svmotion switchover time
Posted by NiTRo | Filed under Kb, Tips & Tricks, VMware
MAJ 02/02/2012 : remplacement du script par un one-liner 
Lors d’une tentative de svmotion nous avons été confronté à un timeout sans plus de détails :
C’est dans le vmware.log de la vm qu’on trouve la cause de l’échec (c’est souvent le cas d’ailleurs…) :
Migrate_SetFailure: The migration has exceeded the maximum switchover time of 100 second(s). ESX has preemptively failed the migration to allow the virtual machine to continue running on the source. To avoid this failure, either increase the maximum allowable switchover time or wait until the virtual machine is performing a less intensive workload.
Pourtant, depuis vSphere 4.0, un svmotion ne nécessite plus une phase de recopie de la ram grâce au “Fast Suspend/Resume” comme détaillé dans une session du vmworld 2009. Il ne nous restait donc plus que la piste de l’activité des vmdk mais la kb dédié à ce problème (Using Storage vMotion to migrate a virtual machine with many disks may timeout) fait référence à des messages d’erreurs aux quels nous n’avons pas été confrontés.
Dans le doute et n’ayant pas le temps d’investiguer d’avantage, nous avons augmenté les valeurs de “switchover time” pour vmotion et svmotion à l’aide de ce script PowerCLI, ce qui nous a permis de régler le problème :
Get-View -ViewType VirtualMachine|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmotion.maxSwitchoverSeconds";Value="200"});(New-Object VMware.Vim.optionvalue -Property @{Key="fsr.maxSwitchoverSeconds";Value="200"}))}))}
Le paramètre ”vmotion.maxSwitchoverSeconds”, nous l’avons trouvé dans les commentaires d’un post très intéressant du blog VMware Uptime au sujet d’une fonctionnalité peut connu de vmotion (vSphere 4.1+) : “quick resume“
In the event the VM passes the 100 second check, VMotion will stun the source and start running on the destination. While the destination runs, the source will transmit the remaining pages to the destination using the “quick resume” capability introduced with vSphere 4.1.
Vous avez bien lu, la vm de destination est démarrée alors le vmotion n’est techniquement pas terminé et les pages restantes sont migrées en tache de fond. Surpuissant.
Comme le précise Duncan dans son post concernant ce sujet, l’impact sur les performances en cas d’accès à une page restée sur la vm source (accès via le réseau donc) compense largement l’agilité de la solution dans la majorité des cas.
Tags: PowerCLI, scripting, SVMotion, troubleshooting, VMotion
Loading ...
April 14th, 2011 at 9:10
“Surpuissant”
+1
April 14th, 2011 at 15:08
Trop fort VMware!
Vas-y Microsoft essaye d’en faire autant
)
Just pulling your leg M$
April 14th, 2011 at 15:19
on peut toujours rêver
February 11th, 2013 at 19:35
Bonjour,
Cela est il toujours d’actualité pour vSphere 5.0 U1 ?
Qu’elle parametre a jouter afin de cibler l’aplication à une VM definie.
Merci,
February 17th, 2013 at 1:12
Salut Fouad, oui c’est toujours d’actualité et pour cibler à une VM tu peux remplacer “Get-View -ViewType VirtualMachine” par “Get-VM ta_vm | Get-View” au début du oneliner
February 21st, 2013 at 15:16
Thanks Nitro !!!!!
February 22nd, 2013 at 11:12
Thanks gain,
Une vielle Red-Hat 2.1 avec vieux Kernel, hardware 4, Unrunning Tools : Bref la galere car le Storage vMotion erreur sur erreur.
Grace à ce one liner c’est passé tous seul.
February 24th, 2013 at 0:03
@Fouad : avec plaisir
August 8th, 2019 at 13:28
[...] Vous l’aurez compris, si l’ESX source n’arrive pas à “dépiler” la vram suffisamment vite lors d’un vMotion, l’execution de la VM en question est ralentie jusqu’à ce qu’une convergence soit possible, dans la limite des timeout par défaut. [...]