Powershell :

Get-VMHost |Get-VMHostStorage -RescanAllHba -RescanVmfs
Get-VMHost -location "cluster" |Get-VMHostStorage -RescanAllHba -RescanVmfs

Cette commande lance un rescan des Hba et un rescan des partition VMFS de tous les serveurs énumérés par la commande “Get-VMHost”. Vous pouvez limiter l’énumération à un cluster par exemple avec l’option “-location”.

Get-VMHost -location "cluster" |Get-VirtualSwitch -name vSwitch0 |New-VirtualPortGroup -name "VLAN 200" -VlanId "200"

Cette commande ajoute un PortGroup (avec VID) nommé “VLAN 200″ au vSwitch0 de chaque serveurs du cluster identifié.

Get-VM |Get-CDDrive |Set-CDDrive -NoMedia -confirm:$false
Get-VMHost -location 'cluster' |Get-VM |Get-CDDrive |Set-CDDrive -NoMedia -confirm:$false

Cette commande démonte tous les lecteurs CD de toutes les VM énumérés par la commande “Get-VM”. Vous pouvez limiter l’énumération à un cluster grace au pipe.

Get-VM 'VMTEST*' |get-VMResourceConfiguration |Set-VMResourceConfiguration -CpuAffinity NoAffinity

Cette commande supprime les affinités de CPU pour toutes les VM dont le nom commence par “VMTEST”

Get-VM -location 'drscluster' |set-vm -DrsAutomationLevel 0

Cette commande désaction (disabled) l’Automation Level de chaque VM du cluster “drscluster”.

Get-VMHost 'ESXTEST*' |Set-VMHostAdvancedConfiguration -name Cpu.MigratePeriod -value ( [system.int32] 50 )

Cette commande passe la valeur Cpu.MigratePeriod à 50 sur chaque serveur dont le nom commence par “ESXTEST”.

Shell :

esxcfg-info | grep "HV Support"

Cette commande vous permet de savoir si votre ESX/ESXi supporte le VT/AMD-V (0 = pas supporté, 1= supporté mais pas activé, 3=supporté et activé).

/opt/vmware/aam/bin/Cli -domain vmware -connect localhost -port 8042 -timeout 60 -cmd listnodes

Cette commande vous permet d’énumérer dans les membres du cluster dont l’ESX/ESXi (primary uniquement) fait parti.

vim-cmd vmsvc/getallvms

Cette commande permet sur un ESXi de lister les VM “registered” sur le serveur (“vmware-cmd -l” sur ESX)

• Support total d’ESXi: Veeam Backup 3.0 apporte le support complet d’ESXi grâce à ses APIs natives. VCB n’est plus nécessaire pour sauvegarder et restaurer des VMs se trouvant sur un hôte ESXi.

• Restauration au niveau fichier sur les plateformes Windows et Linux: Avec la version 3.0, les machines virtuelles Linux peuvent maintenant être restaurées sans extraire l’intégralité de l’image.

• Support de VSS Windows 2008: Veeam Backup 3.0 intègre le support des extensions VSS 2008 pour la cohérence des fichiers de sauvegarde et de restauration des machines virtuelles Windows 2008.

• Sauvegarde des templates: A l’instar des machines virtuelles, les fichiers templates de VM peuvent maintenant être sauvegardés.

• Exclusion spécifique de VMDK: Il est possible de choisir quels fichiers VMDK inclure et exclure pour un job de sauvegarde, en se limitant par exemple aux disques systèmes.

Cette beta est gratuite mais le produit final sera soumis à licence. Profitez en !

En résumé, Citrix serait sur le point de devoiler Q1 2009, une suite d’outils de management pour XenServer (code name Encore) compatible Hyper-V apportant une fonctionalité comparable au Vmotion de VMware. Pour rappel, cette fonctionalité est toujours en cours de dévellopement chez Microsoft et ne sera dispo que courant 2010 avec Windows 2008 R2.

Et comme si cela ne suffisait pas, Citrix travaillerait sur du memory ballooning (aka memory overcommitment) intégré à XenServer 6.

May the Force be with you…

