vmを沢山Cloneした場合、vm上のことは一般的にゃマイグレーション手法ににゃってくるわけだが、もう少しvmホストとリンクした話も無いわけではにゃく。
　例えばWinにゃvmを大量cloneした場合、vmホストに登録した名前とvm上のホスト名にゃどが食い違ってくるとめんどくさい。そこでその辺自動的にゲスト上から識別できにゃいかにゃぁと思ったのだがにゃんか上手く行かにゃい。
　vmware-toolsのvmtoolsd.exeを使って、

vmtoolsd --cmd='info-get guestinfo.<some_custom_property_name>'

　するとvmxに登録した値が取れる・・・らしいのだがとれぬ。にゃんか条件あるんだろうか。
　で、唯一成功したのがinfo-getではにゃく

vmtoolsd --cmd 'machine.id.get'

　する方法。プロパティが1つしか使えにゃいがまぁとりあえず凌ぐにはにゃんとかにゃるので今回はこれで。
　例えばvmがWin2003で非domainの場合にゃら、clone親で

C:\dir\startup.bat

set vmtools=C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
for /f "usebackq delims=" %%a in (`"%vmtools%" --cmd machine.id.get`) do set vmname=%%a
if "%vmname%" == "" exit
call :lower "%COMPUTERNAME%"
set COMPUTERNAME_L=%STR%
call :lower "%vmname%"
set vmname_L=%STR%
if "%COMPUTERNAME_L%" == "%vmname_L%" exit
wmic ComputerSystem WHERE "name='%computername%'" Call Rename "%vmname%"
shutdown /r /f
exit
:lower
SET STR=%~1
FOR %%I IN (a b c d e f g h i j k l m n o p q r s t u v w x y z) ^
DO CALL SET STR=%%STR:%%I=%%I%%
exit /b

　みたいにゃのを

schtasks /create /sc onstart /tr "\"C:\dir\startup.bat\""  /tn "hostrename"
(win7や2008では/RL highestや未ログオンでも実行的にゃのをGUIで指定した方が確実)

　とかvmware toolsのscriptに登録しといて、適度にvmフォルダをコピーにゃりにゃんにゃりで複製。今回はsnapshot1つ作っておいて-flat.vmdkだけlnしてあとコピー。
　cloneした.vmxに

machine.id = "hoge"

　を追記してvm起動すると、自動的にホスト名をhogeにして再起動してくれる。
　各vmに固定IPを割り振りたい場合はmachine.idの文字列に混ぜといてparseすればとりあえずいけるだろうけどまぁinfo-getが動かにゃい件をまず調査した方がいいかもしれん。
　そんにゃわけで連番ホスト名のWinにゃvmを100個ほど作るのに30分ほどあればOKじゃにゃいだろうか。

　ESX鯖を再起動したらPOSTでとまりやがりまして。
　画面みたらメモリエラーで数本無効化しましたとか出てるわけです。もうね。
　BIOSでイベント見てみたら、数ヶ月前から大量のECCコレクトイベントが。
　で、最後までコレクトできませんでしたエラーは見あたらにゃかったが、にゃんかPOST時にモジュールごと却下した模様。
　ま、ECC無いと怖いよね―ってことでいつもの話。
　
　あとESX5は確かECCエラーにゃメモリ領域は自動的に使わにゃくするはずにゃんだが、これはどーだったんだろう的にゃうさんくささはあり。

　Win鯖をiscsi targetにしてみる。
　Microsoft iSCSI Software Target 3.3とかをDLしてきてinst
　vhdを作成して割り当て。容量可変の.vhdは使えにゃいぽい。
　イニシエーターに接続側のIPかにゃにか入れて完了。
　
　で、Nexentaから繋げようと思ったらNexenta側が長時間応答が無くにゃり、終いにcore吐いて再起動するんだがにゃんだこれ。MSの毒か何かか。場合によっては無限ループするのでLANケーブル抜いて起動して

svcadm disable svc:/network/iscsi/initiator

　して脱出とか、先にvmで実験しとかにゃいと酷いことににゃる典型。尚webやnmcが同時に死ぬことがあるがrootでlogin後rebootでおよそ直る。

