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 :

En GUI, seuls “Link Status only” et Beacon Probing” ne sont disponibles pour le Failover des vSwitch et Port Group :

Ces 2 méthodes peuvent suffire dans la majorité des cas mais il existe d’autres paramètres disponibles en CLI uniquement :

checkSpeed = “minimum”
speed = 10
checkDuplex = false
fullDuplex = false
checkErrorPercent = false
percentage = 0

Il est donc possible d’exclure un uplink en fonction de sa vitesse, de son duplex et du pourcentage d’erreur CRC, ce qui peut être une excellente protection contre les mauvaises manipulations sur les switchs et contre les problèmes de câblage. Petite démo :

Extrait d’esxtop sur un ESXi, 3 uplinks sur le vSwitch dont 1 en 100 half (les 2 autres en 1000 full)

Vue du vSwitch0 en GUI

Résultat après la commande “vim-cmd hostsvc/net/vswitch_setpolicy –failurecriteria-speed=1000 vSwitch0” qui a exclu le lien en 100 half

Suivi d’un warning dans le vCenter :

Uplink redundancy degraded on virtual switch “vSwitch0″. Physical NIC vmnic1 is down. 2 uplinks still up.

Dommage que ces paramètres ne soit pas disponible en PowerCLI