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の関係