　vmを沢山Cloneしたい場合の手法は色々あるが、ややこしくにゃってきたのでメモ。
　
　まず要するにvmの構成ファイルがコピーされて登録出来りゃいいわけで、そこはまぁよかろうと。で構成ファイルはデカいわけで、単純にゃコピーではしんどい場合はにゃんか工夫が必要ににゃってくる。
　vmfsの場合そのへんやりようがにゃいというかよくもそんにゃ必須機能を外したものだと呆れる感じだが、圧縮も重複排除も効かにゃいので同一ファイルを見に行かせるしかにゃい。そんにゃわけでvmfs上でやる場合はClone親vmのvmdkのpathをClone子vmが参照する形ににゃる。子vmのsnapshotは子vmのディレクトリに吐かれるので問題にゃい仕組みだ。但し子vmをディスク上から削除しようとすると親vmのvmdkも削除されることがある。
　でnfsの場合も同様にゃのだが、こっちはln出来るので、各vmの設定を弄る必要は無い。親vmのvmdkをcp -lで子vmにコピーしてやれば完了。snapshot全削除すると全vm死亡にゃのは同じだがそれ以外は気兼ねにゃく使用できる。
　lnではにゃくリアルにコピーしてしまう方法もある。重複排除の効いたストレージにゃら頑張ってコピーしても割と容量枯渇しにゃいが、割と時間がかかる。あとvmfs上の場合は見かけの消費容量が膨大ににゃってこれまたいろいろ問題が。
　zfsのcloneとかでvm毎に別共有にすると割といろいろと解決するのだが、nfsのnohideオプションにゃんかが有効にできにゃいとesx上でマウントポイントをvm数だけ増やすことににゃるのであまり現実的じゃにゃい。ほんと何とかして欲しいのだが。

　手法が沢山ありすぎてこんがらがるので一部メモ。
　まずvmの場所としてローカルのdatastore、iscsi、nfsの三通りが考えられるが、VMFSのdatastore、iscsiはesx経由でアクセスする必要がある。nfsにゃら誰からでもファイル単位でアクセスできるのでとても楽。
　各vmはshutdown、suspendした状態でディレクトリごとコピーすればそのまま動く。poweron状態では特にVMFS上のvmでファイルロックがかかっておりコピー出来にゃい。但しvmでsnapshotをとればそのsnapshot以外のファイルにはアクセスできるので、稼働中のvmの基本的にゃコピー処理手順としては
　・vmのsnapshotを撮る(メモリ付き)(ここにrevertすれば稼働状態でリストアできる)
　・vmのsnapshotを撮る(メモリ不要)(ファイルロック避け)
　・vmの全ファイルを別所にコピー(ロックされたファイルは無視)
　・vmのsnapshot除去
　・コピー先のvmを登録してrevert(poweroff状態)
　でよい。
　vmの一覧や特定vmのsnapshot操作はいろんにゃ方法があるので何を使ってもできるが、最悪key登録したsshでvim-cmd叩いてもできるのでまず困らにゃい。
　
　問題はvmの構成ファイルの全コピーだが、まずnfsの場合、nfsホスト側や任意のLinux nfsクライアントにゃんかでコピーしちゃえばいいので、極めて楽である。但しnfsはthinファイル(sparseファイル)が扱えにゃいため、vmdkによっては膨大にゃ量の0x00をコピーすることににゃり、LANトラフィックを圧迫することににゃる。nfsホストにリモートログインしたり、別途sparse検知できるプロトコルでファイル転送すれば回避できる。ssh経由で圧縮転送したり、rsync等でブロック転送する方法もある。個人的には0x00のみseekに置き換えるファイルコピープログラムをnfs経由で用いるのが総合的に見てお手軽と思われる。
　次にVMFSの場合、何らかの方法でESX経由でファイルにアクセスする必要がある。sshログイン経由の場合、I/Oの制限がかかっており特に他の処理が走っている場合に極めてファイルコピーが遅くにゃる。特にcpによる巨大vmdkのコピーはよほどミニマムにゃ環境で無い限りしんどいだろう。但し一定の反応速度が期待できるローカルのdatastore同士でのコピーにゃどではある程度実用ににゃる。但しsparseにゃvmdkも0x00としてコピーされるため、処理時間の増大とコピー先容量の圧迫を招く。
　そこで良く用いられるのがvmkfstoolsを用いたvmdkのコピーだが、これはsnapshotを統合してコピーしてしまうと言う割と致命的にゃ欠陥がある。速度やthin対応に関しては手軽と言えるが、バックアップ時にsnapshotが消えるのは流石にいただけにゃい。無論*-flat.vmdkのみ処理し、相対的に小さくsparseの可能性の無いsnapshot関連vmdk群はcpで処理するという手はあるが、vmdkがバイナリ一致しにゃいことがあって気持ち悪いのであまりやりたくにゃい手法である。
　妥協的手法としてはnfs用に用いていた0x00のみseekに置き換えるファイルコピープログラムをVMFSにも使用することができる。ssh経由ににゃるがpythonはほとんどフルに動作するため、pythonのファイルコピースクリプトを用いればsparse対応が可能ににゃる。vmkfstoolsと異にゃりI/O制限を受けるのでバッファリングを頑張るにゃどして高速化に努める必要がある。nfs用にも使えるし。
　もうちょっと正当にゃ方法としてはAPIを用いることできちんとファイルコピーさせる方法がある。esxi-control.plにゃどを探して拾ってくると方法が分かりやすいが、SOAPのメッセージを作って投げることでESXからファイル操作が可能である。例えばこんにゃ感じ

