Donc pour donner une url plutôt que de retaper une fois de plus l’explication, voici l’extrait du VMware Virtual Networking Concepts qui fait foi :

The speed and duplex settings found in physical networking are not relevant in the virtual network, because all the data transfer takes place in the host system’s RAM, nearly instantaneously and without the possibility of collisions or other signaling-related errors.

Et si vous en aviez encore besoin, en voici la preuve :

iperf win64 entre 2 cartes e1000 "bridée" à 100Mo

iperf entre 2 cartes vmxnet3

]]> http://www.hypervisor.fr/?feed=rss2&p=5822 1 http://www.hypervisor.fr/?p=5815 http://www.hypervisor.fr/?p=5815#comments Fri, 07 Jul 2017 11:03:29 +0000 NiTRo http://www.hypervisor.fr/?p=5815 Lors d’une petite session de PowerCLI avec les célèbres (mais bientôt deprecated) VIX APIs, nous nous sommes heurté à une limite de sécurité bien connue des admins Microsoft: le Kerberos Double Hop.

Pour résumer, nous avions besoin d’exécuter un script situé sur un share depuis un ensemble de VM et nous avons bien évidement tenté de profiter du fait que VIX supporte le SSO, comme des gros fainéants. Et là, c’est le drame:

When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn’t allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

Il nous a suffit de passer les credentials à l’Invoke-VMScript pour que l’UNC devienne accessible:

Due to changes in Microsoft’s virtual machine generation counter specification that was introduced in the Windows 8 Release Preview and Windows Server 2012 RC, corresponding changes were also required in the virtual machine BIOS. Snapshots, checkpoints and VMotion actions of virtual machines with these versions of Windows are not compatible between ESXi hosts that have implemented different revisions of Microsoft’s virtual machine generation counter specification.

Snapshots and checkpoints of virtual machines with Windows 8 or Windows Server 2012 that are taken on a host running ESXi 5.0 Update 1 or ESXi 5.0 P03 will not resume on a host running later versions of ESXi ( ESXi 5.0 Update 2, ESXi 5.1, etc.) and the reverse.

VMotion is prevented between hosts running ESXi 5.0 Update 1 or ESXi 5.0 P03 to and from hosts running later versions of ESXi.

2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Group ‘VMGenCtr’ not found.
2015-11-05T15:01:32.804Z| vmx| I120: CPT: could not find group VMGenCtr
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘AddrReg’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCount’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: DUMPER: Item ‘CtrCountX’ [-1, -1] not found.
2015-11-05T15:01:32.804Z| vmx| I120: VMGenCtrCheckpoint: Failing restore from old Win8 checkpoint
[...]
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.migration.failedReceive] Failed to receive migration.
2015-11-05T15:01:32.804Z| vmx| I120: [msg.checkpoint.mrestoregroup.failed] An error occurred restoring the virtual machine state during migration.

Evidemment la solution proposée par VMware passe par un shutdown de la VM mais lors d’une grosse migration ça fait pas sérieux donc nous avons cherché un vrai workaround.

Sachant que cette feature est exclusivement utilisé par Active Directory Domain Services (pourquoi l’imposer à toutes les VM d’ailleurs ?!), nous avons chercher à la désactiver pour que le resume du vmotion sur l’ESXi de destination ne pose plus de problème. Et pas plus loin que dans une autre kb vmware, nous avons trouvé la solution:

The workaround involving adding the vmGenCounter.enable parameter to the virtual machine .vmx file may cause the new snapshot protection for domain controllers introduced in Windows 8/Windows Server 2012 to stop functioning.

Un petit coup de PowerCLI pour appliquer le setting à chaud :

Get-VM Windows2012R2|Get-View|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmGenCounter.enable";Value="FALSE"}))}))}

Et le vmotion passe en douceur

<14>2015-09-04T22:03:39.616Z esx.vmware.com vobd:  [VisorfsCorrelator] 2274728093499us: [esx.problem.visorfs.ramdisk.full] The ramdisk ‘vsantraces’ is full.  As a result, the file /vsantraces/vsantraces–2015-09-04T21h31m52s079.gz could not be written.

[...]

