En effet, à la lecture du titre de cette news “Using PowerShell Direct and other new features in Hyper-V on Windows 10” on s’attend clairement à un truc révolutionnaire. Vous ne pouvez pas dire le contraire, “Powershell Direct” ça claque !

Alors, naïfs, on se précipite sur TechNet pour en savoir plus ! Mais là, comme pour le coup du Smart Paging, c’est le drame :

It is a new way of running PowerShell commands inside a virtual machine from the host operating system easily and reliably
[...]
Note: This only works from Windows 10/Windows Server Technical Preview Hosts to Windows 10/Windows Server Technical Preview guests.

Bon là on ne va pas y aller par 4 chemins, on est sur du réchauffé++ car je rappel pour ceux qui n’étaient pas encore nés que cette feature existe chez VMware depuis 2009 :

Invoke-VMScript: Runs the specified PowerShell script in the guest OS of each of the specified virtual machines.

Et depuis 2011, elle supporte le SSO :

All VIX cmdlets support using SSPI for Windows guest machines if the underlying vCenter Server is 5.0 version. This might not be valid for users who are local, and not domain users. VIX cmdlets are Invoke-VMScript, Copy-VMGuestFile, *-VMGuestNetworkInterface, *-VMGUestRoute, and Set-HardDisk when used for guest disk resizing.

Et pour ceux qui l’ignorait, ce n’est évidement pas limité à Windows comme c’est le cas d’Hyper-V :

ScriptType: Specify the type of the script. The valid values are PowerShell, Bat, and Bash. If the virtual machine OS is Windows, the default value is PowerShell. If the virtual machine OS is Linux, the default value is Bash.

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

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

Afin d’avoir une meilleure visibilité sur ce qui change au moment où nous avons activé le paramètre et lancé une vague de vmotion au sein du cluster pour l’appliquer, nous avons utilisé les mêmes compteurs que le “dashboard” Guest Memory (aka ResourcePoolQuickStats) pour en faire un rrd sous cacti (avec les même couleurs) :

Un gain immédiat de 20% de RAM sans consommation CPU supplémentaire ni augmentation manifeste de latence (dans notre cas) :

Et pour ceux qui se posent la question, dans ce cluster cumulant 1.5To de RAM attribuée à des VM Windows 2008 R2 et RHEL 6 x64, seulement 40Go de Large Pages sont allouées en moyenne.

Moralité, TPS c’est bon, mangez-en !

• No more vRAM (5.0+)
• In vSphere 5.1, the VMware vSphere Web Client is the new primary point for vSphere management
• 64 vCPU support
• vGPU support (NVIDIA + view)
• SE sparse disk (Guest OS Storage Reclamation)
• vMotion and Storage vMotion in one operation
• Zero-downtime upgrade for VMware Tools (5.1+)
• The vSphere Web Client adds support for interrupt-driven workloads
• Maximum number of hosts that can share a read-only file on a VMFS is increased to 32
• In vSphere 5.1, a new time-out value for APD is being introduced
• VMware provides a generic SMART plug-in in vSphere 5.1
• Automatically SIOC tuning congestion threshold
• SIOC correlation detector
• Auto Deploy “stateless caching” and “stateful installs”
• VDS Configuration Backup and Restore / automatic rollback and recovery
• LACP support
• Network Health Check
• SR-IOV support
• vSphere 5.1 has introduced the ability to swap out and reduce the memory reservation for several of the vSphere backend processes
• Latency Sensitivity Feature

VMware a également ”gratuifié” vSphere Replication sans SRM mais la VR appliance reste mandatory contrairement au modèle d’Hyper-V Replica, ce qui nous apparaît donc comme une piètre riposte de dernière minute…

En toute honnêteté, pendant 2 secondes nous avons pensé à une killer feature qui permettrait de placer automatiquement la swap du GuestOS sur un vdisk à part ou quelque chose d’encore plus ingénieux. On y croyait vraiment à mort tant la feature list d’Hyper-V 3 est impressionnante (pour un produit “gratuit”).

