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=5594 http://www.hypervisor.fr/?p=5594#comments Sun, 17 Apr 2016 23:26:32 +0000 NiTRo http://www.hypervisor.fr/?p=5594 MAJ 28/05/2016 : Sur XenServer 7, cette feature a un joli nom, HyperVisor Memory Introspection (HVMI)

Nous profitons du recent article de The Information qui décrit la volonté d’Apple de construire ses propres serveurs en raison d’une crise de paranoïa, pour partager avec vous une video découverte récemment traitant de Virtual Machine Introspection, une fonctionnalité de l’API Memory Inspection de l’Hyperviseur Xen (utilisé par Amazon pour AWS par exemple…).

Cette vidéo est présentée par Tamas K Lengyel, chercheur en sécurité et développeur actif sur les projets Xen Project Hypervisor, LibVMI et DRAKVUF (Dynamic Malware Analysis system). La description faites sur la home du site de ce dernier est particulièrement flipante :

DRAKVUF is an agentless dynamic malware analysis system built on Xen, LibVMI, Volatility and Rekall. It allows for in-depth execution tracing of malware samples and extracting deleted files from memory, all without having to install any special software within the virtual machine used for analysis.

Un peu avant la 3eme minute de la présentation, vous aller voir Tamas lancer la calculatrice de Windows 7 dans une VM, depuis l’hyperviseur, en “hijackant” la mémoire du GuestOS à l’aide de l’API VMI de Xen. Si si.

Ce projet est loin d’être recent puisqu’il date de 2011 et a bien été amélioré depuis :

In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added.

On vous laisse méditer sur les fonctions clefs du projets pendant que votre DSI se félicite d’avoir migré tout son système d’information sur Azure…

• Agentless start of malware execution.
• Agentless monitoring of Windows internal kernel functions.
• Guest multi-vCPU support.
• Tracing heap allocations.
• Tracing files being accessed.
• Extracting files from memory before they are deleted.
• Cloning of analysis VMs via copy-on-write memory and disk.

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.

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 !

Nous profitons de la sortie de FreeNAS 9.3, qui introduit le support des primitives VAAI TPST et TPSTUN, pour dissiper, une bonne fois pour toute on l’espère, le brouillard de bullshit récurant autour du thin on thin (en mode block).

Pour rappel, TPST(W) et TPSTUN, respectivement Thin Provisioning Space Threshold (Warning) et Thin Provisioning Stun, ont été introduites avec vSphere 5.0 très probablement pour répondre aux énormes risques que représente le thin on thin aka stocker un vmdk thin sur un LUN thin (TPSTUN existait en 4.1 sous le nom Out of Space Condition mais uniquement via plugin constructeur).

En effet, l’espace disponible d’un datastore VMFS est calculé de l’espace consommé par rapport à la taille du filesystem (SCSI oblige) contrairement à un datastore NFS qui interroge la baie/serveur pour le savoir. Ainsi, ESX n’a aucun moyen de savoir s’il reste assez ou plus (+) d’espace qu’il ne le croit. TPST (0×6 0×38 0×7) et TPSTUN (0×7 0×27 0×7) permettent à la baie/target de palier précisément à ce problème en envoyant aux clients/initiator des commandes SCSI lors du passage d’un certain seuil et/ou lorsqu’il n’y a plus d’espace du tout.

Soyons clair : thin|thick on thin sans TPSTUN + saturation de la baie = corruption de VM. Vous pouvez facilement le vérifier en faisant un test et sachez que nous l’avons vécu en production avec nos confrères vmdude et dagnu. On était content d’avoir du (veeam) backup…

Avant de rentrer dans le détail, voici un aperçu de notre vision des avantages et inconvénients des différentes combinaisons thin|thick on thin|thick :

• thick on thick : le top du top dans tous les domaines sauf celui le la rentabilité. Presqu’aucune intervention humaine n’est nécessaire excepté si les VM subissent des snapshot. Financièrement, c’est évidement la pire des solutions.
• thin on thick : le meilleur compromis. Seul l’espace touché est consommé (coté VMware) et en cas de datastore full seules les vm qui veulent grossir sont freezées.
• thin on thin : le rêve des admins SAN, le cauchemar des admins VMware. Cette solution nécessite un monitoring au top du sol au plafond et des tests de validation avant mise en production. Sans les primitives TPST et TPSTUN, cette solution est très proche de la roulette russe.
• thick on thin : les inconvénients du thin on thin sans les avantages. Vous pensez réserver l’espace en faisant du eagerzeroedthick mais en réalité la baie récupère les zéros et compresse le reste. Heureusement TPSTUN agit aussi sur les vmdk thick.

Concentrons nous sur le thin on thin puisque c’est la solution (assumée) qui tend à s’imposer officiellement (oui, avant vous “pensiez” faire du thin on thick). Tant que tout va bien, vous n’avez à craindre que l’impact du thin des vmdk. Mais quand l’espace vient à manquer dans la baie, on espère pour vous que ça se passe comme ça :

Lorsque vous aurez atteint le seuil (parfois) configurable du TPST, disons 75%, vous aurez droit à du “0×6 0×38 0×7″ dans vos logs à une fréquence qui dépend de son implémentation dans le logiciel qui contrôle la baie. Ces messages génèrent des événements esx.problem.scsi.device.thinprov.atquota et vob.scsi.device.thinprov.atquota que vous retrouverez dans le vCenter (alarme possible) sous la forme suivante :