<14>2015-09-04T21:00:53.492Z esx.vmware.com vobd:  [VisorfsCorrelator] 2269273677949us: [vob.visorfs.ramdisk.full] Cannot extend visorfs file /vsantraces/vsantraces–2015-09-04T19h34m10s776.gz because its ramdisk (vsantraces) is full.

La cause de ce problème est assez simple : booter ESXi via USB ou SD card = visor-thin = partition /scratch dans la RAM. Et quand vous n’avez pas de scratch persistante, la partition /vsantraces est configurée par défaut à 300MB comme vous pouvez le constater dans /etc/vmware/vsan/vsantraced.conf :

# Ramdisk size in MB (do not increase over 300MB without a matching increase
# to coredump size).
#VSANTRACED_RAMDISK_SIZE=300

Or comme l’explique Cormac dans son post VSAN considerations when booting from USB/SD :

VSAN traces require ~500MB of disk space.

Aprés quelques échanges avec le support VMware, il nous a été confirmé qu’il était possible et supporté de changer la taille de cette partition en modifiant vsantraced.conf, ce que nous avons pu tester et valider en l’augmentant à 500MB pour mettre fin aux erreurs :

GSS nous a cependant mis en garde :

Just be aware that if you do so, you also must increase coredump size by the same value.

Il nous a également fallu rediriger le workingdir de la commande vm-support (lorsque nous en avons besoin) pour éviter l’erreur suivante :

IOError: [Errno 28] No space left on device

Une autre info interessante sur le sujet : Handling VSAN trace files when ESXi boots from a flash device

esxcli software vib remove -n vib1 -n vib2 -n vib3

Et pour ceux qui veulent du lourd sur esxcli, jetez un un oeil au Quick Tutorial de Steve Jin.

Et on a bien fait, parce qu’on a même réussi à créer une partition VMFS sur une clef de boot ESXi 6.0 :

Pour que ça ait de la gueule, nous avons utilisé ce qui se fait de mieux en la matière : une clef USB 3.0 MX-ES SLC NAND Ultimate Endurance capable d’encaisser 180Mo/s en écriture.

La procédure est la même que pour créer un datastore en cli avec partedUtil et vmkfstools :

Et pour le fun, on a aussi essayer sur une clef Kingston/VMware ESXi “special” :

Nous vous laissons imaginer les possibilités que cette nouvelle “unsupported“ feature pendant que nous préparons un post qui n’attendait que ça pour voir le jour…

]]> http://www.hypervisor.fr/?feed=rss2&p=5461 3 http://www.hypervisor.fr/?p=5298 http://www.hypervisor.fr/?p=5298#comments Fri, 13 Feb 2015 07:54:16 +0000 NiTRo http://www.hypervisor.fr/?p=5298 MAJ 18/05/2016 : Finalement les Large Pages c’est vraiment pas top…

These issues are due to bug in large page promotion path on destination host during vMotion.

MAJ 22/10/2015 : Et encore des mecs qui confondent cloud et homelab…

All experiments run on a dual CPU blade server with two AMD Opteron 6272 CPUs (16 cores each) and 32 GB of RAM.

MAJ 26/02/2015 : Le patch pour la 5.0 vient de sortir, la boucle est bouclée.

Vous ne vous en êtes peut être pas rendu compte lors de votre dernière campagne de patching mais depuis mi-Octobre 2014, tout nouveau patch d’ESXi ajoute une fonctionnalité de salage pour TPS. Désactivée lors de son introduction mais bien destinée à être activée de force lors d’un patch ultérieur. Jusqu’à fin Janvier, seule la version 5.1 était concernée mais depuis le 27/01 la version 5.5 bénéficie aussi de cette nouvelle “feature”. La 5.0 est encore épargnée à ce jour.

As we noted earlier on Oct 16, Nov 24 and Dec 4, VMware has introduced new TPS (Transparent Page Sharing) management options. Today’s release of ESXi 5.5 U2d restricts TPS to individual VMs and disables inter-VM TPS by default unless an administrator chooses to re-enable it. Please see KB 2097593 for full details on the functionality.

Depuis l’annonce, beaucoup de bullshit. De nombreux blogeurs ont donné leur avis sur la question en omettant volontairement (aka je-suis-pas-un-expert-en-sécu) d’analyser les recherches qui ont abouti a cette rustine. Nous ne sommes pas expert en matière de sécurité non plus, par contre on ne va pas se gêner pour décortiquer les résultats de ces recherches et les critiquer. On commence par la kb 2080735 de VMware :