Pour rappel, cette option est un watchdog de VM qui vérifie de façon plus ou moins régulière la disponibilité des vmtools :

Cette option permet donc de rebooter une vm ayant subit un BSOD, un kernel panic ou si l’OS est devenu trop “bancale”. Très pratique donc.

Malheureusement, l’update 3 d’ESX 3.5 à quelque peut gâchée la fête. En effet, un vmotion vers un host 3.5 U3 “peut” provoquer un reboot de la VM lorsque l’option “virtual machine monitoring” est activée.

Concrètement, les vmtools de la VM ne renvoyait plus de “heartbeat” donc elle était considérée comme HS et un signal de reset était renvoyée à la VM. Démonstration (extrait du vmware.log d’une VM) :

12:35:49.421: vmx| MigrateStateUpdate: Transitioning from state 0 to 7. <– début du VMotion

[...]

12:35:50.132: vmx| MigrateWaitForData: waiting for data.
12:35:50.132: vmx| MigrateStateUpdate: Transitioning from state 7 to 8.
12:35:50.778: vmx| MigrateStateUpdate: Transitioning from state 8 to 9.
12:35:54.892: vmx| MigrateWaitForData: Waited for 4.76 seconds.
12:35:54.892: vmx| MigrateStateUpdate: Transitioning from state 9 to 10.

[...]

12:35:55.438: vcpu-0| MigrateStateUpdate: Transitioning from state 10 to 11.
12:35:55.438: vcpu-0| Migrate_ClearDoneState: cleared state.  State was 11. <– fin du VMotion
12:35:55.438: vcpu-0| MigrateStateUpdate: Transitioning from state 11 to 0.
12:35:55.438: vcpu-0| Done Sync monModules(4).

[...]

12:38:00.886: vmx| TOOLS received request in VMX to set option ’synctime’ -> ‘1′
12:38:00.893: vmx| VMXVmdb_LoadRawConfig: Loading raw config
12:38:17.867: vmx|
12:38:17.867: vmx|
12:38:17.867: vmx| VMXRequestReset <– reset de la VM par le virtual machine monitoring

Le patch ESX350-200811401-SG censé résoudre le problème, ne résout malheureusement rien.

Heureusement, comme nous l’avions annoncé dans la news précédente, ce workaround lui fonctionne bien (tests à l’appui).

Faire modifier un fichier manuellement sur X serveurs vi ssh c’est tellement plus fun que de mettre à dispo un vrai patch…

Il y a quelques jours, nous découvrions avec grand étonnement plaisir que VMware avait rendu les api RCLI pour ESXi read-write pour la version gratuite, grâce à l’update 3.

Mais en fait, non :

With the release of VMware ESXi 3.5 Update 3, some API calls became freely available.  As it turns out, these new APIs were opened up unintentionally.  This inadvertent change happened when VMware was resolving an API-related bug.

Only customers who downloaded the free version of ESXi have been affected.  VirtualCenter and VI (Foundation, Standard, Enterprise) customers are not affected.

My VMware contacts tell me that this bug will be fixed shortly, and the next release will lock down the RCLI again.

Merci à Rich Brambley pour l’info.

MAJ 03/12/2008 : VMware a enfin rendu disponible le patch corrigeant ce problème.

A peine l’histoire du “timebomb” de l’update 2 oubliée, un nouveau bug frappe la dernière update (build 123630) d’ESX 3.5

Ce bug touche l’option “Virtual Machine Monitoring” qui reboot les VMs ne renvoyant plus de “heartbeat“. Lorsque cette option est activée dans un cluster HA/DRS et qu’une VM subit un Vmotion (vers un serveur ayant recu l’update en question) sur recommandation du DRS, il y a de fortes probabilitées que cette VM soit rebootée une fois le Vmotion terminé.

ivobeerens.nl nous apprend qu’il suffit de désactiver l’option pour contourner le problème et qu’une update sera disponible dans la journée du 20 novembre 2008 :

“I made a support request @ VMware. The told me today that 20 November patch 10 for VMware 3.5 Update 3 will be released. Patch 10 fixes SOME random reboot problems in Update 3. I hope it resolves this nasty issue.”

