Unofficial Tech Memo - Koji Komatsu

vSphere PowerCLIとvSphere SDK for .Netの関係

kkomatsu — Thu, 29 Oct 2009 04:48:26 GMT

VI PowerShell / vSphere PowerCLI についてよく聞かれる質問のひとつが、VI Perl Toolkit / vSphere SDK for Perlに比べてできることが少ないのではないかという点。これはある意味正しい。というのも、PowerShell版は簡単に使える代わりに抽象化度が高く、本来のAPIに含まれる機能についての網羅性に欠けているのだ。

ただ、PowerCLIの範囲ではできないことも、.Net上に実装されVI PowerShellのバックグラウンドで透過的に動いているSDK for .Netを直接利用することで、制約をうけずより広範な処理を記述できる。もちろん PowerCLI の範囲ですむ部分はそこですましながら必要に応じてスクリプトの中で使い分けられるのだ。

この切り替えは、主にGet-Viewというコマンドレットを使って行う。Get-ViewにのIdを渡す(オブジェクトそのもののパイプライン渡しも可)と、純然たるManaged Objectが得られる。あとは、vSphere APIに実装されているプロパティやメソッドが自由に使えるようになる。

たとえば、vSphere PowerCLIのMove-VMコマンドの制約についてまとめた下記の記事も、Get-Viewを使うことで回避することができる。
Move-VMコマンドレットでのVMotionのクセ

下記の例では、指定したESX上のパワーオン状態の仮想マシンを全て別のESXにVMotionさせている。

$src_esx = Get-VMHost <esx-name1>
$dst_esx = Get-VMHost <esx-name2>
$VMs = Get-VM -Location $src_esx
$res = Get-ResourcePool 'リソース' -Location $dst_esx

$esx_moref = ($dst_esx | Get-View).Moref
$res_moref = ($res | Get-View).Moref

$VMs | Where-Object { $_.PowerState -eq "PoweredOn" } | foreach {
($_ | Get-View).MigrateVM($res_moref, $esx_moref, "highPriority", "PoweredOn")
}

PowerCLIの範囲をはみ出しているということを意識しなくてもよいくらいシームレスに使えてることが分かる。
ここで使われているMigrateVMはvSphere APIのメソッドであり、Move-VMはMigrateVMを透過的に使用しているPowerShellのコマンドレットなのだ。

最後に、SDK for .Netについて特徴をいくつか細くしておく。

メソッドに()を使う(PowerCLIのコマンドレットでは()は不要)
引数にオブジェクトを使う場合Morefを使う(PowerCLIはオブジェクトそのものかIdをとる)
MigrateVMとMigrateVM_Taskの違いはPowerCLIの-Asyncの有無に相当(非同期実行)
Get-Viewの逆はGet-ViObjectByViewで行う

このあたりを先日のVMware Virtualization Forum 2009のセッションでしゃべった資料は下記。
VMware Virtualization Forum 2009 A66資料

IPマルチキャストとESX

kkomatsu — Wed, 24 Dec 2008 10:24:06 GMT

IPマルチキャストについてはのTechnical Paperがリリースされた。

Using IP Multicast with VMware ESX 3.5
http://www.vmware.com/resources/techresources/1082

骨子をまとめてしまうと以下の3つ。

ESX3.5 Update2以降では、VMotionやNICチーミングのフェールオーバが発生してもマルチキャストの受信がすぐに再開される (ユニキャストのSwitch Nortificationに相当する機能として、IGMP Membership Fake Queryが実装されている）
デフォルトではIGMP v3のQueryを投げるが、IGMP v2で動作しているゲストOSはこれに対してIGMP Reportを応答しない。v3で動作しているゲストOSはv2のQueryにも応答するため、ゲストOSでv2を使っているものが存在している場合やバージョンが不明な場合は、ESXの詳細設定(Advanced Settings)で、Net.IGMPVersionを2とするのが安全。
ESX3.5 Update1以前のリリースでは、マルチキャストルータのIGMP Queryの間隔（多くはデフォルト60秒）を小さく設定することで、VMotion時等のマルチキャスト受信の中断時間を小さくすることができる。

なお、NICチーミングの負荷分散アルゴリズムでIPハッシュを使用している場合には、バージョンや構成によらずNICフェールオーバ時のマルチキャスト受信の中断はおきない。

Move-VMコマンドレットでのVMotionのクセ

kkomatsu — Tue, 23 Dec 2008 16:52:44 GMT

VI PowerShellのサンプルとしてよく見かける下記の記述では、どうやらCold Migrationしかできないようだ。VMotionしようとすると、inner errorと言われしまう。結構はまり所かも。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-VMHost "host-name")

ホストの変わりにリソースプールを指定すれば成功するのだが、リソースプールではなくてESX直下にVMotionしたい場合、回りくどく下記のように書く必要がある。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-Resourcepool -Name リソース -Location (Get-VMHost "host-name"))

途中、Get-Resourcepool で指定している「リソース」という名前は、ESXに自動的に生成された見えないルートリソースプールの名前。英語版の場合には「リソース」ではなく「Resource」となるのかな？（未確認）

なお、クラスタ内の場合、DRSの有無にかぎらずESXのルートリソースプールはクラスタのルートリソースプールになっているのか、コレで指定してもESXを移動しない。（エラーは発生せず、成功したように見えるが。）

これらの点について、VI PowerShellのヘルプでは下記のように注意書きされている。

Moving a virtual machine in a cluster is only possible if the virtual machine is in a resource pool in that cluster.

実際の挙動を確認した限りは下記が正解に近いのではないだろうか。

クラスタの有無にかかわらず、VMotionの移行先にはリソースプールだけが指定できます。また、クラスタ内では（たとえESXのルートリソースプールを指定したとしても）ESX間の移行はできません。

なお、確認はESX3.0.3 / VC 2.0.3および、ESX 3.5 Update1 / ESXi 3.5 Update1 / VC 2.5 Update1で実施した。

2009年10月29日追記

VI PowerShell のメジャーバージョンアップである vSphere PowerCLI 4.0とvCenter 4.0の組み合わせでは、下記でのVMotionに成功した。
ESXは4.0でも3.5 Update4でも可能だった。残念ながら、vSphere PowerCLI 4.0でも、vCenter 2.5に対しては使用できなかった。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-VMHost "host-name")

なお、この制限はVI API / vSphere APIそのものにあるわけではない。.Net上に実装され、VI PowerShellのバックグラウンドで透過的に動いているSDK for .Netを使用すると、バージョンに関係なくVMotionが可能である。こちらについては下記の記事にまとめた。
vSphere PowerCLIとvSphere SDK for .Netの関係