Published academic papers have demonstrated that by forcing a flush and reload of cache memory, it is possible to measure memory timings to try and determine an AES encryption key in use on another virtual machine running on the same physical processor of the host server if Transparent Page Sharing is enabled between the two virtual machines. This technique works only in a highly controlled system configured in a non-standard way that VMware believes would not be recreated in a production environment.

Even though VMware believes information being disclosed in real world conditions is unrealistic, out of an abundance of caution upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default

C’est pourtant clair mais VMware à quand même choisi de jouer la carte de la sécurité.

Une petit coup de Google nous a rapidement permis d’identifier les rapports de recherche à l’origine du mélodrame : Fine grain Cross-VM Attacks on Xen and VMware are possible! et Wait a minute! A fast, Cross-VM attack on AES dont les travaux semble basés sur un autre rapport datant de 2013 : FLUSH+RELOAD: a High Resolution, Low Noise, L3 Cache Side-Channel Attack

Extraits choisis du document de 2013 :

The technique uses the processor’s clflush instruction to evict the monitored memory locations from the cache, and then tests whether the data in these locations is back in the cache after allowing the victim program to execute a small number of instructions.

While copy-on-write protects shared pages from modifications, it is not fully transparent. The delay introduced when modifying a shared page can be detected by processes, leading to a potential information leak attack.

An important feature of the LLC in modern Intel processors is that it is an inclusive cache (NDLR : Et donc pas AMD). That is, the LLC contains copies of all of the data stored in the lower cache levels. Consequently, flushing or evicting data from the LLC also remove said data from all other cache levels of the processor. Our attack exploits this cache behaviour.

Retrieving data from memory or from cache levels closer to memory takes longer than retrieving it from cache levels closer to the core. This difference in timing has been exploited for side-channel attacks.

A round of attack consists of three phases. During the first phase, the monitored memory line is flushed from the cache hierarchy.

The spy, then, waits to allow the victim time to access the memory line before the third phase.

In the third phase, the spy reloads the memory line, measuring the time to load it. If during the wait phase the victim accesses the memory line, the line will be available in the cache and the reload operation will take a short time.

Maintenant qu’on en sait un peut plus sur la nature de l’attaque, voyons un peu les contraintes d’applications dans la vraie vie :

For a virtualised environment, the attacker needs access to a guest co-located on the same host as the victim guest. Techniques for achieving co-location are described by Ristenpart et al.
[...]
Identifying the OS and software version in co-resident guests has been dealt with in past research.

D’un coup de baguette magique, on se retrouve sur le même ESX avec le même GuestOS. Facile. On continue :

For the attack to work, the spy and the victim must execute on the same physical processor. For our testing, we set the processor affinity on the multi-processor system. However, in a real attack scenario the attack depends on the system scheduler.

Vous avez bien lu, la VM de l’attaquant doit résider sur le même processeur que la VM de la victime. Cache L3 oblige. Et c’est pas fini :

When performing the tests, the spy and the victim were the only load on the system. Such a scenario is not representative of a real system where multiple processes are running. We expect such load to create noise that will affect the quality of capture. Furthermore, for a load that includes multiple parallel instances of GnuPG, the spy will be unable to distinguish between memory access of each instance and will be unable to recover any data.

Donc, pour que l’attaque soit réalisable, il faut que la VM de l’attaquant se retrouve, avec la VM de la victime, seules sur le même socket du même ESX et avec le même GuestOS ! Et c’est toujours pas fini.

Extraits choisis du document sur l’attaque AES :

We know that VMware implements TPS with large pages (2 MB) or small pages (4 KB). We decided to use the later one, since it seems to be the default for most systems. Furthermore, as stated in [28], even if the large page sharing is selected, the VMM will still look for identical small pages to share.

Sachant que TPS ne supporte pas les large pages qui sont la configuration par défaut d’ESX depuis des années, non seulement ESX ne serait que partiellement vulnérable uniquement en cas d’overcommit important mais de plus le contexte initiale de l’étude est complètement faux.

Disabling the deduplication would make the attack impossible in the cloud however memory deduplication is highly performance beneficial, especially in cloud where multiple users share the same hardware. This is why we believe that the system designers should restrict the deduplication mechanism rather then completely disabling it.

