The upgrade contains conflicting VIBs. Remove the conflicting VIBs or use Image Builder to create a custom upgrade ISO image that contains the newer versions of the conflicting VIBs, and try to upgrade again.

Il nous a fallu fouiller au fin fond des logs d’ESXi pour identifier les VIB en question :

Si vous lisez attentivement les release notes, vous savez déjà que depuis ESXi 5.1 il est possible d’upgrader avec la commande esxcli directement depuis le vib depot de VMware (William Lam a d’ailleurs écrit un post à ce sujet pour détailler le process) :

You can upgrade and apply patches to ESXi 5.0.x hosts by using the esxcli command-line utility for ESXi to upgrade to ESXi 5.1 from a download depot on vmware.com or from a downloaded ZIP file of a depot that is prepared by a VMware partner.

Nous avons donc tenté la même opération en ssh et l’erreur retournée par ESXCLI est nettement plus précise que celle de VUM :

Au passage, on attend toujours un plugin VUM digne de ce nom pour le webclient…

Disponible uniquement sur les resource pools dans le client legacy, cette vue synthétise l’utilisation “near real-time” cpu/ram du cluster des 5 dernières minutes (quickstats). Il suffit de créer un resource pool à la racine de votre cluster (sans reservations ni limites, les shares n’ont pas d’importances ici) pour avoir une visibilité comparable des ressources du cluster :

La vue “Guest Memory” se paye même le luxe d’être un peu plus détaillée graphiquement alors que la vue “Host Memory” est faussée par la mémoire allouée aux VM.

MAJ 29.01.2013 : On peut pousser encore un peu plus le tuning en baissant le Xmx java.

Si vous n’utilisez pas le webclient ni aucun autre composant reposant sur vCenter SSO ou si vous souhaitez réduire au maximum l’empreinte mémoire de votre lab, vous serez sans doute ravis de savoir qu’il est possible de désactiver SSO et revenir sur le mode d’authentification legacy pre-5.1 grâce au paramètre suivant :

config.vpxd.sso.enabled

En désactivant les services ssotomcat, vmwarelogbrowser, vimQueryService, vimPBSM et vspherewebclientsvc, vous ne perdez presque pas de fonctionnalité essentielle (à part l’onglet “Hardware Status”) mais vous pourrez diviser par 2 votre consommation de RAM :

]]> http://www.hypervisor.fr/?feed=rss2&p=4515 9 http://www.hypervisor.fr/?p=4283 http://www.hypervisor.fr/?p=4283#comments Sun, 21 Oct 2012 22:37:14 +0000 NiTRo http://www.hypervisor.fr/?p=4283 MAJ 21.02.2013 : Ajout de filtres pour les hosts vide afin d’éviter les divisions par 0.

MAJ 06.02.2013 : Debug des scripts.

MAJ 22.11.2012 : Nous avons oublié de préciser que pour que le script fonctionne correctement, le “statistic level” pour l’intervale de 5 minutes doit être à 2 minimum :

MAJ 23.10.2012 : Ajout d’un filtre dans les scripts pour ne modifier le(s) cluster que si nécéssaire.

Suite au post de Frank “distributed” Denneman traitant du sujet délicat des HA slot size “HA admission control is not a capacity management tool“, nous avons dépoussiéré une vieille idée de script de configuration automatique des “slot size” (mémoire et cpu) d’un cluster HA pour en faire un bon petit oneliner. L’idée est forcer le “slot size” à une valeur reflétant une vm moyenne du cluster afin de savoir approximativement la “place” restante dans le cluster et surtout pouvoir vraiment tirer parti de l’alarme “insufficient resources to satisfy HA failover level“

Nous avons fais nos tests sur un cluster de 6 ESXi 4.1 (4×4 cores 2.3Ghz & 64Go de RAM) contenant environ 150 VM sans réservations. Par défaut, voici ce qu’HA remonte comme information dans le vCenter :

Ces informations sont totalement erronés étant donné que le cluster est presque plein (en tenant compte du N-1 pour HA) mais c’est le comportement attendu d’HA lorsque les VM n’ont pas de réservations (l’overhead est pris en compte). On notera que le nombre de vcpu correspond à la plus grosse vm.

Voici ce qu’HA remonte après avoir passé notre script :

On est nettement plus proche de la vérité. Le calcul pour le cpu est la moyenne d’utilisation journalière par vm démarrée, idem pour les vcpu mais pour la ram nous avons du faire un choix pas trop optimiste (active memory) ni trop optimiste (consumed memory). Nous avons donc choisi de prendre la valeur médiane entre active et consumed (moyene journalière). Voici le résultat sur une journée de stat sur notre cluster de test :

