vSphere 5 introduces a new enhancement that ensures vMotion will not fail due to memory copy convergence issues. As noted in the “Architecture” section, transfer of the virtual machine’s memory contents during the vMotion process involves an iterative precopy procedure. In most cases, a precopy iteration should take less time to complete than the previous iteration. However, a pathological case where the virtual machine modifies memory faster than it can be transferred—due to workload characteristics or network infrastructure limitations—results in aborting vMotion in vSphere 4.1 and prior releases, because precopy fails to make forward progress. The enhancement in vSphere 5 slows down the virtual machine during such pathological cases and ensures that the memory modification rate is slower than the precopy transfer rate, thereby preventing any possible vMotion failures.

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.

Cette fonctionnalité semble parfaite pour les monster VM qu’on a du mal à évacuer lors d’un passage en maintenance mode mais elle est aussi très “problématique” lorsque l’infrastructure réseau n’est pas ou plus adaptée. D’où le très discret “network infrastructure limitations” dans le descriptif.

En l’occurence, le client en question mène une campagne de “refresh” de son parc afin de remplacer des machines ayant largement dépassé leur date de péremption technique. Mais sans faire évoluer son réseau. Il se retrouve donc avec machine de 2To de RAM sur un réseau 1GbE.

Evidement, à mesure que des VM de plus en plus grosses sont provisionnées sur ces environnements, les fenêtres de maintenance sont de plus en plus grande mais surtout des ralentissements apparaissent lors des mise en maintenance ou simplement quand DRS déplace de VM :

018-12-13T16:32:29.378Z cpu18:74031)VMotion: 4943: 7811810961774337297 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 693298, prev 461605, cur 497489, network bandwidth ~28.619 MB/s, 94% t2d)
2018-12-13T16:38:32.426Z cpu188:72874)VMotion: 4943: 7811810962073701659 S: Not enough forward progress, enabling SDPS (Pages left to send: prev2 126959, prev 18467, cur 15909, network bandwidth ~60.158 MB/s, 103% t2d)

SDPS fait son boulot et il le fait bien alors évidement pour faire passer des VM de 256Go qui bossent fort dans du 1GbE ca pique… Donc la prochaine fois qu’on vous dit que la bande passante de vmotion peut être sacrifiée, vous saurez quoi répondre.

Evidement, il y a un (mauvais) plan B :

To work around this issue, the Stun During Page Send (SDPS) feature can be disabled on a per-host basis.
[...]
Change the value of Migrate.SdpsEnabled to 0.

Nous en profitons pour souligner un autre “petit” détail du texte au sujet du Page Tracing :

During the pre-copy phase, the vCPU’s, in use by the virtual machine, are briefly stunned to install the page tracers.

Et voici le oneliner PowerCLI pour le faire vite et bien :

Get-View -ViewType HostSystem|?{$_.Runtime.ConnectionState -eq "connected" -and $_.config.product.ProductLineId -eq "embeddedEsx" -and ($_.Config.Option|?{$_.Key -eq "Misc.SIOControlLogLevel"}).Value -ne "1"}|%{(Get-View $_.ConfigManager.AdvancedOption).UpdateOptions((New-Object VMware.Vim.OptionValue -Property @{Key="Misc.SIOControlLogLevel";Value=[Int64]1}))}

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.

Nous avons concocté un script qui va, via la cmdlet Copy-DatastoreItem, copier le fichier vmware.log de la VM dans le répertoire temporaire de l’utilisateur, en afficher le contenu avec un code couleur en fonction de la source (vmx, vcpu, mks, etc…), recopier le fichier toutes les 5 secondes (paramétrable avec -delay=”x”) et en extraire à chaque fois le différentiel pour l’afficher à la façon de “tail -f“. Si le fichier vmware.log est locké ou déplacé pendant l’exécution du script (vmotion/svmotion par exemple), le script va bouclé jusqu’à ce qu’il soit de nouveau disponible et chercher le nouvel emplacement du fichier si besoin.

Dans la vidéo si dessus, les éléments successifs correspondent à des opérations (vmotion, snapshot, etc…)

L’intégralité de ce qui a été affiché dans la console est également redirigé vers un fichier log consolidé $env:temp\”nom-de-la-vm”-full.log (par ex : C:\DOCUME~1\admin\LOCALS~1\Temp\1\vm-full.log)

download

Function not implemented

La solution était caché dans une kb VMware sur le troubleshooting d’erreur lors de la creation d’un datastore :

Note: If you are using VMware ESXi or the <identifier> you are specifying is located within the /vmfs/ directory, you may need to append the conv=notrunc parameter to the dd command. Not doing so may result in a Function not implemented error.

Alleluia !

Après plusieurs semaines de troobleshooting et avec l’aide de la communauté vmware, nous avons pu identifier un effet de bord lié à la version des vmtools. Dans certaines circonstances, la DCUI d’ESXi peut crasher en raison de vmtools pas à jour. Par chance, l’hyperviseur n’en souffre pas donc les VM continuent à fonctionner mais les agents VPXA et AAM ne répondent plus. Seule solution, se connecter directement à l’ESXi avec le client VI (ou Vsphere) pour faire un shutdown des VM puis un hard reset du serveur physique car impossible de faire un restart.

Pour éviter cela, il est possible d’automatiser (si besoin) la mise à jour des vmtools au démarrage de la VM grâce à cette option :

Voici un petit script (piqué à Chris Nakagaki) pour le faire sur toutes vos VM sans peine (et activer la syncro de temps pour ceux veulent) :

get-vm  | foreach-object {
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
# $vmConfigSpec.tools.syncTimeWithHost = $true
(Get-View $_.ID).ReconfigVM($vmConfigSpec)
}

/!\ En cas de MAJ des vmtools, la VM reboot automatiquement /!\

/!\ Cette fonction n’est active que si des vmtools existent déjà dans la VM /!\