Quel dilemme…

We not only performed the attack in native machine, but also in a cloud-like cross-VM scenario.

“cloud-like” et pourtant :

All experiments were performed on a machine featuring an Intel i5-3320M four core clocked at 3.2GHz.

Ironie du sort, un récent rapport de recherche décrit un nouveau type d’attaque sur le cache L3 en exploitant…les large pages !

S$A: A new deduplication free L3 cache side channel technique: We proposed a new side channel technique that is applied in the L3 cache and therefore can be applied in cross-core scenarios. The new side channel technique bases its methodology in the usage of huge size pages, which give extra information about the position that each memory location occupies in the L3 cache.

Prochaine étape : désactivation des large pages par défaut ou V2P en masse.

The relevance of these studies is highlighted by the prompt security update by VMware, making memory deduplication an opt-in feature that was formerly enabled by default.
[...]
We have disclosed our attack to the security teams of VMware, Amazon AWS and Citrix.

Mais revenons en au salting et à ses effets en cas d’overcommit. Sur un Dell R730 avec 256Go de RAM, nous nous sommes amusé à démarrer 512 VM SUSE 11 x64 1vcpu 2Go de vRAM avec des combinaisons de settings Mem.ShareForceSalting et Mem.AllocGuestLargePage différentes. Pour éviter que ça coince pendant le swapout, nous avons redirigé les vswp sur des SSD NVMe. On commence en mode défaut (Mem.ShareForceSalting=2 et Mem.AllocGuestLargePage=1) :

La courbe d’overhead (orange) permet de se rendre compte de la progression du démarrage des 512 VM. On remarque qu’au 3/4 du bootstorm le premier mécanisme de reclaim est la swap, viennent ensuite la compression, le ballooning et seulement après le sharing (principalement des zéros). Avec 23Go de swap et 43Go de zip, n’espérez pas des temps de réponses de folie même avec du SSD. On continue sans le salting (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=1) :

Avec plus de 100Go de sharing et seulement 3,6Go de swap les effets de l’overcommit (3:1 quand même) sont presque imperceptibles dans ce scénario même si on regrette de constater que le swapping est encore le 1er mécanisme à se déclencher. Maintenant passons en full small pages (Mem.ShareForceSalting=0 et Mem.AllocGuestLargePage=0) :

Là on est au top, 200Go de sharing et un démarrage tout en douceur sans swap, compression ni balloon. Et pour finir, notre fameuse technique du Large Page on Demand (Mem.ShareForceSalting=0 Mem.AllocGuestLargePage=1 et LPage.LPageAlwaysTryForNPT=0) :

Même chose mais avec “seulement” 143Go de sharing, la différence étant vraisemblablement attribuée à des large pages.

Moralité, optez pour un régime sans sel !

Historiquement, il suffisait de “zeroer” l’espace libre inGuest et faire un storage vmotion vers n’importe quel autre datastore pour récupérer l’espace “zeroé” grâce au datamover fsdm qui zappe les zéros. Malheureusement, depuis l’apparition du datamover fs3dm dans vSphere 4.0 cet avantage a disparu comme l’explique Duncan dans un vieux post de 2011.

A cette époque, il était courant d’avoir des datastores configurés avec des blocksize différents ce qui permettait de contourner le problème facilement. Aujourd’hui, VMFS 5 a changé cette approche avec le blocksize unifié à 1M.

Pour tricker comme avant et forcer fsdm à faire le boulot il faut une rupture technologique VMFS <> NFS ou jouer avec un paramètre caché de vsish comme l’indique William Lam dans son commentaire :

Whether VMFS should handle data movement requests by leveraging FS3DM

Et depuis le temps que nous voulions le tester, nous sommes enfin tomber sur une VM avec ~60Go à récupérer dans un environnement VMFS5 only:

Un coup de sdelete -z plus tard, on change le paramètre /config/VMFS3/intOpts/EnableDataMovement dans vsish et on lance un storage vmotion.

Au passage on remarque bien la phase de lecture sans écriture pendant le svmotion :

Après la migration (qui vous permettra aussi de renommer officiellement les fichiers de votre VM), la VM a maigri comme il faut :

