Hypervisor.fr

VMware à mis à dispo hier un pack de cmdlet compatible Power-CLI 4 U1 pour vCenter Update Manager. A nous les joies du scripting pour les updates VM/VMHost !

Tags: PowerCLI, powershell, VUM

Depuis la version U1 du Power-CLI, vous avez peut être remarqué que la cmdlet get-snapshot est 3000% plus lente. Nous supposons que l’ajout de la propriété SizeMB y est pour beaucoup car plus les différents snapshot d’une VM sont gros, plus le résultat sera long à arriver. Cette information n’est pas nécessaire dans tous les cas, on aurait donc beaucoup apprécié que la cmdlet originale n’est pas été remplacée.

Pour un besoin spécifique (gestion de la rétention des snapshot en l’occurrence), nous avions besoin de lister tous les snapshot d’une infra avec un filtre sur la description. Dans ce cas précis, nul besoin de la taille du snapshot. La cmdlet get-snapshot du Power-CLI U1 retourne la liste en plusieurs dixaines de minutes sur cette infra (oui, il y en a BEAUCOUP), ce qui n’était pas acceptable. Nous avons donc retroussé nos manches pour scripter une fonction récursive en powershell afin de lister les snapshots d’une, d’une liste ou de toutes les VM présentes dans le vCenter :

param($VM)
 
if ($VM) {$rootsnap = $VM|%{Get-View -ViewType VirtualMachine -Filter @{"Name" = $_}}|%{$_.Snapshot.RootSnapshotList}}
else
{$rootsnap = Get-View -ViewType VirtualMachine |%{$_.Snapshot.RootSnapshotList}}
 
$snaplist = @()
$snaplist += $rootsnap
 
function get-snapshotlegacy ($rootsnap){
	foreach ($snap in ($rootsnap|%{$_.ChildSnapshotList})){
		$snap
		if ((($snap|%{$_.ChildSnapshotList})|Measure-Object).count -gt 0){
			get-snapshotlegacy $snap
		}
	}
}
 
$snaplist += get-snapshotlegacy $rootsnap
$snaplist

Ce script peut etre utilisé de 3 façons différentes : pour une seule VM, pour une liste de VM ou pour toutes les VM.

.\get-legacysnapshot.ps1 VM1

.\get-legacysnapshot.ps1 @(”VM1″;”VM2″;”VM3″)

.\get-legacysnapshot.ps1

La liste d’objets retournée par ce script est utilisable par la suite pour d’autre cmdlet. Par exemple, si l’on souhaite supprimer tous les snapshot dont la description est “à supprimer”, voici la syntaxe :

.\get-legacysnapshot.ps1 |?{$_.Description -eq "à supprimer"} |%{(get-view $_.snapshot).RemoveSnapshot_Task(0)}

Vous pouvez constater ci dessous que pour lister 111 snapshot dans plus de 600 VM, l’exécution du script ne prend que 53 secondes (contre plus de 20min avec la cmdlet get-snapshot) :

Tags: PowerCLI, powershell, scripting

MAJ 09/03/2010 : Pour ceux qui utiliseraient ce script sur un gros environnement, voici une version “optimisé” grâce au fameux get-stat2 de LucD (qui nous a confiés que les method du VC-SDK étaient plus rapides que les cmdlet du PowerCLI) qui dans notre cas réduit le temps d’exécution de 15min à 3min (Get-Stat2.ps1 doit être dans le même répertoire) : Get-Capacity++

Dans un environnement hétérogène, il est parfois difficile d’estimer la quantité de VM qu’un cluster peut encore accueillir ou si ce dernier en héberge déjà trop. VMware offre un produit qui remplit cette tache -et plus encore- (Capacity Planner) avec des jolis graphes et des morceaux de reporting dedans mais à un prix exorbitant (1500€/socket au dernières nouvelles).

Ayant besoin d’avoir cette visibilité à moindre frais, nous nous sommes lancés dans la réalisation d’un script powershell qui offrirait une visibilité par cluster en s’appuyant uniquement sur les stats CPU/RAM (pour les IO réseau et stockage c’est un peut plus complexe et pas encore pris en charge par DRS) et qui tiendrait compte des contraintes de disponibilité (HA Admission Control Policy). Pour chaque cluster ce script recueil les moyennes horaires sur 7 jours et calcul la moyenne des valeurs au dessus de la moyenne globale. Cette valeur est utilisée comme “moyenne” de consommation du cluster sur 7 jours et est ensuite soustraite à la capacité effective du cluster (sans les hosts “de réserve”) et divisée par le nombre de VM pour obtenir un nombre de VM “moyen” restant ou, si le résultat est négatif, en surplus. Ceci offre donc une vision synthétique de la balance cpu/ram du cluster ainsi que le nombre de VM moyennes encore admissibles :

Voici le résultat sur le cluster hébergement votre blog préféré. Les dons de RAM sont acceptés

Voici le résultat sur un environnement de production

Les valeurs entre crochets sont les “moyennes” utilisées pour le calcul, à titre indicatif (une bonne idée d’Alan Renouf qui vois déjà ce script dans vCheck !).

Nous en parlions il y a quelques temps déjà, le TPS ne fonctionne pas lorsque vMMU est pris en charge matériellement (RVI ou EPT) à cause des “large pages”. Nous nous sommes livrés à de petites expériences pour illustrer la différence swMMU/hwMMU :

Les tests ont été fait sur un serveur lame IBM LS42 (Opteron 8376 HE / 32Go), nous y avons démarré 30 VM identiques (W2K3EE) à 10sec d’intervalle, avec le paramètre de vMMU forcé. On voit clairement sur le graphique que le TPS “récupère” beaucoup plus de mémoire en swMMU qu’en hwMMU.

Halesh (VMware R&D) nous a confirmé que dans cette situation, le TPS n’agissait que sur les pages “zeroed” au boot de la VM. Seongbeom Kim (VMware) nous en dis plus par mail :

On EPT/RVI platform, large pages are used to back guest memory request for better performance. This delays page sharing until the host goes into memory overcommitted situation.
In more recent updates to ESX4.0 (including build 219382), zero pages are shared in 4K granularity while guestOS boot-process zeros all guest memory.
This approach provides early sharing and can be beneficial for guests that do not access all the configured memory.
Whenever the shared page is broken, we try to back it with large page to achieve better performance.

Mais le plus fort c’est que le vMMU peut être changé à chaud grâce à VMotion (en changeant le paramètre avant le VMotion bien-sur) ! Pour illustrer cette prouesse purement futile, nous avons superposé les 2 graphiques mémoire des 2 hosts :

Nous attendons d’en savoir plus sur la “légitimité” de cette “feature”…

Selon Halesh, le fonctionnement de VMotion explique cet effet :

For VMotion we need common CPUs across source & destination. But as you said during vmotion, vMMU worlds are restarted/newly created on destination this might be supporting.

Tags: RVI, TPS, vMMU

La nouvelle version, tant attendue, du célèbre benchmark Project VRC a été publiée il y a quelques jours. Comparé à l’ancien benchmark, celui ci à été totalement revu (tests plus lourds et horloge de mesure externe) et effectué sur des serveurs à base de Xeon Nehalem avec les dernières versions des 3 hyperviseurs. Des tests en environnements 64bits font leur apparition et les résultats ont été réunis dans un seul et unique document.

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…

Tags: Benchmark, VRC