Idéalement, ce script est donc à lancée une fois par jour. Voici la version pour vSphere 4.x (filtré par cluster où HA est activé) :

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}, @{n="vcpu";e={(($_.vm|%{get-view $_ -property Runtime,Config}|?{$_.Runtime.PowerState -eq "poweredon"})|%{$_.Config.Hardware.NumCpu}|measure -average).average}}|measure -average -property mem,cpu,vcpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.SlotNumVCpus";value=$_[2].tostring()}))})}),$true)}}}

Pour vSphere 5.0, le nombre de vcpu ne rentre plus en comptre pour le calcul du slot size, nous avons donc adapté le script en conséquence :

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}|measure -average -property mem,cpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne ($cluster.ConfigurationEx.DasConfig.Option|?{$_.key -match "das.slotCpuInMhz|das.slotMemInMB"}|measure -Sum -Property value).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=(New-Object VMware.Vim.ClusterDasConfigInfo -property @{option=@((New-Object VMware.Vim.OptionValue -property @{key="das.vmMemoryMinMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.vmCpuMinMHz";value=$_[1].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotMemInMB";value=$_[0].tostring()});(New-Object VMware.Vim.OptionValue -property @{key="das.slotCpuInMhz";value=$_[1].tostring()}))})}),$true)}}}

As of vSphere API 5.0, the number of vcpus is no longer used for slot calculations

Pour vSphere 5.1, le slot size est maintenant configurable dans via la GUI du web client (et donc de nouvelles propriétés sont disponibles) mais on va le faire en PowerCLI quand même

foreach ($cluster in (get-view -viewtype ClusterComputeResource -property Host,ConfigurationEx|?{$_.ConfigurationEx.DasConfig.Enabled})) {,($cluster.host|%{get-view $_ -property runtime,vm}|?{$_.Runtime.ConnectionState -match "^connected$"}|?{($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})}|select @{n="mem";e={(($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "active$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}) + ($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "consumed$"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count/1kb}))/2}}, @{n="cpu";e={($_|%{((get-view (Get-View ServiceInstance).content.PerfManager).QueryPerf((New-Object VMware.Vim.PerfQuerySpec -property @{entity = $_.moref;format = "normal";IntervalId = "300";MetricId = (New-Object VMware.Vim.PerfMetricId -property @{instance = "";counterId = (((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "usagemhz"}|?{$_.RollupType -match "average"}).key)})}))|%{$_.value}|%{$_.value}|measure -Average).average/(($_.vm|%{get-view $_ -property Runtime}|?{$_.Runtime.PowerState -eq "poweredon"})|measure).count})}}|measure -average -property mem,cpu|%{[math]::round($_.average,0)})|%{if (($_|measure -Sum).sum -ne (@($cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.SlotPolicy.Memory, $cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.SlotPolicy.Cpu)|measure -Sum).sum) {$cluster.ReconfigureComputeResource((New-Object VMware.Vim.ClusterConfigSpecEx -property @{dasConfig=((New-Object VMware.Vim.ClusterDasConfigInfo -property @{admissionControlPolicy=((New-Object VMware.Vim.ClusterFailoverLevelAdmissionControlPolicy -property @{slotPolicy=(New-Object VMware.Vim.ClusterFixedSizeSlotPolicy -property @{cpu = $_[1];memory = $_[0]});FailoverLevel = $cluster.ConfigurationEx.DasConfig.AdmissionControlPolicy.FailoverLevel}))}))}),$true)}}}

Ceux qui ont l’oeil auront certainement remarqué l’usage d’une “multidimensional array” (aka nested array) dans nos oneliner pour faire passer des tableaux au travers d’un pipe sans en changer le type.

Pour plus d’information sur HA, nous vous conseillons vivement la lecture de la série “Clustering Deepdive” de Duncan et Frank.

Get-Datastore vsp50sas01|Get-View|?{$_.Summary.Accessible -eq $true -and $_.Capability.StorageIORMSupported -and $_.Summary.MultipleHostAccess}|%{(Get-View (Get-View ServiceInstance).Content.StorageResourceManager).ConfigureDatastoreIORM_Task($_.MoRef, (New-Object VMware.Vim.StorageIORMConfigSpec -Property @{enabled="1"; congestionThresholdMode="automatic"; percentOfPeakThroughput="90"; statsAggregationDisabled="0"; statsCollectionEnabled="1"}))}

Ce oneliner permet, en plus d’activer SIOC en mode automatique, de jouer sur la proprieté “percentOfPeakThroughput” (90% par défaut), décrite dans le “What’s New in VMware vSphere 5.1 – Storage” :

The latency threshold is set to the value determined by the I/O injector (a part of SIOC). When the I/O injector calculates the peak throughput, it then finds the 90 percent throughput value and measures the latency at that point to determine the threshold.

De plus, dans la GUI, “Exclude I/O statistics from SDRS” correspond à la propriété “StatsAggregationDisabled“. Et “StatsCollectionEnabled” vous permettra de désactiver le mode “stats only” si vous êtes certain que le datastore ne fera jamais parti d’un storage POD datastore cluster et que vous souhaitez alléger votre VCDB.

Depuis leur apparition dans vSphere 4.0 en 2009 et jusqu’à aujourd’hui (malgré les nouvelles features exclusives), nous avons considéré les distributed switch comme des SPOF. L’idée de départ est très bonne mais la dépendance au vcenter nous paraissait trop importante, il était possible de lancer des actions irréversibles (sur le management network en particulier), de nombreuses kb vmware ont fait état de bugs assez gênant (surtout pour la v4.x) et nous avons toujours été inquiet de ne pouvoir presque rien faire en direct sur un ESXi en cas de problème réseau. VMware admet même le pire scénario (qui poussait les plus prudents d’entre nous à mixer standard/distributed lorsque le nombre de nic le permettait) dans  le “What’s New in vSphere 5.1 – Networking” :

However, in the VDS environment, where multiple hosts are connected to a distributed switch, any network failure or misconfiguration of the management port group can potentially disconnect all hosts from the vCenter Server system.
[...]
In vSphere 5.0, the only way for the user to recover from this situation is by going to individual hosts and building a VSS with a proper management network configuration.

vSphere 5.1 apporte, en plus d’une certaine maturité, toutes les fonctionnalités qui manquaient à DVS. L’une d’entre elles, nommé Host Networking Rollback, fera certainement changer d’avis les plus réticents (y compris nous-même). Pour faire court, cette feature “déjoue” automatiquement la dernière reconfiguration du stack réseau (standard ou distributed) qui aboutie à une déconnexion du vCenter :

Tout à fait logiquement, lorsque les ESXi recontactent le vCenter, le distributed switch annonce un “out of sync” du au rollback :

C’est là qu’une autre nouvelle feature (le Distributed Switch Rollback) rentre en scène et permet de restaurer la précédente configuration d’un distributed switch ou distributed portgroup. Attention, en cas de restart du vCenter, la dernière configuration est perdue.

When you use a VMware distributed virtual switch, each time you reconfigure the switch, the Server saves the switch configuration before applying the updates. If the vCenter Server is restarted, the saved configuration is not preserved and the method does not return a configuration specification.

Cette fonctionnalité n’étant accessible qu’avec le webclient, voici comment procéder en PowerCLI :

(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).ReconfigureDVPortgroup($(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).DVPortgroupRollback($()))

(Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).ReconfigureDvs((Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).DVSRollback($()))

Cette dernière action n’est d’ailleurs même pas possible en GUI, à moins d’avoir exporté la configuration du DVS dans un fichier.

Bonus : nous vous avons concocté un petit onliner pour créer une alarme afin d’être averti en cas rollback automatique sur les ESXi attachés à un distributed switch :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "vSphere Distributed Switch Rollback Event";Description = "Custom alarm to monitor vim.event.RollbackEvent Event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "vim.event.RollbackEvent";objectType = "HostSystem";status = "yellow"});)});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmare.local";Subject = "[vAlarm] {targetName} NetworkRollback Event - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false}))})});ActionFrequency = "1800"}))

Nous n’avons pas encore trouvé une solution correcte pour exporter la configuration des distributed switch/portgroup dans un fichier (le web client renvois un zip ressemblant à un vib), n’hésitez pas à nous remonter vos idées et/ou réactions sur le sujet.

Pour finir, il est maintenant possible de reconfigurer “automatiquement” la partie management network (standard ou distributed) via la DCUI :

Get-View -ViewType DistributedVirtualSwitch|?{($_.config.HealthCheckConfig|?{$_.enable -notmatch "true"})}|%{$_.UpdateDVSHealthCheckConfig(@((new-object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=1;interval="1"}),(new-object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=1;interval="1"})))}

Pour les admins qui aiment bien “aller voir si tout va bien ou pas”, il n’y a que le Web Client :

Et pour les autres, il y a les alarmes (par défaut) :

Bonus, vous pouvez changer l’intervalle par défaut (en minutes). Impossible en GUI

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.