Space utilization on thin-provisioned device naa.xyz exceeded configured threshold. Affected datastores (if any): “xyz”.

Si vous ne faites rien, vous finirez par atteindre le fond du panier et vous mangerez les fameux “0×7 0×27 0×7″. A ce moment là, ESXi freezera n’importe qu’elle VM demandant plus (+) d’espace et vous aurez droit à ce genre de message :

There is no more space for virtual disk xyz.vmdk. You might be able to continue this session by freeing disk space on the relevant volume, and clicking Retry. Click Cancel to terminate this session.

A cet instant précis, la seule et unique bonne chose à faire est de libérer de l’espace sur la baie. Nous avons à peu prés tout essayé de l’UNMAP jusqu’au VMFS3.OpenWithoutJournal sans obtenir de résultat stable. Si vous atteignez le “No space left on device“, la LUN est démontée et toutes vos VM passent en “inaccessible”. Et vous êtes dans la mer*e.

Notre conseil : testez, essayez de remplir/vider/re-remplir un LUN avant de partir en production (on à déjà vu des cas où TPST remontait mal voir pas du tout), monitorez bien les différents messages et commandes SCSI. Mais surtout, ne partez pas du principe que la baie ne sera jamais full…

Et pour ceux qui croiraient encore aux vertus du thick on thin, on vous laisse apprécier les joies d’un datastore full alors que le LUN ne l’est pas :

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…

In order to support virtual machines with strict latency requirements, vSphere 5.5 introduces a new per-VM feature called Latency Sensitivity.

Cela nous a fait curieusement penser à une autre feature disponible dans la version 5.1 : VM Latency Sensitivity.

vSphere 5.1 simplifies the process of configuring a virtual machine to support low-latency applications. It now offers a latency sensitivity advanced setting that automatically makes low-level changes in the vSphere kernel to reduce latency for the virtual machine.

Ah tiens c’est bizarre, elles ont le même nom…

Vous constaterez qu’il n’en est nullement fait référence dans le whitepaper de la 5.5 donc impossible de savoir si c’est “vraiment” une nouvelle fonctionnalité, la même fonctionnalité améliorée ou un gros pipeau.

En attendant d’en savoir plus, on vous a préparé un petit oneliner pour activer la fonctionnalité et même fixer le nombre de µs secondes que vous souhaiter (2000 dans notre exemple) :

Get-VM "Flash_Gordon"|Get-View|?{-not $_.Config.Template}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{latencySensitivity=(New-Object VMware.Vim.LatencySensitivity -Property @{level="custom";sensitivity="2000"})}))}

Et pour savoir ce qui a été configurer :

(Get-VM "Flash_Gordon"|Get-View).Config.LatencySensitivity

Any vendor claiming support for #vStorage 5.1 API, CANNOT perform consistent backups

Réponse bien précise de veeam :

Our development team wasn’t able to fix these issues but they did realize that separating the VDDK calls into a separate process monitored by a watchdog process will help to dramatically increase overall reliability. In case this process hangs, we simply kill the process without affecting the job. With an alternative architecture not featuring such isolation, VDDK code hang will cause they whole backup and restore “job” to hang just as the VMware KB article explains.

Additionally, Veeam sets extra timeouts on some critical VDDK calls to avoid possible deadlocks.

Conclusion :

In short, Veeam customers are immune to VDDK issues while Symantec customers need to go back and verify the recoverability all of their VMware VM backups, as per Symantec’s own tweet.

Ça fait mal.

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.

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

Mais la vraie question, c’est : “qu’est ce qu’on va bien pouvoir faire d’une VM avec 128 vcpu ?!“

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.”

L’une d’entre elles, Heterogeneous Pools, permet de composer un cluster (Pool chez Citrix) avec des serveurs dont les cpu sont de différentes générations  en s’appuyant sur Intel Flex Migration et AMD Extended Migration (tout comme VMware EVC depuis Q3 2008…). On comprend très bien l’intérêt de pouvoir mixer des Xeon Core 2 avec des Xeon Core i7 mais lorsque qu’on tente de mixer 2 serveurs identiques avec une simple difference de stepping (codification des révisions chez Intel, induisant des corrections de bug et/ou évolution de process de fabrication), on a droit à un joli message d’erreur :

Là on se dit, Citrix a voulu assurer grave sur les pools hétérogènes pour éviter les problèmes de XenMotion. Oui mais non. Car si sur ces mêmes serveurs, vous installez XenServer 5.5, toujours avec des licences gratuites, que vous créez un pool avec et que vous upgradez ce pool en 5.6, ca marche :

Je vous laisse en tirer la conclusion qui adhérera le mieux à votre niveau de paranoïa…

Mieux, si vous voulez ajouter la ram à votre snapshot c’est aussi soumis à licence :

Rajoutez à cela :

• Pas d’update automatique des xentools 5.5 >5.6
• Pas d’update via XenCenter de XenServer 5.5 > 5.6
• Pas de snapshot quiesced et/ou w/memory sans les xentools 5.6
• Pas de thin provisioning natif
• Pas de XenMotion sans PV drivers

Mais on a quand meme droit au revert snapshot et au linked clone (surprise !) sur la version gratuite :

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