Pour ceux qui voudrait tout simplement le faire offline, il y a l’option –punchzero de vmkfstools.

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 30/07/2014 : VMware vient de nous informer de la prise en compte du bug (PR 1286205) et que le correctif sera dispo Q4 2014 dans le patch 3 d’ESXi 5.5 :

Customer observed ESXi PSOD when polling IP-MIB. snmpd calling NetVsi_TcpipSysctlGet

Hormis la fameuse commande crashMe de vsish, il est généralement très difficile de reproduire un PSOD à la demande. Pourtant, nous avons trouvé un cas assez violent où l’utilisation de SNMPv3 via cacti fait crasher l’ESX de façon systématique et ce sur toutes les version depuis la 5.1 :

Evidemment, VMware est sur le coup. Pour info, nous avons utilisé le “walk through” de William pour la configuration.

La seule référence que nous ayons pu trouver à ce sujet est une kb d’un path pour ESXi 5.0, dommage.

En passant, nous vous rappelons qu’il est possible de rediriger le log d’une VM vers le syslog d’ESXi pour vous éviter de fouiller dans le fichier vmware.log et c’est bien sûr faisable à chaud en PowerCLI (comme d’hab, vmotion pour appliquer le setting) :

Get-VM toto|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="vmx.log.destination"; Value="syslog-and-disk"}))}))}

Après on peut faire des belles requêtes dans son Graylog2 :

Un grand merci à William pour cette pépite.

Follow the Migrate Virtual Machine Wizard to select the ESX 3.0.1 host and VMFS3 datastore destination. The Wizard validates the destination and moves the configuration files of the virtual machine and virtual disks to the new VMFS3 datastore.

Depuis, nous avons étudié, testé, troubleshooté, et utilisé en production (de manière parfois intensive) cette fonctionnalité (qui a beaucoup évolué depuis 2007) devenue presque banale depuis SDRS.

C’est au moment où nous croyons tout savoir du mécanisme que nous prenons une grande claque d’humilité lors d’une migration de plusieurs centaines de VM et que nous nous apercevons pour la première fois qu’un svmotion d’un vmdk thin (ou Lazy Zeroed) génère 2 fois plus d’écritures que de lectures :

Nous n’avions jamais fait le rapprochement entre un svmotion et un sujet qui a longtemps fait polémique :

Because zeroing takes place at run-time for a thin disk, there can be some performance impact for write-intensive applications while writing data for the first time.

Et le pire c’est qu’il nous a fallu un temps infini à l’échelle de Google pour tomber sur un thread reddit où un VCDX explique tout d’une seule phrase :

It has to zero the block before writing the actual data.

Voila pourquoi sans VAAI (ou au moins la primitive WRITE_SAME) vos svmotion (thin ou lazy zeroed) prendrons 2 fois plus de temps car 2 fois plus de données transiterons vers le stockage (entre 2 VMFS avec le même blocksize).

A titre de démonstration, voici un visualEsxtop de 2 svmotion consécutifs de la même VM entre 2 datastore, avec et sans le setting DataMover.HardwareAcceleratedInit :

Ce n’est pas une défaillance de votre téléviseur, avec le zeroing offloadé à la baie c’est presque 2 fois plus rapide (ou 2 fois moins long si vous préférez…).

Ce comportement n’a évidement aucun rapport avec la “non-récupération” des zéros lors d’un svmotion… Bien qu’il semble etre possible de le forcer d’une manière non supportée !

Evidemment il y a un algorithme complexe, du paramétrage et des seuils variables pour rendre le mécanisme suffisamment intelligent mais dans le cas d’un cluster pas ou peu overcommité (cpu et/ou ram uniquement), le déséquilibre est une situation “normale” puisque le coût d’un vmotion sera presque toujours supérieur a son bénéfice. DRS estime le gain à partir de la demande des vm et n’a de raison d’agir que si elles ne peuvent pas obtenir les ressources demandées. Le bon nivellement des VM dans le cluster n’est absolument pas pris en compte. De plus, DRS fait une projection de ce que la vm pourrait consommer dans un futur proche en fonction des statistiques passées afin de ne pas réagir trop tard.

Néanmoins, dans certains cas il peut s’avérer nécessaire de forcer DRS à “secouer” un peu le cluster pour répartir les vm. Après une opération de maintenance ou de façon proactive (moins de vm par host=moins de conséquences en cas de crash) ou encore pour niveler les I/O disque/réseau pas (encore) pris en compte par DRS.