Mais non, c’est juste le fichier de swap de la vm qui va avec une autre nouvelle fonction “minimum memory”. Je vous laisse apprécier le descriptif :

Dynamic Memory improvements include support for configuring minimum memory, and Smart Paging, which is a memory management technique to provide a reliable restart experience for virtual machines configured with less minimum memory than startup memory.
[...]
Smart Paging uses disk resources as additional, temporary memory when more memory is required to restart a virtual machine than the amount of memory currently allocated to a virtual machine.

Ça c’est du dépoussiérage de feature où on s’y connait pas ! Mais c’est pas fini, on vous a gardé le meilleur pour la fin :

To minimize the potential performance impact of Smart Paging, HyperV uses it only when all of the following occurs:

1. The virtual machine is being restarted.
2. There is no available physical memory.
3. No memory can be reclaimed from other virtual machines running on the host.

Et on vous rafraîchi la mémoire sur ce qu’M$ pensait de l’overcommit quand Hyper-V n’en était pas capable :

What this means is while Memory Overcommit has its uses in certain configurations, it’s not a panacea for virtualization administrators. Memory Overcommit should be used judiciously and only when absolutely necessary.

• Average virtual machine to physical host  consolidation ratio : 5,1
• Primary Hypervisor usage for Desktop virtualization : 54,2%
• Reasons given for changing primary hypervisor  for Server virtualization - Features offered by alternative hypervisors : 47,4%
• Main concerns preventing increased virtualization – Backup and restoration: 33%

On note l’absence totale de l’aspect “sécurité” pour les “Main concerns preventing increased virtualization” et le taux de consolidation moyen dramatiquement bas.

L’excellent whitepaper d’Aidan Finn nous permet de comprendre à quel point la partie backup d’Hyper-v R2 est loin d’être idéale. Si vous n’avez pas d’Hardware VSS provider, vous “pourriez” utilisez le Software VSS provider d’Hyper-V R2 si vous avez envie de voir les performances de votre infrastructure s’effondrer :

Redirected Mode is active from the time that the backup job starts until the backup job completes

C’est à dire que pendant TOUTE la durée du backup, TOUT le trafic disque de TOUTES les VM est redirigé en SMB, par le réseau, vers le CSV coordinator ! Et, pire encore :

We recommend that virtual machines deployed on CSV should be backed up serially

En admettant que vous ayez un Hardware VSS provider, vous aurez quand même droit à un petit flood réseau :

Redirected Mode only takes place for the time it takes the SAN to create a snapshot of the LUN containing the CSV volume

Et nous avons gardé le meilleur pour la fin :

If the virtual machine’s Dynamic VHDs need to expand then the CSV Coordinator will have to start Redirected Mode for the entire CSV so it can perform the expansion of the VHD.

C’est à dire que si vos VM sont en thin provisioning, à chaque fois qu’un VHD doit grossir, TOUT le trafic disque de TOUTES les VM du CSV passe par le réseau en SMB pendant la durée de l’opération. La grande classe.

Et si le thin provisioning ne vous fait vraiment pas peur, à plus ou moins court terme le CSV sera fragmenté, et là c’est le drame :

Fragmentation leads to greater latency for read operations. You can defrag the physical storage volumes. In the case of a CSV, that means that the CSV will be in Redirected Mode for the length of the defrag operation

Alors, la prochaine fois qu’on vous parle d’Hyper-V, souriez

MAJ 29/07/2011 : Veeam nous a confirmé que le ratio est bien vm/hyperviseur et qu’ils sont aussi surpris que nous le sommes de ce chiffre d’autant plus que radio moquette est au taquet avec les rumeurs autour des modifications de licencing VMware…

MAJ 19/07/2011 : Ayant mal interprété les informations, nous avons contacté Veeam pour plus de précisions.

