こんなかったるい仕事はしたくない
ぶっちゃけですね。IDCFクラウドへのインポートがovaのみって凄まじくイケてない。それだけならまだしも、http経由でIDCFクラウドへダウンロードさせる必要があるというのも、本当にクソみたいな仕様でマジでイケてない。もっとも、かの悪名高い Zenlogic を買収している時点で未来がなくて他社との勝負権を放棄しているとは思いますが、とりあえず「やって欲しい」と頼まれたんで、ブログのネタにしちゃろと思ってみました。(ちなみに買収後、間違いなく定期メンテナンスの量は激増しています。障害の量は相変わらずですが、週刊サーバ障害！からは抜け出したかな。)
まあこんなん誰がやるんだって話ですけどね
使い勝手ならGCPやAWSの方が遥かに良いし。物理ラックと接続できるメリットが無ければ自分も選ばな(略
というか、プライベートコネクトも回線速度1Gbps契約なのに実質100Mbps (10-13MByte/s)しか出ないので、使い物にならな(略
という訳で、書いていきます。
ハマリポイント
ブラウザのovfエクスポートは使い物にならない
これ、本当に罠です。ESXi 6.0 あたりから VMware vSphere Client では無く、ブラウザGUIを利用できるようになりました。ここから ovf エクスポートが可能なのですが、100%失敗します。ええ。本当に。めちゃくちゃ騙されました。ブラウザの仕様?か何かでデータが大きいとタイムアウトします。
そこでovfエクスポートには、必ず 最新版の OVF TOOL を利用してください。現在は 4.4.0 が最新版のようです。Linuxでやればよかったと後悔しましたが、RDP経由で作業していたので Windows 版で行いました。
実作業 ovf 出力から ova 変換
作業例は サーバ 172.25.13.224 にある testserver を z:\ にovfエクスポートする例です。
ちなみに仮想サーバ側は Power ON 状態でエクスポートする事は不可能なので、一旦パワーオフしておいてください。
その場合は、Error: Fault cause: vim.fault.InvalidState というエラーがでます。
C:\Program Files\VMware\VMware OVF Tool>ovftool.exe --noImageFiles vi://root:****PASSWORD****@172.25.13.224/testserver z:\
Accept SSL fingerprint (4C:89:F1:46:92:30:92:55:54:D2:95:A6:1F:D0:4B:F2:EF:63:A0:46) for host 172.25.13.224 as source type.
Fingerprint will be added to the known host file
Write 'yes' or 'no'
yes
Opening VI source: vi://[email protected]:443/testserver
Opening VI source: vi://[email protected]:443/testserver
Opening OVF target: z:\
Writing OVF package: z:\testserver\testserver.ovf
Disk progress: 15% <- 適当
Transfer Completed
Completed successfully
こんな感じで z:\ に testserver というディレクトリを自動生成して、その中に ovf やら vmdk を出力してくれます。そして、このままだとクソ仕様のIDCFクラウドにはインポートできないので、ova変換します。
C:\Program Files\VMware\VMware OVF Tool>ovftool.exe Z:\testserver\testserver.ovf Z:\testserver\testserver.ova
Opening OVF source: Z:\testserver\testserver.ovf
The manifest validates
Opening OVA target: Z:\testserver\testserver.ova
Writing OVA package: Z:\testserver\testserver.ova
Disk progress: 16%
Transfer Completed
Completed successfully
変換用バッチファイルを作った
@echo off
if "%~4"=="" (
echo;
echo *** Error!! Parameters are missing. ***
echo;
echo %0 ESXiPassword ServerIP ExportPath vmname
echo [example] conv.bat pass1234 192.168.0.111 c:\tmp testserver
exit /b
)
ovftool.exe --noImageFiles vi://root:%1@%2/%4 %3
ovftool.exe %3%4\%4.ovf %3%4\%4.ova
ovftool.exe %3%4\%4.ovf %3%4\%4.ova
del /F %3%4\%4.ovf
del /F %3%4\%4.mf
del /F %3%4\*.vmdk
いちいちコマンドを打つのが面倒くさかったので、Windows用のバッチファイルを作りました。変換されたかどうか待ってるのもタルいですし。
C:\Program Files\VMware\VMware OVF Tool 内部に好きなファイル名でバッチファイルを作成してください。
パラメーターは、ESXiパスワード・ESXiサーバIP・出力先パス・VMname です。
例では、conv.bat というバッチファイルを作成、パスワードは pass1234。ESXiのサーバは192.168.0.111。
このESXi上にある testserver を、c:\tmp へ ovf 出力したあと、そのまま ova ファイルへ変換します。不要なファイルは最後で全て消します。
ovaをインポートする為のhttpサーバをIDCFクラウドで立てる
これが一番意味わかんないんですよねー。
IDCFクラウドへインポートする為にはovaファイルをIDCFクラウドへアップロードする必要があります。しかし、このアップロードはブラウザではできません。NFSやSMBもありません。
どうするかと言うと、テンプレート作成画面からURLを指定してダウンロードさせる仕様になっています。ここからその説明をします。
IDCFクラウド側へインポート(テンプレート)
正直、このovaファイルのインポートの仕様は訳わからなかったです。詳しくは後述します。
まずボリュームでもインポートできそうだし、テンプレート側でもインポートできそうでした。FAQ読めばよかったんですが、面倒なので今回はテンプレート側で作成する事にしました。(結局、これが正解でしたが)
[テンプレート] -> [テンプレート作成] からエクスポートした仮想サーバの情報を入力していきます。
ここで不思議な項目がありますね。「URL」ってヤツです。
これがこのIDCFクラウドへのインポートの最大の癌、超絶クソ仕様といわんばかりのアップロード方法です。つまり、IDCFクラウドで ova ファイルをアップロードするには、http経由じゃないとアップロードできません。
自前でWEBサーバを別に立てて、そこに ova ファイルを置いてダウンロードさせる仕様
になっています。もはやこの時点で面倒くささ炸裂です。もし自前でサーバがなかったとしたら、IDCFクラウドで別の仮想サーバを作成して、ova を置く場所を作り、そこでhttpサーバを起動させてから、IDCFクラウドのコントロール画面でダウンロードさせる…という心底アホな仕様なんです。これが前の章で書いた、”後述”にあたる所です。
設計した人は頭悪いんじゃないかなって本気で思いました。自分は更にプライベートコネクトを利用して、別のネットワークから裏線で接続しているんですが、この裏線経由ですらhttpサーバ経由では取りに来てくれません。理由は管理画面を見れば判りますが「許可IPアドレスリスト」というのがあって、このIPアドレス帯からじゃないとアップロードできないのです。
で、この 「許可IPアドレスリスト」 は当然、IDCFクラウドで利用できるIPアドレス帯(自社で持っているIPのみ)が書かれていて、しかも変更できないので、強制的にIDCFクラウド上でアップロード専用の仮想サーバを別に作成しなくてはいけません。当然、その分のコストはこちら持ちです。
仕組みとして最低ですね。
更に罠があります。東京リージョン1と2では、ESXi 6.0 までしか対応していません。東京リージョン3でやっと ESXi 6.5に対応しました。そんなサポート切れたESXiを使ってるわけないでしょ(笑) というレベルでお粗末な仕様です。 中身は cloudstack だそうですが、初期に作ったもんをそのまま弄れず、コストも掛けられないから放置してるんでしょうね。
ふと思い出した
そういえば、ここ。Zenlogic って最低のクラウド業者を買収したんですよ。Zenlogic といえば、過去に散々やらかした上に、自分のところのブログでもネタにしたレベルの酷い事業者でした。つい先日まで、週刊サーバートラブル 絶賛発売中！とばかりに、障害の起きない週は無いというレベルの酷いシステムでした。
で、何でこんなクソな業者を買収したのかなーって思ったんですが、自社で構築した cloudstack があんまり良くなくて、Zenlogic で使ってるクラウドシステムが欲しかった or 見たかったのでは無いかと邪推しました。特にあの時期なら、トラブル続きで買い叩けるでしょうし、腐ってもファーストサーバだったので顧客も引っ張れるし…という目論見だったんじゃないかと思いました。あくまで邪推です。
ただ、今現在システム統合できていない所を見るに、どっちも使い物にならなかったんじゃないかなーと思います(笑)
話が脱線しました。
という訳で、引き続きテンプレートを作成していきます。
と言っても全て記載したら、あとは「テンプレートを作成する」というボタンを押すだけです。何事も無ければ正常にインポートされます。
作成するのボタンを押すと、記載したURLからダウンロードが始まります。
画像だと見にくいのですが、「install Template」と表示されています。一時ファイルとしてどこかにダウンロードした後、テンプレートへの変換処理でもしているんでしょう。
インストールが完了すると、テンプレート名がクリックできるようになります。
こんな感じです。
ちなみにこのテンプレートはovaの容量分では無く、実容量で課金されるとの事でした。ovaファイルが100GBでも、使用容量が15GBならその分の課金だという事です。圧縮されて保存されているとか。
テンプレート化されたovaから仮想マシンを作成する
ここから仮想サーバを作成していきます。
「仮想マシン作成」を押し、「仮想マシン作成画面へ」をクリックします。
いつもの仮想マシンの作成画面に飛びました。
ここで気をつけるのは、イメージを「My Template」から選択する事です。先程作成したテンプレートがあるので、これを選択します。
あとの設定はお好みでどうぞ。ちなみにCentOS6だと当然ネットワークの認識問題が絡むので、/etc/udev/rules/ 以下のネットワーク設定で認識したNICにeth0を割り当ててください。
作成できたので、そのまま起動します。
起動している画面はこんな感じです。
ちなみにこの時点だとHDDは実容量では無く、仮想で確保したHDD容量分だけ課金されます。先程のテンプレートでは、ovaファイルが100GBでも、使用容量が15GBならその分の課金だと説明しましたが、テンプレートから仮想マシン化すると、HDDは元のovaファイル分が確保されるので、使用容量が15GBでも容赦なく100GB分の課金になります。嫌なら、ova化の前にパーティションを弄ったりlvmで縮小しておいた方がいいと思います。
IDCFクラウドはHDD課金、正直言って異常に高いので。
WEBコンソールも接続できたので、無事にovaファイルからインポートできました。
起動が確認できたら、テンプレートは削除して構いません。無駄金取られるだけなので。
結論
正直、2度とどころか一生やりたくないです。
まず何はともあれめんどくさい！！！！の一言です。元々のvmwareのバージョンに依存していて、ver13以上は利用できない。ver14等の場合は、vmxを弄ってからどうにかしてイメージを起動して、ovaエクスポートする必要があります。
更にその上で、通常のovaをブラウザでダウンロードすると大抵エラーが起こるので、ovatool が必要になります。更に更に、その ovatool で vmx を変換する場合、一度 ovf にしてから、再度 ova に再変換が必要になります。
そうやって、ようやくインポートできるカタチになります。
で、そのインポートできるカタチになったモノを IDCFクラウド内で起動した http サーバの配下へコピーして、クラウド画面からダウンロードできる段取りを作らなければならない。
その時、東京リージョン1でやってしまうと、ver10までしか対応していないので東京リージョン3でやり直しをする。よしんばそこまでうまくいって、仮想マシンを作成してもOSの起動に失敗する事が多数ありまくって心が折れます。
実際、自分はCentOS6,7、Windows10、Ubuntuでトラブりました。
あと、このインポートに関してはお客様の環境依存という事で、法人営業のついてない方はトラブル対応してくれません。そして、法人営業がついていても「サポートはベストエフォートなので」という一言で終わります。
ウチは営業に “できる” って言われたからやっとんのじゃ！と言いましたが、最終的にその解決の手間の時間で他の作業ができるという事でサポートを捨てました。
という訳で、ovaインポートができる確率ですが、自分の環境では大体20%成功すれば御の字というレベルでした。自画自賛する訳では無いですが、openstackやvmware、ESXi、Linuxやネットワークの知識はそれなりにあります。(15年以上触ってますし) それでもこれだけトラブるので、一般の方には絶対オススメしません。私が1週間で検証した内容も、経験の少ない方では解決するだけで数ヶ月は必要だと思います。そのくらい、多岐にわたってトラブルシュートの知識がいります。ova化する時もオプションにコツがあったり、vmdk側で一旦00で埋めた後にvmdkファイルサイズの縮小をした後にova化したらうまくいった、という例もありました。
この作業にはマニュアルが無いので、全てトライ・アンド・エラーです。ネットワークエンジニアを雇って検証させたら、いくら掛かるんでしょうね…というレベルで無駄な時間とコストが掛かります。
余談ですが、ここで起動失敗したイメージは、AWSやGCPでは一瞬で起動しました。なので、予算がある程度確保できるのであれば、AWSやGCPをオススメします。AzureはvmdkをVHDに変換する必要がある気がするので、ちょっと大変かもです。
というわけで全国で数人の為だけの記事を作ってみました。何度もいいますが、
IDCFクラウドを利用するなら、1から作った方が早くて安くて確実よ！！！間違っても既存環境をそのままインポートすれば、とか考えない事！！！
( 余談&名誉の為に言いますが、弊社についてくれている営業は一人を除いて、とても優秀な方です。まあ、そのダメな一人は新人っぽくて契約書を数週間ほっぽらかして、こっちのスケジュールめためたにしてくれて数十万損させてくれたってだけですけれど。勿論その分、色々と便宜をはかって頂けたので総合的な対応としては及第点です。あと、何も考えずに 1 から \500 サーバを作る分にはとても安くていいと思います。)