Le forum de vmware commence à flamber… (ici, ici et ici)

Autre détail, les VM sous Windows ayant souffert du problème présentent ce symptôme dans l’eventlog :

On y retrouve toutes les commandes utiles pour l’administration quotidienne ainsi que des commandes réservées au support VMware telle que esxnet-support.

Malheureusement, les partitions “data” ne sont pas toujours les seules à subir un nombre important d’I/O. Les environnements Terminal Serveur et Citrix en sont un parfait exemple lorsqu’il s’agit des profils utilisateurs.

Alors qu’avec VMFS2 il était nécessaire de passer par la case “ligne de commande”, une partition VMFS3 créée (pas migrée) via le client VI est désormais bien alignée à la structure de la LUN. De même sous Windows 2008, une partition est par défaut correctement alignée à la structure du disque).

Mais sous Windows (2003 et 2000 s’il en reste ?!) bien qu’il soit facile d’aligner une partition data (MBR ou GPT) lors de sa création ou une futur partition système (avec des outils tel que GParted via une iso bootable), il est nettement plus difficile de le faire sur une partition existante.

Au détour d’une conversation sur le forum VMware datant de février 2007, un membre donne une solution aussi efficace que complexe :

La technique consiste à déplacer la partition sur un disque temporaire et de la recopier sur la partition d’origine avec un paramètre d’alignement. Pour gagner du temps, nous avons tester la procédure en copiant directement la partition sur un disque qui remplacera le disque d’origine. Démonstration :

• Télécharger l’iso de DFSee
• Faire un backup de la VM
• Créer un disque secondaire sur la VM, plus grand d’1Mo que l’original et booter sur l’iso
• Une fois dans l’application, appuyer sur Echap pour passer en mode ligne de commande :

• taper la commande “disk 1″ puis “part 1″ :

• taper la commande “move -f:2 -e:0×41,s -c” pour copier la partition sur le 2eme disque avec le bon alignement :

• Sortir de DFSee (F3) et relancer (dfseerun 1)
• Toujours en ligne de commande, sélectionner la partition 1 du disque 2 (“disk 2″ puis “part 1″)
• taper la commande “fixpbr” :

• Rebooter sur le bon disque et taper la commande suivante sous windows : “wmic partition get BlockSize, StartingOffset, Name, Index”. Le StartingOffset est passé à 65536.

Dans le screenshot suivant, la 1ere partition du disque 1 est aligné avec la méthode ci dessus (StartingOffset à 65536). Dans l’ordre nous avons créé une partition non alignée (StartingOffset à 32256) que nous avons supprimé et recréé avec le paramètre “align=64″. Les deux méthodes aboutissent bien au même résultat :

Merci encore à embo500 du forum VMware.

Cette update apporte majoritairement du support matériel supplémentaire mais 2 nouveautés intéressantes font leur apparition :

• La limite de vCPU par core passe de 8 (ou 11 pour du VDI) à 20
• vmfs-undelete, un outil de restauration de fichiers supprimés pour VMFS

Bien que vmfs-undelete ne soit encore qu’experimental et non disponible sur ESXi, il sera très probablement plus que bien accueilli par la communauté VMware

L’update 2 de Virtual Center 2.5 offre une option fort intéressante permettant la compatibilité des CPU Intel/AMD pour le VMotion. Cette option baptisée EVC, pour Enhanced VMotion Compatibility, n’est malheureusement activable que sur les CPU récents (à partir des Intel 45nm Core 2 (Penryn) et AMD Second Generation Opteron -revision E or F-).

Pour permettre la compatibilité VMotion entre 2 hosts de génération différente, il existe une solution non supporté par VMware mais bien efficace : la modification du bit mask des VM.

Par défaut, le vCPU d’une VM possède les mêmes caractéristiques que le CPU du host qui l’héberge. Lorsqu’un VMotion est initié, Virtual Center verifie la compatibilité entre le vCPU et le CPU du host de déstination. Si les 2 cpu ne sont pas compatibles, le VMotion échoue immédiatement.