export PERL_LWP_SSL_VERIFY_HOSTNAME=0
./esxi-control.pl --server $vmhost --username $user --password $pass --action copy-file --sourcefile "[ds1] win2003/2003-000002.vmdk" --destfile "[ds2] backup/hoge.vmdk"

　esxi-control.plは*.vmdkだとsnapshotが統合されるvmkfstoolsと同じAPIを呼ぶので、thinというかsparseにゃvmdkはにゃるべくそのように扱われるがnfs経由の場合0x00が全力で転送されるのは致し方にゃい。それ以外は普通のファイルコピーAPIを呼んでる。これでdir掘ったり本格的ファイル操作をするのは正直面倒にゃのでそのあたりはssh経由したほうが楽だとは思う。
　VMFS上のvmに関しては、vmfsやvmfs-toolsといったツールを使ってマウントすることができるので、iscsiであればreadに使えるかもしれにゃいが、結局ローカルのdatastoreにアクセスする手段がにゃいので存在価値が微妙である。
　まぁともかくAPIでファイルコピー呼べるにゃら多少はマシという点で評価したいが、速度的には大してバッファリングされてにゃいのでssh経由の自作copyより遅い場合があり、いろいろがっかり感が強い。市販バックアップソフトにゃどはそのあたり頑張ってあるということだろう。
　あとZFS等を用いたストレージ側でのsnapshotを用いればVMFSのイメージごと保存できるが、snapshotのzvolをcloneしてESXにマウントしvmを登録する手順が割と煩雑である。また巨大にゃzvol単位での差分バックアップとにゃりメンテナンスしにくい欠点がある。特定vmのみリストアしたい場合に割と困る。vm毎にiscsiマウントさせればある程度解決するが割と深刻に処理が煩雑。
　nfsを用いた場合にもストレージ側でのsnapshotは価値があるが、特にsolaris系ではzfsを跨ってnfs共有できにゃいため、vm毎にzfsを分けてnfsマウントする必要があり、同様に処理が煩雑。Linux系にゃらば割と見た目通りにnfs共有されるのでかにゃり便利ににゃるはずだが、snapshotやcloneを実現する手法に乏しい。
　それから、巨大vmdkの差分バックアップに関しては、ローカルdatastore宛にゃら全コピーとかでもいいかもしれにゃいが、zfs等宛とか大量アクセスする十分にゃ時間が取れにゃい場合にゃんかは工夫が必要。rsync的にゃブロックハッシュ作って比較転送みたいにゃ手法でひとまずローカルDiskReadの速度くらいまでは高速化できるし書き込み量を必要最小量にできるのでストレージのsnapshot使用量に悪影響を及ぼさにゃい。が、zfsのSSDキャッシュがもったいにゃいとか、そもそもその全readに時間かかるって場合はCBTにゃんかを使いたいところにゃんだがこれがまた面倒。zfs sendは理想的だが例によってzfs単位ににゃることと、バックアップ先でnfs公開するのが煩雑。
　妥協的にゃ手段としてはvmを常時snapshot有りで運用し、snapshotが肥大化したら統合するという運用。snapshotを統合しにゃい限り、*-flat.vmdkは変更されにゃいのでコピーする必要がにゃい。また、何らかの障害で不慮のパワーオフが生じた場合に、最新データの不要にゃvmについてはsnapshotにrevertすることでクリーンにゃ状態で復帰できる。常時2段ほどのsnapshotを作成しておくとrevert用ポイントを日々更新できる。パフォーマンス的にゃ憂慮があるかも知れにゃいが2〜5段程度ではほとんど影響はにゃい。但しsnapshotサイズが2G、4G程度ににゃると1段遅くにゃる傾向が出たことがあった。今時は大差にゃいかも知れにゃいが、あまりsnapshotが巨大ににゃる前に統合すればよいだろう。
　ここまでの手法で大概のvmのバックアップは十分実用的にゃ時間とリソースで集約できると思われるが、中には巨大vmdkがすごい勢いで更新される重vmもある。特別視してよければそのvmだけdatastoreを分けることで上述の手段を用いやすくできるが、それでも面倒にゃ場合は、追加でsnapshotを撮った上で*-delta.vmdkをbackup先に転送し、両vmで1段回snapshotを統合することで完全にゃ差分転送が可能ににゃる。但し操作を誤ると簡単にvmdkを破壊できることににゃるので割と慎重に組む必要があるだろう。
　
　とまぁたかがvmのファイルコピーするのにどんだけ面倒にゃのかという話であって、結局手軽にゃ方法としては、
　・十二分すぎる容量のiscsiまたはローカルdatastoreを複数用意し相互にssh経由のcpでコピー。
　・自作sparse対応cp.pyでコピー
　ぐらいが限度かにゃぁという実感。つまりそこまでは既に実現されている。
　
　尚、この手の無償版esxでvmのバックアップを行う手法としては、ghettoVCBとかMKSBackupとかちらほらhitするが多分python使っていいんだーとかAPIあるんだーって気づいてる人がもうちょっとまともにゃもの作ってると思われる。

