Hypervisor.fr

MAJ 18/03/2011 : Comme nous le précise Tntteam, c’est ironiquement ce même patch qui corrige le problème (KB1037190)

En appliquant la mise à jour ESXi410-201104401-SG dispo depuis le 28/04/2011 (la première update depuis l’Update 1 de la 4.1)  sur notre lab à l’aide de VUM, nous nous sommes retrouvés avec cette erreur : “The host returns esxupdate error codes: 10“. Plus précisément, en utilisant la fonction “Scan…” de VUM directement sur un des ESXi d’un cluster car l’erreur retournée lorsque nous avons tenté un “Scan for Updates” sur ce cluster était beaucoup trop vague.

Heureusement, la réponse à ce problème a été particulièrement bien détaillée par un membre de VMware dans un thread sur le forum de l’éditeur :

[...]/tmp was added in 4.1U1 to the list of directories “cleaned” by /sbin/tmpwatch.sh.  (tmpwatch.sh is run by root’s crontab /var/spool/cron/crontabs/root).  tmpwatch is not aware that /tmp/scratch is special and needs to be left alone.

[...] On ESXi Installable, /scratch is a symlink to some /vmfs/volumes/… place, not assaulted by tmpwatch.

[...] So only Embedded is affected, and then only a subset (diskless machines), and then a subset of those (without suitable scratch space on the boot USB key).

Pour résoudre le problème en attendant un prochain patch, plusieurs solutions sont à votre disposition (merci aux membres du forum ainsi qu’à filbo pour les détails) :

• Utiliser des supports USB/SD supérieurs à 5Go (pour la partition scratch soit bien créée à l’install)
• Rediriger la scratch vers un volume vmfs via les advanced settings (ScratchConfig.ConfiguredScratchLocation)
• Modifier le script /sbin/tmpwatch.sh (la pire des solutions pour des raisons évidentes)
• Recréer le répertoire manquant via mkdir -p /tmp/scratch/var/tmp (la solution la plus rapide car ne nécessite pas de reboot mais non durable)

Tags: bug, embbeded, VUM

Lors d’une restore de VM ou suite à une mauvaise manipulation, il peut arriver de perdre les précieux ”Custom Attributes” aka “Custom Fields” qui sont stockés dans la base du vCenter et non dans le vmx de la vm comme c’est le cas de l’attribut “annotation” aka “notes” aka “Description” (oui, nous aussi ça nous gonfle…) :

C’est encore PowerCLI qui vient à notre secours pour un script d’export/import de ces informations vers un fichier xml pour une manipulation plus facile.

Sans arguments, le script exportera l’ensemble des Custom Fields et Annotation de toutes les vm (ou d’une en particulier grâce au paramètre -VmAlone)  dans un fichier “VmFieldList.xml” dans le répertoire courant (ou à l’emplacement de votre choix grâce au parametre -$XmlPath) ; si le fichier existe déjà, il sera renommé suivant la nomenclature VmFieldList-yyyyMMddHHmmss.xml. Le fichier généré ressemble à cela :

Pour restaurer les infos d’une VM, voici la syntaxe :

IOCustomField.ps1 -VmAlone RSW2K8VPX51 -Action import -Confirm 1

Pour restaurer toute ou une partie des vm, il suffit de passer au script le nom de la vm dans une boucle :

Get-Cluster "CLU01"|Get-VM|%{.\IOCustomField.ps1 -VmAlone $_.name -Action import -Confirm 1 -XmlPath .\VmFieldList.xml}

download

En bonus, un petit OneLiner pour exporter vos Host Profiles en fichiers .prf du même nom :

Get-VMHostProfile|%{Export-VMHostProfile -FilePath "$($_.name).vpf" -Profile $_ -Force}

Tags: oneliner, PowerCLI, powershell, scripting

@VMwareKB vient de twitter une kb très intéressante à propos des conséquences que peut avoir l’architecture NUMA sur les VM dont le nombre de vCPU dépasse le nombre total de cores disponible dans les nodes NUMA du host qui l’héberge. Pour avoir la réponse, il faut avant tout connaitre les différences de fonctionnement des scheduler NUMA d’ESX 4.0 et 4.1 (cf vSphere Resource Management Guide et  The  CPU Scheduler in  VMware ESX 4.1) et en particulier du “Wide-VM NUMA” qui a fait son apparition dans la 4.1 :

esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.0 hosts :

If the virtual machine has a higher number of vCPUs than the number of cores in the NUMA node, then the virtual machine is not managed by the NUMA Scheduler and there are no benefits from NUMA locality.

esxtop command showing high %RDY values for virtual machines running on NUMA enabled ESX/ESXi 4.1 hosts :

If the virtual machine has a higher number of vCPUs than the number of cores in the NUMA node, then the vCPUs are broken down into clients that are scheduled on multiple nodes.

Lorsque vous constatez des valeurs élevées sur le compteur Ready Time, il est donc important de s’assurer de la version d’ESX car les causes et conséquences selon les versions ne sont pas du tout les mêmes.

Nous vous recommandons la lecture de l’excellent article ESX 4.1 NUMA SCHEDULING de Frank Denneman décrivant les conséquences du split de client NUMA sur les performances de la VM.

Tags: NUMA, Wide-VM NUMA

Suite a une grosse coupure de SAN, nous avons du faire face à des “power on” récalcitrants avec lesquels nous avions déjà eu affaires lors de coupures réseaux sur du stockage NFS ou iSCSI :

N’importe lequel de ces messages vous mènera aux forums VMware, sur des blogs ou même à cette kb qui précise justement ce que nous allons prendre à contre pied :

Because a virtual machine can be moved between hosts, the host where the virtual machine is currently registered may not be the host maintaining the file lock. The lock must be released by the ESX host that owns the lock

Le point commun de ces troubleshooting est l’objectif de faire sauter le lock du ou des fichiers, ce qui parait tout à fait censé et que nous avons d’ailleurs déjà suivi par le passé en essayant aussi de redémarrer le service hostd en masse grâce à plink (ou esxi.txt est la liste des fqdn) avant de redémarrer l’ESX en dernier recours :

@echo off
FOR /F %%i in (esxi.txt) do call :plink %%i
:plink
"C:\Program Files (x86)\PuTTY\plink.exe" -pw "password" root@%1 "/sbin/services.sh restart"
GOTO End
:Last
:End

Cette dernière étape est particulièrement longue et fastidieuse alors que, sauf cas exceptionnel, la solution “idéale” est de trouver le dernier ESX ayant fait tourné la vm (via le vmware.log ou grâce à export régulier des infos du vCenter), de passer DRS en manuel pour être prompté au démarrage de la VM et de selectionner le bon ESX :

C’est tout simple mais ça marche très bien

Tags: lock, SAN, snapshot, vmdk, VMFS, vmx

Le géniallissime Massimiliano Daneri aka Mr VMTS a fait bavé toute la communauté en 2009 lors du VMworld Europe en présentant son projet de serveur de déploiement utra simple d’ESXi administrable via un plugin de vCenter.

Aujourd’hui, l’ultime maillon manquant à vCenter pour être totalement autonome depuis la machine physique jusqu’à la vm est enfin disponible ! Visez plutôt la feature list :

• Automated provisioning of new ESXi hosts stateless and statefull
• ESXi host state (firmware) backup, restore, and archiving with retention
• ESXi builds repository management
• ESXi Patch management
• Multi vCenter support
• Multi network support with agents
• Hosts memtest

Rendez-vous dans les VMware Labs pour télécharger package vPXE, certainement le meilleur plugin gratuit de vCenter ! Vous n’aurez d’ailleurs même pas besoin de consulter la doc ou les vidéos pour prendre instantanément en main ce plugin.

Pour ceux qui se poserai la question, la solution repose tout simplement sur un serveur qui gère les différents répository et qui envoi des ordres à un agent DHCP/TFTP/HTTP, le tout via un plugin aussi abouti qu’une solution payante. L’agent en question est inclus dans le package serveur, vous pouvez donc deployer des ESXi sur le même subnet que le serveur (qui peut être installé sur le vCenter) mais vous pouvez également installer un ou plusieurs agents sur différents subnet pour déployer ESXi où ça vous chante Vous pouvez aussi utiliser gPXE pour passer faire de l’http au lieu du traditionnel tftp ou utiliser PXE Manager pour faire du memtest86+ sur les serveurs et bien d’autres choses totalement surpuissantes !

N’hésitez pas à faire un petit tour par la page “Donate” du site de Max pour lui témoigner votre soutien et remerciement.

Grazie mille Max !

Tags: ESXi, PXE, VirtualCenter