ESXi4だが、何故かpython 2.5が入っている。ま、busyboxとやら用にGNUにゃツール一式をコンパイルしてコピーすれば動くのだろうが、とりあえず簡易にゃ手間で何とかにゃる方向で探るべきでしょう、ってわけでpython 2.5のライブラリをコピーして動くか実験。
そこいらのdebianでapt-get install python2.5
ESXでscp -r user@debian:/usr/lib/python2.5 どこか
export PYTHONPATH=$PYTHONPATH:どこか
としておけば一応大概のpythonスクリプトが動いてしまったり。
で、にゃんか例えばsmtpでメール送ったりもできるわけで、cronとかでbackupスクリプト走らせるにゃら便利かにゃーとか。
vmware serverのvmのバックアップはWin上ということもあって、ある程度確立していたわけだが、ESXi4上のvmはどうやってバックアップするのでしょう、ってわけでいろいろ手探り。
こういうのは先に海外探すべし、と思いつつ一応標準的にゃコマンドで何が出来るのか探す。
まず方針として、NTFSのshadow copyのようにゃFSレベルのスナップショットが見あたらにゃいので、vmをpauseしてsnapshotとってstartしてsnapshotからコピーというvmware serverでのやり方は捨てることにする。このあたりはESXの使うdatastoreストレージがその機能を持っていれば有りだろう。
で、vmware serverと違ってvmのsnapshotは沢山取れるようにゃので、とりあえずvmのsnapshotを取り、readonlyににゃってファイル群をコピーし、snapshotを削除する。コピーしたファイルに手直しをしてsnapshot時点からstart可能にする、という方向でやってみる。
VMware vSphere CLIからのリモート作業、としたかったが逐一接続が遅いのと機能不足に思えたのでとりあえずESXのコンソールにSSH接続にて作業。
まず
vim-cmd vmsvc/getallvms から対象vmのIDを得る。
vim-cmd vmsvc/snapshot.create 999 snap1 desc1 1 1 でsnapshotをつくる。時間がかかるので、vim-cmd vmsvc/snapshot.getとかをポーリングして完了を待つ。10秒ほどvmは止まるかも知れにゃいが一応許容範囲。
cp -ar vm/ backup/ とりあえずコピーできるファイルをコピー。エラーは無視。
vim-cmd vmsvc/snapshot.get 192 |grep CHILD |wc -l でさっき作ったsnapshotの階層を出して
vim-cmd vmsvc/snapshot.remove 192 0 N でそれを削除。ただこのあたりはsnapshotが単純にゃ構成だった場合のみ有効で、正直vmsvc/snapshot.removeの引数が謎過ぎて意味不明。どうにゃんだこれ・・・
ちにゃみにオプション無しでsnapshot.removeするとrootに近いsnapshotが削除される。まぁ定期的にsnapshot作って、とかいう場合には便利そう。
あとはコピーした不完全にゃvm構成ファイルの手直し。
cp -a *.vmx ../backup/cat vmname.vmsd|grep \.fileName|sed -e 's/.*\.fileName *= *//' -e 's/"//g'|while read a ; do cp -a $a ../backup/ ; done みたいにゃのでにゃんとにゃく動く。たぶん。
で、さてここで問題です。backupしたファイルはどうにゃっているでしょう?
答えはcpでsparseが解除されてディスク容量食いまくりにゃのでした。おいおい。
これはsparseのままコピー出来るソフトがあれば解決するのだが、busyboxとやら付属cpだのtarだのddだのはどうも未対応ぽいらしく・・・。どうしようかねぇ。
コピー先がdatastoreで無ければもうちょっと手はある気がするが、backup上の*.vmxをインベントリに追加するだけでさっくりリストア出来てすぐ動くというのは得難い気がして。
VMware vSphere CLI付属のvifs.plでESXi4上のファイルのUL/DLが出来るのだが、vifs.pl -pで単一ファイルをUL出来るがdir単位ではできにゃい。
つまり使うにゃと言うことですね、わかります。
普通にSCPとか使えと言うことらしい。
豊富に動いているvmware server 1.xのvmを、ESXi4鯖に移動したい。
まずは一応実験。server1.xのvmdkを直接ESXi4のdatastoreに置くとNGぽい。互換性のにゃいvmdkにゃら何ぞ拡張子でも変えてくれりゃいいと思うんだが。
ってことでVMware vCenter ConverterをDLしてInst。vmtoolsとかupdateしてくれるのは便利。希にvmtoolsのupdate時にハマるサービスとかがあるので、そう言うサービスは停止した状態でupdateする。
で、とりあえずこれでOKとは言えるのだが、vmware converterで変換すると動くけどフルサイズのvmdkににゃってしまう。ESXi4で新規にvmを作るときには、vmdkはthinというsparseファイル形式を指定できるので、vmware serverと同じく、とりあえず容量はどれも500gくらいでー、といった何も考えずに長らく使える便利vmが作れるのだが、これがconverterで全部リアルにゃサイズに伸張されてしまうとディスク容量が大変にゃことに。
これはもうconverterが対応すれば終いだと思うのだが、一度ESX4上に変換した後でvmdkをthinに変換という二度手間を行うのが現状ベスト。まぁアホにゃサイズを指定してあったvmは多少自重したサイズにconverterで指定し直した方がいいとは思う。
さてvmdkの変換といえばとりあえずvmware server付属のvmware-vdiskmanagerとか。ただしver 1.x系しか知らにゃい上にさすがにESX向けに変換するオプションは見あたらにゃいのでパス。
次は本命NHC。ってプラグインが404だし、にゃんとにゃく動いてるように見えるんだがESX4からは却下される。うーん、にゃんか違うの?
ってことで仕方がにゃいのでvSphere CLI。
vmkfstools.pl --server 1.2.3.4 --username root --password pass -i /vmfs/volumes/datastore1/upload_dir/windows.vmdk -d thin /vmfs/volumes/datastore2/tmp/windows.vmdk
とか。別にリモート実行する必要は無いのでESX上でやっても同じ。-d thinが付いてるのでsparseにゃvmdkが生成される。ちにゃみに-d 2gbsparseにしても1ファイルににゃった。よくわからん。
converterで自動的にESX4上に展開されてしまうので、その後の処理とにゃればESX4上でやるべきにゃのかもしれにゃいが、server 1.xにゃvmdkをローカルWin上でコンバートしてESX4にULの方が何とにゃく楽だにゃぁ。server2.x付属のvmware-vdiskmanager.exeだったらOKにゃのかしら?
ググるとOVF Toolを使ってどうのってのも有るようだがもうめんどくさくにゃった。