En plein délire autour du nouveau mode licensing de VMware, Veeam vient de lancer V-index, un genre de baromètre de la virtualization qui sera mis à jour tous les trimestres.

En plein milieu de la home page, le taux de consolidation moyen de 544 grands comptes : 6:1 vm/host, c’est à dire à peine plus que ce que VMware avance mais que personne ne semble croire au moins la moitié de ce que VMware annonce (on suppose que la moyenne est supérieure à 2 sockets par host) :

The average number of VMs per physical processor is 5.7. I know this may be counter-intuitive to some customers who are pushing the envelope, but the detailed distribution of consolidation ratios is on the graph below.

Encore plus fort, le taux de consolidation “percu” (si, si !) serait supérieur au taux de consolidation réel, 9,8 contre 6,3 (déja on gagne 0,3 en passant de la home au détail) :

Perceived consolidation ratio based on respondents’ own assessment. Actual ratio based on calculation of number of virtual machines divided by number of physical hosts for each individual respondent. Hence perceived consolidation differs from actual.

On y apprend aussi que XenServer serait mieux implanté de 2% qu’Hyper-V, fraîchement entré dans le carré VIP des Leaders selon la boule de cristal de Gartner…

C’est quand meme sympa de la part de Veeam vous ne trouvez pas ?

Et pour ceux qui ne serait pas fort  en calcul mental, un petit quote des commentaires enflammés de futur ex-client VMware :

Also, vSphere 5 supports 1 TB of RAM in a VM, but why would I virtualize that server if I have to pay VMware 22x Ent Plus licenses at $3,500 ($77,000) to run that much RAM in a VM? Why wouldn’t I just save the $77K and keep it a physical server…?

Ça aurait été mieux un pigeon comme logo plutôt qu’un mouton non ?

L’initiative pourrait rester valable si elle n’était pas gavée de gros morceaux de bullshit comme ce magnifique tableau comparatif :

Notre bullshit-o-meter, déjà dans le rouge, a totalement grillé sur la séquence comparative Core Parking vs DPM (extrait ci-dessus). Notre brave Symon (“Microsoft Technical Evangelist” en chemise bleu) semble persuadé qu’un serveur allumé consomme autant qu’un serveur éteint (où l’inverse). Et pourtant :

The Core Parking feature allows Windows Server 2008 R2 to consolidate processing onto the fewest number of possible processor cores, and suspends inactive processor cores

Même si le CPU représente une part non négligeable de la consommation d’un serveur, il n’est question en moyenne que d’1/4 à 1/3 de la consommation totale. Mais quelque chose nous dit que M$ a fini par s’en apercevoir, ils n’ont juste pas encore prévenu Symon. Néanmoins, pour pouvoir consolider au maximum il faut un peu mieux que Dynamic Memory…

Démonstration avec un cluster, hébergeant 66 VM (W2K3 – 2Go), composé de 12 serveurs bi Xeon 5345 + 8Go de RAM sous ESXi 4.1 build 348481. Les VM de ce cluster devant etre dispo à 100% entre 8h et 19h, Distributed Power Management est programmé dans vCenter pour s’activer à 20h et se désactiver à 7h (hors WE). Résultat, 9 serveurs sur 12 OFF (pour Symon, ça veut plus d’électricité du tout) en heures creuses, c’est à dire 60% du temps dans notre cas :

Evidemment, impossible d’atteindre ce taux de consolidation hallucinant de 600% sans l’aide de TPS, Ballooning, Memory compression et Hypervisor swapping :

Ça, c’est du GreenIT et c’est dispo depuis 2008 !

Mais maintenant que les migrations commencent sur les environnements de production, un problème lié au stockage (pas encore clairement identifié) à été signalé vendredi sur Twitter. Ca va même très loin pour certains :