En modifiant le bit mask de la VM, il est possible de forcer le vCPU à masquer les caractéristiques du CPU. Ainsi, la VM peut etre déplacée à chaud mais ne jouira pas des mêmes caractéristiques d’un host à l’autre (le SSE3 par exemple). Au péril de la stabilité de la VM.

Nous allons modifier le bit mask d’une VM afin de rendre le VMotion possible entre 2 hosts Intel de génération très différentes :

Une tentative de VMotion entre ces 2 hosts se solde par l’erreur suivante :

Après une première modification du bit mask, on obtient une autre erreur :

Après une seconde modification du bit mask, le VMotion peut être effectué (malgré le warning pour les interfaces réseau) :

Voici les modifications effectuées dans l’ordre sur la VM :

Dans notre cas, voici le résultat en image :

avant :

après :

La KB VMware détaillant l’historique des posibilités sur les différentes versions de VC/ESX ainsi que les détails sur les différences Intel/AMD se trouve ici, le VMotion Guide se trouve ici et un exemple de compatibilité entre CPU là

reg delete “HKLM\SOFTWARE\VMware, Inc.\VMware Tools” /v ShowTray

reg add “HKLM\SOFTWARE\VMware, Inc.\VMware Tools” /v ShowTray /t REG_DWORD /d 0

Le slogan est encore meilleur :

Malgré des résultats plus que spectaculaires [...]chiffre d’affaires trimestriel de 472 M$, en hausse de 32 % par rapport au troisième trimestre 2007[...], VMware augmente ses tarifs de 10% en Europe et en Océanie.

Cette augmentation (décidée en juin 2008) nous a été confirmé pour la France et tombe particulièrement mal au moment où les autres acteurs du marché font du forcing (pour ne pas dire du rouleau-compresseur-marketing) pour placer leur hyperviseur.

Réponse officielle de VMware : le dollard reprend de la valeur face à l’euro.

Rien à voir avec le fait que l’action soit au plus bas depuis l’introduction en bourse de VMware. Non rien.

C’est très joli mais pas suffisamment précis pour un benchmark.

L’outil ultime pour accompagner un benchmark sur ESX est esxtop. Cette commande bien connu des admins VMware permet l’affichage en quasi temps-réel (2s d’intervalle au mieux) de toutes les informations concernant la consommation des VM et du host les hébergeant. Ces informations sont classées en 4 parties : CPU, Memory, Storage et Network.

Scott Drummonds, TAM et “performance specialist” chez VMware, à publié une méthodologie détaillée pour l’analyse des performances. Chaque domaine (CPU, RAM, stockage et réseau) est traitée avec précision ce qui permettra d’identifier rapidement la provenance d’une dégradation des performances.
Concernant la partie CPU, Scott à également publié une annexe très intéressante dédiée au compteur “Ready Time” (temps durant laquelle la VM attend la ressource CPU nécessaire à son fonctionnement), indispensable pour les VM en SMP.

Pour les ESXi, la commande esxtop est disponible via ssh ou en ligne de commande distante (resxtop) dans via les “VI Remote CLI” disponible sur le site de VMware sous forme de package Windows, Linux ou d’une Appliance en ovf.

esxtop étant une commande facilement scriptable et permettant l’export de fichiers .csv, elle permettra également de constituer des rapports de performance pour le suivis des serveurs de votre infrastructure (importable dans perfmon).

MAJ 30/10/2008 : Il y a aussi la méthode officielle made in VMware

Ce document rédigé par Seva Semouchinun, TAM (Technical Account manager) pour VMware Allemagne, ne peut etre considéré comme document officiel mais plutot comme une sorte de “community white paper” comme on peut en trouver sur le site de VMware.

La version définitve de ce documents sera posté sur VI:OPS.

• Pressez Shift-O lors du démarrage d’ESX3i
• Tapez “shell” puis validez
• Au menu principal, pressez Alt-F1 pour accéder au shell
• Taper “unsupported” en aveugle puis tapez le mot de passe root

Il vous est maintenant possible d’utiliser les commandes esxcfg :

Cette manipulation est appelé Tech Support Mode par VMware