Hypervisor.fr

Après cette traduction foireuse du mot “overhead”, bien plus explicite dans sa langue maternelle, nous voudrions vous faire partager un petite expérience en rapport avec notre précédent billet au sujet de l’importance de la quantité de vRAM attribuée aux VM. Nous avons fait allusion au tableau d’overhead mémoire du Resource Management Guide (4.1) et avons remarqué pour la première fois que les valeurs n’étaient pas linéaires. Et pour cause, elles ont plutôt l’air exponentielles :

On constate que :

• Les écarts sont proportionnels jusqu’à 4Go
• A partir de 4Go, 3 groupes se forment 1, 2-3-4 et 5-6-7-8 vCPU
• A partir de 4Go les courbes des groupes se confondent presque
• A 256Go de vRAM, une VM à 5 vCPU à presque 2 fois plus d’overhead qu’à 4 vCPU et presque 3 fois plus qu’à 1 vCPU

Et bien d’autres choses encore que nous vous laissons découvrir par vous même…

Tags: overhead

ESX ignore totalement la nature et l’importance du contenu des pages de vos VM (il connait uniquement les statistiques d’utilisation), mais il peut faire appel au driver qui controle le ballooning “In-Guest” pour forcer le “Guest OS” à liberer des pages disponibles ou à deplacer des pages peut ou pas utilisées dans le swap du “Guest OS”. Cela fonctionne très bien seulement si la VM à le temps d’effectuer cette opération. Ainsi, lors d’une forte contention meme brève, ESX n’attendra pas que la VM “rende” des pages et commencera à compresser (si possible et uniquement à partir de la version 4.1) puis swapper aléatoirement des pages vers le fichier de swap de la VM (potentiellement catastrophique pour les performances) :

(1-contention rapide / 2-contention lente)

De plus, comme indiqué dans le Resource Management Guide, plus la VM est riche en vCPU et en vRAM, plus elle imposera un overhead important au VMkernel. Cet overhead est réservé et donc totalement “perdu”. Il ne sera pas non plus soumis aux differents mécanismes de récupération d’ESX (Transparent Page Sharing > Memory Idle Tax/Ballooning > Memory Compression > Hypervisor Swapping).

On ne parle que d’une centaine de Mo pour une VM avec 1 vCPU et 1Go de vRAM, mais un petit one-liner de PowerCLI nous permet de savoir de combien on parle pour une infra de plus de 1200 VM :

Write-Host -ForegroundColor Red -BackgroundColor Yellow $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Runtime|Measure-Object -Sum -Property MemoryOverhead).sum/1GB,1)) / $([math]::round((Get-View -ViewType virtualmachine -Property Summary,Runtime|?{$_.runtime.PowerState -eq "poweredOn"}|select -ExpandProperty Summary|select -ExpandProperty Config|Measure-Object -Sum -Property MemorySizeMB).sum/1KB,1))

Presque 220Go d’overhead sur environ 3,8To de vRAM attribué, soit près de 6% !

Il est donc nettement plus judicieux de bien determiner la taille de vRAM nécéssaire au “Guest OS“ et de tailler au plus juste plutot que mettre une valeur trop large au risque de voir la VM en souffrir plutot que d’en bénéficier (idem pour les vCPU d’ailleurs).

A lire tous les soirs après s’etre brossé les dents : Understanding Memory Resource Management in VMware ESX 4.1

Tags: ballooning, memory overcommit

Après des mois de tapage makerting autour de Dynamic Memory (ballooning farceur) et Remote FX (RDP++), le lancement officiel du SP1 de Windows 2008 R2/Hyper-V R2 s’est fait sans grosses explosions blogesques puisqu’on en connaissait déjà les détails (mise à part la critique de l’excellent whitepaper Project VRC Phase III au sujet de l’ASLR sur le Windows Virtualization Team Blog).

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

Tags: bug, Bullshit

Cette histoire date de début 2010 mais puisque nous avons du chercher un peu trop longtemps pour la retrouver, avec ce post cela n’arrivera plus.

Tout commence avec la technique de sauvegarde de Veaam Backup : le Synthetic Backup aka “reversed incremental“. Imaginez le principe de la sauvegarde incrémentale à l’envers, c’est à dire que le backup full est toujours le plus “up to date” et que les incrémentales vous permettent de remonter dans le temps. C’est donc beaucoup plus simple en cas de restauration du dernier backup (majorité des cas) et surtout en cas de backup sur bande car l’élément à backuper est toujours le même : la full (.vbk).

Veeam Backup “injects” the changes into the full recovery file (.VBK) and then also saves any data replaced during this process into the reversed incremental changes file (.VRB)

The .VBK file also has the most current modified date as it gets updated after each backup cycle.

Par contre, même si l’on force la politique de rétention à “1″, si un backup est déjà présent lors de l’exécution du job, un fichier .vrb (reversed incremental) est créé, alimenté durant toute la durée du backup et supprimé une fois le job terminé. L’inconvénient dans l’histoire c’est que si vous vous servez du même volume pour accueillir tous vos backup et que plusieurs job sont exécutés simultanément, il faudra prévoir l’espace “perdu” pour les fichiers .vrb temporaires.

Si l’on ne dispose pas de cet espace, on est évidement tenté de supprimer le fichier .vbk et laisser le job refaire une full. Dans la version 3 de Veeam Backup, il était tout à fait possible de procéder ainsi mais ce comportement à été modifié dans la version 4 : le job refuse de se lancer sans le .vbk précédent (à moins que l’on supprime manuellement le backup via la console) :

C’est dans le “release notes” de la version 4.1.1 que l’on trouve une partie de la parade:

Support for rotated media. Veeam Backup can now be instructed to automatically re-create full backup file if it is missing from the backup storage to better support scenarios with rotated media as backup target. This behavior can be enabled with a registry mod.

Et le “registry mod” le voici (pour la v4) :

[HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and FastSCP]
"ForceCreateMissingVBK"=dword:00000001

Ou si vous êtes en v5 :

[HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication]
"ForceCreateMissingVBK"=dword:00000001

Tags: veeam

Parce qu’il nous arrive encore de lire des trucs imprimés pour de vrai sur de la véritable fibre cellulosique, nous inaugurons aujourd’hui (alors que nous aurions du le faire il y a longtemps comme notre confrère VMDUDE) une rubrique “presse” où vous pourrez retrouver notre sélection ”spéciale” ainsi que des ouvrages que nous recommandons. Bonne lecture à tous !

Tags: e-book