En effet, après avoir activé l’autoExpand, le nombre de ports utilisables d’un DVPortgroup (en Static binding aka earlyBinding) se verra incrémenté automatiquement de 10 lorsqu’aucun port n’est disponible pour une nouvelle VM. Il y a également une fonction d’autoShrink décrite dans l’API Reference mais c’est une peu vague :

When this property is set to true, the portgroup becomes a potential candidate for auto-shrink. Once the portgroup has auto-expanded then its disconnected ports are likely to be deleted automatically, as a part of auto-shrink step, if there are more than certain number of free ports. If the portgroup never auto-expanded, then it will never lose any free ports.

Sachant que cette fonction est activé par défaut sur les DVSwitch 5.1, nous avons voulu vérifier si c’était également le cas lors d’une migration :

On constate donc que même après avoir upgradé le DVSwitch 5.0.0 en 5.1.0, l’autoExpand est toujours désactivé. Mais pas pour longtemps

Après analyse du script PowerCLI d’Arne et de l’API Reference, nous avons constaté que les DVUplinks “disposaient” de cette fonctionnalité (désactivée dans tous les cas et à ne probablement pas activer) car comme nous le confirme Steve Jin, ce ne sont que des DVPortgroup avec un tag spécifique (SYSTEM/DVS.UPLINKPG). De plus, lors de la reconfiguration du DVPortgroup, la propriété configVersion devrait être incrémentée. Et pour finir, en onliner c’est plus sexy :

Get-View -ViewType DistributedVirtualPortgroup|?{!($_.Tag|?{$_.Key -eq "SYSTEM/DVS.UPLINKPG"}) -and !$_.Config.autoExpand}|%{$_.ReconfigureDVPortgroup_Task((New-Object VMware.Vim.DVPortgroupConfigSpec -Property @{autoExpand="True";ConfigVersion=[int32]$_.Config.ConfigVersion+1}))}

Le script n’active la fonctionnalité que sur les DVPortgroup ne l’ayant pas déjà (hors DVUplinks) et incrémente la propriété ConfigVersion de 1 :

Et pour ceux qui voudraient savoir quand de nouveaux ports ont été ajoutés ou supprimés, il y a une alarme pour ça (Monitor : vSphere Distributed Swiches) :

]]> http://www.hypervisor.fr/?feed=rss2&p=4633 3 http://www.hypervisor.fr/?p=4240 http://www.hypervisor.fr/?p=4240#comments Sun, 30 Sep 2012 23:44:57 +0000 NiTRo http://www.hypervisor.fr/?p=4240 MAJ 27.02.2013 : PowerCLI 5.1 R2 contient 2 nouvelles cmdlet permettant l’export des des distributed switch/portgroup dans un fichier.

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