[...] in my case running a validation report even damaged the MBR record on the LUNS making them inaccessible to Cluster Shared Volumes. So I lost a good part of my production Hyper-V servers (Thank you back-up).

Testez bien avant de patcher, ou migrez vers ESX avec vCenter XVP Manager

“This time it’s gonna be different. Trust me.”

Et en juin, on fêtera les 3 ans d’Hyper-V : youpi !

Nous ne résistons pas à la tentation d’une citation de notre morceau favoris de l’interview de Bernard Ourghanlian (Directeur Technique et Sécurité de Microsoft France):

[à propos du projet MinWin] C’est un travail qui est assez colossal, puisque cela nécessite de complètement dénouer l’espèce de « plat de nouilles » qui est aujourd’hui présent dans le noyau Windows pour des raisons historiques, notamment liées à la version d’Internet Explorer dans Windows.

In this scenario, VMware vSphere favors fairness over throughput and sometimes pauses one vCPU to dedicate a whole core to another vCPU, eliminating gains provided by Hyper-Threading

Après avoir fourni un patch ainsi que 2 paramètres d’optimisation, l’équipe de Project VRC à publié cette fameuse mise à jour qui “restaure l’équilibre” :

The vSphere 4.0 Update 1 P05 patch clearly has positive impact on TS 2008×64 workload with 4vCPU’s. The performance differences are now very small [...] In practice, performance will be equal for all hypervisors when 4vCPU’s are used with Hyper-threading.

Dans le même temps, Citrix publie un bench VDI maison (avec un schéma où l’on peut voir Hyper-V en NFS et du VHD avec ESX…) où Hyper-V fait le meilleur score pour Win7 (admirez l’échelle) mais le moins bon pour WinXP et pourtant Citrix conclu :

First, it is clear that the industry’s two leading hypervisors for these benchmarks for both TS and VDI, are Hyper-V R2 and XenServer 5.5.

Et concernant Virtual Reality Check – Phase II version 2.0, une petite touche d’humour :

The results clearly stung the VMware folk who rushed out a patch that they claim fixes their TS performance issues, but they have yet to disclose whether this affects their VDI performance, and we have yet to test it.

On peut constater clairement que la suite d’événements autour de ce fameux patch #5 légitiment les résultats des benchmark de Project VRC. Quant à VMware, tout laisse à penser que l’éditeur tient autant à son image qu’aux résultats de son hyperviseur. Et concernant le patch en lui même (dispo public depuis le 01/04/2010) nous partageons l’avis de Scott :

Of course production environments rarely (never?) have a one-to-one ratio of vCPUs to logical processors.

Bien que les auteurs rappellent que ces résultats ne peuvent être sortis du contexte TS/ICA, ils n’en restent pas moins surprenants :

En 32bit, vSphere domine.

En 64bit, le baremetal domine et vSphere se fait devancer de ~20% !

Le Gain nextgen hyperviseur/hardware est spectaculaire

Une lecture incontournable…

VMware, soucieux de conserver son avance en la matière, ajoutera un nouveau mécanisme de memory overcommit dans sa future version : la “memory compression”. Il s’agirait d’une compression dynamique de pages, ultime étape avant le swapping.

HyperviZor.com a d’ailleurs dédié un superbe diagrame à ce sujet :

La VM à migré sans interruption, tout le monde est en plein extase : bienvenue en novembre 2003 !

Couts en $ / VM (128Go/ host)

Le secret de ces résultats est la gestion de la mémoire, largement critiqué par Microsoft. Anton a donc fait ses calculs avec différents ratio de sur-allocation (1.2, 1.3 et 1.4), ce qui permet d’avoir plusieurs points de comparaison pour différents corps de métier. Le résultat est évidement proportionnel : la différence de prix est réduite par le nombre croissant de VM jusqu’à devenir en défaveur d’Hyper-V sur des serveurs à 64Go de RAM et plus !

Merci à Anton de nous avoir fait partager son étude.