Nous nous sommes justement retrouvés dans cette situation suite à l’ajout de plusieurs host dans un cluster 5.0 U1 et face à l’immobilisme de DRS, nous nous sommes souvenus d’un post détaillé de Frank à ce sujet faisant référence à une kb vmware.

This issue may occur in an environment with a large number of relatively low demand virtual machines

Il s’agit de modifier *temporairement* les paramètres MinGoodness et CostBenefit pour que DRS déclenche un vmotion à la moindre occasion sans en considérer le coût. le résultat est immédiat :

Depuis vSphere 5.1, l’algorithme de DRS à été modifié pour palier à des situations similaires (vSphere 4.1 U3 et vSphere 5.0 U2 intègre aussi la modification) mais il est toujours possible de forcer si besoin avec d’autres paramètres :

Starting with this release, DRS algorithm is improved to better balance the load in a DRS cluster. If you notice that the cluster is still not balanced with the default settings, you can configure the advanced DRS options with the following values and run DRS to further improve the load balancing capability of the DRS cluster:

SevereImbalanceDropCostBenefit 1
FixSevereImbalanceOnly 0

Malheureusement la page de ce fling n’existe plus (même si l’outil est toujours disponible) mais nous avons trouvé son équivalent en PowerCLI au détour de 2 kb traitant de SIOC (ici et là). Il s’agit d’un module powershell qu’il suffit de charger avec la commande “Import-Module” et vous aurez ensuite accès à 2 nouvelles cmdlet (Get-PxCounterLevelMapping et Set-PxCounterLevelMapping) pour opérer les changements désirés.

A titre d’exemple, voici le niveau par défaut du compteur mem.active.average dont nous parlions plus haut :

Après exécution de la commande magique, le résultat (avant/après sur les graphiques) :

Get-PxCounterLevelMapping|?{$_.Name -eq "mem.active.average"}|Set-PxCounterLevelMapping -AggregateLevel 1

Ces modifications auront des conséquences sur la taille et peut être les performances de la base de données de votre vCenter mais ce sera toujours mieux qu’une augmentation “globale” qui entraînera la collecte de compteurs dont vous n’aurez peut être jamais besoin…

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 :

Une kb vmware couvre le sujet mais les 2 workaround sont particulièrement déplaisants. Au choix, unregister/register de la vm (arrêtée sinon c’est pas drôle) ou modifications dans la base du vcenter (arrêté sinon c’est pas drôle non plus).

Pour rappel, un unregister une vm du vcenter vous fait perdre les stats et les custom fields mais induit aussi un changement de moref qui peut également entraîner de conséquences importantes comme une perte des règles d’affinités DRS ou encore une appartenance à un job de backup.

N’ayant pas pour habitude d’accepter ce genre de solutions sans chercher un moyen de contournement pour éviter un downtime ou une perte d’information quelconque, nous avons fini par trouver la solution simplement dans la description du problème :

This issue occurs because the entries from VPX_DISABLED_METHODS are not removed after a virtual machine backup task completes.

Vous l’aurez deviné, un nouveau backup (réussi) de la vm a corrigé le problème et nous avons pu continuer la migration.

MAJ 24/01/2012 : La version 841.k1.34.1-1vmw semble régler le problème car les cartes sont détectées et fonctionnelles.

A nos dépends, nous nous sommes aperçu que le driver async 841.k1.28.1-1vmw fourni par Qlogic (via le site de vmware) pour ESXi 4.x n’était pas compatible avec les cartes QLogic 8Gb Fibre Channel Expansion Card (CIOv) ISP2532 (QMI2582) pour blade IBM (extrait de /var/log/message just après le boot) :

qla2xxx 0000:24:00.0: Found an ISP2532, irq 184, iobase 0×0x4100a0a02000
qla2xxx 0000:24:00.0: Configuring PCI space…
qla2xxx 0000:24:00.0: Configure NVRAM parameters…
qla2xxx 0000:24:00.0: ZIO mode 6 enabled; timer delay (100 us).
qla2xxx 0000:24:00.0: Verifying loaded RISC code…
qla2xxx 0000:24:00.0: ISP System Error – mbx1=1ff7h mbx2=10h mbx3=3h mbx7=0h.
qla2xxx 0000:24:00.0: Failed to initialize adapter