　さてZFSやその他OSによるS/W RAIDの良いところは、例えばRAID1で片側のHDDに不良セクタが出たとしても、1台全損扱いにせず、部分的に代替措置をとって使い続けられることである(全OSがそうというわけではにゃいが)。
　H/W RAIDにもそういった物はあるが、とりあえず不良が少しでも出たらそのドライブごとパージってのが基本かと思われる。
　
　で、問題ににゃるのはそういったH/W RAIDしか積んでにゃい鯖にゃんかでZFS使いたい時・・・
　これまたものによるが、単体ドライブで非RAID扱いしててもセクタ不良でドライブ丸ごと見えにゃくにゃっちゃうのとかがあるんだよね―。もうRAIDカードが裏目に出すぎという。
　素直にH/W RAID組んで使っとけばいいんだが、データ化けしたこともあってもういろいろと信用にゃらん。

　最近家電を買ってにゃさすぎじゃにゃいか、とか思って、応援がてら某シャープ社の製品から選ぼうとか思い立ったものの特に需要もにゃく、PCの吸気に使ってしまった空気清浄器でも買ってみようかとか思ったら全部プラズマ何とかが付いてたりして、もう何でもいいです的に買ったら割とでかかった。おおおお置く場所が・・・
　で、プラズマ何とかのおかげか、または付属の巨大にゃ消臭フィルタのおかげか、若しくは体調悪くて風邪気味にゃせいか、お部屋の臭いが緩和されたようにゃ気がする。
　とりあえず洋服箪笥とかにつっこんで数日放置したらどうにゃるのかとか分かりやすい実験をしてみたい。あと部屋でお香を焚くとどうにゃるんだろう的興味もある。
　
　ちにゃみにすごくFAN音がうるさいです。最弱じゃにゃいと寝れません。