Qu’à cela ne tienne :

(get-vm TargetVM|get-view).RelocateVM((new-object Vmware.Vim.VirtualMachineRelocateSpec -property @{datastore=(get-datastore TargetDatastore|get-view).moref;host=(get-vmhost TargetESX|get-view).moref;pool=(get-cluster TargetCluster|get-resourcepool -Name resources|Get-View).moref}),$null)

Comme vous l’avez certainement lu dans les “What’s new” ou dans les *très* nombreux post traitant du sujet, Ô combien sensible, du Web Client, VMware ne lève plus le petit doigt concernant le client C#. Dans cette optique et certainement pour forcer massivement son adoption, toutes les nouvelles fonctionnalités de vSphere 5.1 ne sont disponibles que dans le client flex qui ne laisse personne indifférent :

In vSphere 5.1, all new vSphere features are available only through the vSphere Web Client.

A contre courant, ce post est le premier d’une série qui vous permettra de continuer à utiliser le bon vieux client lourd, 10x plus fluide et ergonomique à nos yeux, et bénéficier des nouvelles fonctionnalités via des commandes PowerShell.

On commence par xvmotion (le codename du “Shared Nothing Live Migration” de VMware), qui permet de déplacer à chaud les vdisk ET le state (cpu & ram) d’une vm d’un host à un autre sans avoir besoin d’un stockage commun :

(get-vm TargetVM|get-view).RelocateVM((new-object Vmware.Vim.VirtualMachineRelocateSpec -property @{datastore=(get-datastore TargetDatastore|get-view).moref;host=(get-vmhost TargetESX|get-view).moref}),$null)

Il vous suffit de remplacer “TargetVM”, “TargetDatastore” et “TargetESX” par les valeurs de votre choix.

Pour en savoir plus sur xvmotion, nous vous conseillons vivement la lecture du document “VMware vSphere 5.1 vMotion Architecture, Performance and Best Practices” qui précise d’ailleurs que lorsque la vm à déplacer a un ou plusieurs snapshot, les fichiers en read only (généralement le plus gros de la vm) sont déplacés en NFC via l’interface de management (vmk0 donc) et ne bénéficiera donc pas du multi-NIC.