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.

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.

get-vm|?{$_.PowerState -eq "PoweredOn"}|%{move-vm -vm $_ -destination (get-random @((($vmhost = $_.Vmhost).Parent|get-view).host|%{get-view $_}|?{$_.Runtime.ConnectionState -eq "connected" -and !$_.Runtime.InMaintenanceMode -and $_.Runtime.StandbyMode -eq "none" -and $_.name -cne $vmhost.name})).name -whatif}

Pour être un peu plus précis, ce script va faire un vmotion sur un des autres ESX disponibles du cluster parent. OneLiner oblige, ce script ne tient pas compte des vm qui seraient déplacées par DRS avant son passage. Il est par contre nécessaire d’avoir un minimum de “mou” sur le cluster en question pour éviter une vilaine contention.

Dans l’état, le script vous affichera la liste des vmotion, il suffit d’ôter le “-whatif” et relancer pour agiter la pulpe

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.

Dans de rare cas de figure, vous aurez peut être à relier des VM par un lien réseau interne à l’ESX. Il vous faudra donc pour cela créer un vSwitch sans attachement physique comme celui-ci :

Sachez par contre que si vous devez maintenir ce lien au sein d’un cluster, en cas de vmotion vous aurez droit à cette erreur :

En effet, selon la kb VMware relatif à ce sujet :

VMware does not support VMotion migration of virtual machines that are connected to an internal only switch

Mais sur le forum VMware, un français nous donne la parade :

<migrate>
<test>
<CompatibleNetworks>
<VMOnVirtualIntranet>false</VMOnVirtualIntranet>
</CompatibleNetworks>
</test>
</migrate>
You have to create this section at the end of the vpxd.cfg file but still in the section <config>

Et un restart du service vpxd…

Chad (de chez EMC) à mis en ligne la vidéo de la session en question ainsi qu’une vidéo de démo sur son blog et Duncan (de chez VMware) vient de poster les pré-requis pour ce type de vmotion.

EMC a profité de cette session pour présenter un aperçu de l’avenir des baies symmetrix (Advanced Active/Active et Virtual Matrix) ce à quoi NetApp ne tardera surement pas à répondre.

Ron “Barracuda” Myers d’AMD nous fait une démo un peu foireuse de l’EVC (sous ESX 3 !?) d’un Barcelona à un Istanbul en passant par un Shanghai :

Les serveurs 8 sockets seront bientôt disponibles, comme par exemple le DL785 G6 d’HP :

Avec 48 cores et 1To de RAM sous ESX 4, on devrait pouvoir atteindre les 320 VM

Dès que les résultats VMmark seront dispo, nous en saurons un peu plus sur le bon rapport perf/prix promis par AMD…

Il faut rajouter dans la section <vpxd> du fichier C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg le paramètre suivant :

<ResourceManager>
<maxCostPerHost>16</maxCostPerHost>
</ResourceManager>

Suivi d’un redémarrage du service VMware VirtualCenter Server (vpxd).

Sachant qu’un vmotion “coute” 4 points (une migration à froid coute 1 point), la valeur souhaité doit etre multipilé par 4 (6 vmotion = 24 points). Cette valeur est à considérer par host, dans notre exemple nous autorisons donc 4 vmotions simultanés par host.

]]> http://www.hypervisor.fr/?feed=rss2&p=442 0 http://www.hypervisor.fr/?p=285 http://www.hypervisor.fr/?p=285#comments Thu, 06 Nov 2008 01:14:21 +0000 NiTRo http://www.hypervisor.fr/?p=285 MAJ 26/11/2008 : Mike DiPetrillo va plus loin encore sur son blog et donne la méthode pour désactiver totalement le cpu check de VMotion avec vidéo à l’appui.

L’update 2 de Virtual Center 2.5 offre une option fort intéressante permettant la compatibilité des CPU Intel/AMD pour le VMotion. Cette option baptisée EVC, pour Enhanced VMotion Compatibility, n’est malheureusement activable que sur les CPU récents (à partir des Intel 45nm Core 2 (Penryn) et AMD Second Generation Opteron -revision E or F-).

Pour permettre la compatibilité VMotion entre 2 hosts de génération différente, il existe une solution non supporté par VMware mais bien efficace : la modification du bit mask des VM.

Par défaut, le vCPU d’une VM possède les mêmes caractéristiques que le CPU du host qui l’héberge. Lorsqu’un VMotion est initié, Virtual Center verifie la compatibilité entre le vCPU et le CPU du host de déstination. Si les 2 cpu ne sont pas compatibles, le VMotion échoue immédiatement.

En modifiant le bit mask de la VM, il est possible de forcer le vCPU à masquer les caractéristiques du CPU. Ainsi, la VM peut etre déplacée à chaud mais ne jouira pas des mêmes caractéristiques d’un host à l’autre (le SSE3 par exemple). Au péril de la stabilité de la VM.

Nous allons modifier le bit mask d’une VM afin de rendre le VMotion possible entre 2 hosts Intel de génération très différentes :

Une tentative de VMotion entre ces 2 hosts se solde par l’erreur suivante :

Après une première modification du bit mask, on obtient une autre erreur :

Après une seconde modification du bit mask, le VMotion peut être effectué (malgré le warning pour les interfaces réseau) :

Voici les modifications effectuées dans l’ordre sur la VM :

Dans notre cas, voici le résultat en image :

avant :

après :

La KB VMware détaillant l’historique des posibilités sur les différentes versions de VC/ESX ainsi que les détails sur les différences Intel/AMD se trouve ici, le VMotion Guide se trouve ici et un exemple de compatibilité entre CPU là

Le slogan est encore meilleur :