Nous avons par ailleurs trouvé une kb très proche de ce bug mais pour ESXi 5.0 : ESXi 5.0 async QLogic driver 911.k1.1-19vmw fails on 8G fiber channel IBM Mezzanine Card.

Heureusement pour nous, point besoin de “Press Shift+R when rebooting” ou de “Re-install ESXi” car un simple remove du vib avec la commande “esxupdate” (“esxcli software vib” pour la ESXi 5.0) fera largement l’affaire :

On attend le retour de VMware à ce sujet…

]]> http://www.hypervisor.fr/?feed=rss2&p=3567 0 http://www.hypervisor.fr/?p=3561 http://www.hypervisor.fr/?p=3561#comments Tue, 17 Jan 2012 00:19:25 +0000 NiTRo http://www.hypervisor.fr/?p=3561 MAJ 09/02/2011 : le patch 3 fraîchement disponible corrige enfin les derniers gros bugs de la v6, mais pas tous…

If you plan to use Direct SAN access mode, are running a localized version of Microsoft Windows, or are upgrading from a previous version of Veeam Backup & Replication, consider installing the patch.

Vous n’avez sans doutes pas pu passer à coté du lancement de la version 6 de Veeam Backup & Replication tant la liste de nouvelles features est impressionnante. La capacité à faire un failback sur les jobs de réplication, le support d’Hyper-V (avec “CBT” via un driver “made in” Veeam) et le changement d’architecture (proxy/server/repository) étant les 3 changements majeurs.

Attention toute fois, la v6 souffre encore de quelques bugs (plusieurs patch successifs ont été mis à dispo par le support veeam) qui en ont même découragé certains, nous y avons d’ailleurs dédié un short link : vm.lc/v6

N’hésitez pas à utiliser notre script de linked clone pour tester vos upgrades.

Comme toujours, c’est dans les petits détails que l’on peut juger de la finition d’un produit :

Avec le nouveau report de la v6, adieu les taux de transferts cosmique qui plaisait tant aux commerciaux…

Et pour inaugurer notre nouveau slogant “There’s A One-liner For That”, en voici un qui aura sa place dans vos taches planifiés pour “retry” un job “failed” :

Get-VBRJob|?{$_.GetLastResult() -eq "Failed"}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

Le problème en question concerne l’arrêt du daemon vmsyslogd lorsque le datastore désigné pour accueillir les logs n’est pas accessible (ou a été indisponible trop longtemps). La kb 2003470 fait état du problème lorsque l’ESXi est en boot from SAN mais le problème est identique lorsque le paramètre Syslog.global.logDir pointe vers un datastore NFS qui serait indisponible lors d’une coupure réseau.

Ce problème est d’autant plus fâcheux (mais en même temps évident) que c’est ce même daemon qui transmet les messages au Syslog.global.logHost, ce qui signifie que si vous devez troubleshooter un effet de bord suite à une coupure réseau ou SAN trop longue et que vous redirigiez les logs sur un datastore “remote”, vous n’avez plus de logs pour le faire. Et VMware voudrait vous faire rebooter rien que pour ça !

Heureusement, le reboot peut être facilement évité en faisant un reload du daemon ou (si le process à été tué ou si le watchdog n’a pas réussi à relancer le process) en lançant manuellement le daemon (le reload génère une erreur lorsque le process ne tourne plus) :

esxcli system syslog reload

/usr/lib/vmware/vmsyslog/bin/vmsyslogd

Un petit détail en passant, sur la version embedded d’ESXi 5.0 le daemon syslog n’est pas configuré (/scratch/log par défaut) si la partition scratch est absente :

Autre petit détail intéressant, contrairement aux précédentes versions d’ESXi, vous pouvez maintenant utiliser le même chemin pour tous vos ESXi et activer le paramètre  Syslog.global.logDirUnique qui créera automatiquement un sous répertoire au nom FQDN du serveur pour y placer les logs.

Dernier point qui a également son importance, le “format syslog” d’ESXi est nettement mieux respecté dans cette nouvelle version ce qui permet d’améliorer le filtrage lorsqu’on redirige vers une plateforme type rsyslog+loganalyzer :

]]> http://www.hypervisor.fr/?feed=rss2&p=3387 0