Après moult tests, nous nous sommes rendu compte qu’il était possible d’obtenir des combinaisons particulièrement intéressantes et notamment des configurations “impossibles” :

Sur cet exemple, nous avons créé une VM mono socket quad-core sur un serveur quadri-socket mono-core.

Nous vous laissons en déduire les complications juridique que cela pourrai engendrer pour des applications avec un mode de licensing par socket dans une VM “trafiquée”…

Au détour du vSphere Upgrade Guide (lecture hautement recommandée pour ceux qui sont concernés) nous avons remarqué la procédure de “roll back” d’une update/upgrade ou d’un patch. Cette procédure correspond bien au détail d’architecture d’ESXi :

You can also intervene manually at boot time to choose which image to use for that boot, so you can back out of an update if necessary.

C’est un peu vague, nous vous proposons donc un détail du process :

1. build “principale”
2. SHIFT + R pendant le bootloader
3. confirmation du fallback avec SHIFT + Y
4. Fallback réussi (l’opération est instantanée)
5. build “précédente”

Cette opération est possible sur toute les version d’ESXi, y compris la 3.5 :

Pour information, la fonction de fallback n’est pas disponible pendant le reboot qui suit une update :

Si l’on souhaite faire la manipulation inverse (totalement inutile donc indispensable de savoir comment), on obtient ce message (le même que lorsqu’il n’y a jamais eu d’update sur l’ESXi) :

Logique car si roll back il y a eu, c’est bien pour résoudre un problème ou appliquer une update plus récente. En admettant qu’on veuille VRAIMENT faire un roll back du roll back, il suffit de fouiller dans les fichiers boot.cfg des 2 partitions (bootbank et altbookbank) pour trouver la réponse :

Il faut repositionner la variable “bootstate” à “0″ pour que le bootloader repasse en mode “normal”.

Il semble que cela soit devenu un jeu d’enfants avec ESX 4 (toujours avec ntfs-3g).

VIX API est une bibliothèque permettant de créer des scripts et des programmes compilés pour interagir avec des host et/ou des vm. Mais ce qui nous intéresse ici, c’est un précieux utilitaire qui permet d’exécuter des commandes DANS les vm : vmrun

Voici un extrait liste des commandes de cet outil génial qui vous permettra, par exemple, d’installer un agent ou de déployer des mises à jour sur des vm en DMZ et donc non joignable depuis votre réseau de production :

Quelques exemples :

Supprimer un fichier dans une VM :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" -gu gadmin -gp "gpassword" deleteFileInGuest "[datastore] VM/VM.vmx" c:\test.txt

Copier un fichier depuis le vCenter vers une vm :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" copyFileFromHostToGuest "[datastore] VM/VM.vmx" c:\vctemp\agent.exe c:\utils\agent.exe

Faire un screenshot d’une vm :

C:\Program Files\VMware\VMware VIX\vmrun.exe -T ESX -h https://vcenter.vmware.com/sdk -u vcadmin -p "vcpassword" captureScreen "[datastore] VM/VM.vmx" c:\vm.png

Pour ceux qui commence à aimer le powershell (merci le VI toolkit), une library .NET est maintenant disponible.

Update : VMWareTasks est maintenant disponible sur codeplex

Ces proxy, comme d’autres également, scannent (anti-virus, anti-trojants) les fichiers téléchargés avant de les transmettre aux clients. Lorsque le fichier ne fait que quelques Ko c’est presque transparent mais lorsqu’il fait quelques dizaines de Mo c’est plus long. Aucun problème lorsque la requête est faite par un navigateur car le proxy redirige vers une page d’attente affichant la progression du download. Mais lorsque la requête provient d’un composant tel qu’Update Manager c’est le timeout assuré.

Résultat, Update Manager ayant téléchargé le fichier xml contenant la liste des nouvelles mises à jour mais le download des updates ayant échoué, vous vous retrouvez avec la liste des MAJ qui n’existent pas dans le répository et que vous ne pouvez donc pas appliquer. Malheureusement, impossible de forcer un nouveau download et télécharger les updates manuellement pour les copier ensuite dans le repository relèverait de la torture.

Après quelques recherches et un peu d’improvisation dans la base SQL VIM_UMDB, nous avons trouvé 2 solutions. L’une figure dans l’admin guide d’Update Manager et l’autre très certainement pas supporté du tout par VMware puisqu’il s’agit de modifier le contenu d’une table de la base SQL.

VMware a en effet prévu que le VirtualCenter ne soit pas connecté à Internet. Il existe donc un autre composant sur le CD d’install : UMDS aka Update Manager Download Service.

Une fois ce composant installé sur un serveur en DMZ ou ayant un accès direct à Internet, il suffit de configurer (en CLI uniquement) UMDS avant de lancer un téléchargement des updates. Vous pouvez utiliser des commandes pour ne télécharger que les updates sur une période précise et forcer un nouveau téléchargement en cas d’échec. Une fois le téléchargement terminé, il suffit d’utiliser une commande pour exporter le contenu du repository de l’UMDS vers un répertoire et d’utiliser une autre commande sur le VirtualCenter pour les importer. Toutes ces commandes sont détaillées à la page 16 de l’admin guide.

L’autre solution, plus “trash”, consiste à supprimer de la base SQL VIM_UMDB (présente sur le VirtualCenter) les updates dont le download aurait échoué.

Il suffit pour cela d’installer Management Studio Express de Microsoft sur le VirtualCenter et de vous connecter à la base SQL de ce dernier.

Une fois la table dbo.VCI_UPDATES identifiée, il faudra dans un premier temps désactiver les relations avec les autres tables pour pouvoir ensuite supprimer les lignes des updates à re-télécharger.

Il faut ensuite relancer le service vmware-ufad-vci et la tache planifiée de l’Update Manager. La ou les MAJ seront alors re-téléchargée(s).

Nous avons testé à plusieurs reprise cette métode et bien qu’aucun effet indésirable ne se soit manifesté, nous vous recommandons vivement de faire un backup avant toute modification de la base.

… Qui sera certainement plus ergonomique que le vCenter Mobile Access, Citrix nous offre une alternative avec son client XenApp pour iphone (dont vous avez entendu parlé sur le blog de notre expert Citrix) :

Après avoir publié le VMware Infrastructure Client sur une ferme XenApp 4.5+ (Presentation Server pour les irréductibles) et configuré un site PNAgent, on obtient un iVMware client :

Bon ok, c’est pas encore ça…

Son script est fait à l’origine pour un host, nous l’avons adapté pour un cluster (il possible de mettre le nom d’un datacenter ou d’un folder sans modification) :

Param ($cluster = "")
#$cluster = "vmcluster"
$iscsiHba = "vmhba32" #might be vmhba33
$iscsiServer = "iscsi_ip"
$iscsiPort = 3260
 
$target = New-Object VMware.Vim.HostInternetScsiHBASendTarget
$target.address = $iscsiServer
$target.port = $iscsiPort
$iscsiauth = New-Object VMware.Vim.HostInternetScsiHbaAuthenticationProperties
#$iscsiauth.ChapAuthEnabled = "true"
#$iscsiauth.ChapName = "user"
#$iscsiauth.ChapSecret = "password"
$h = Get-VMHost -Location $cluster
Foreach ($hostView in ( Get-View -VIObject $h)) {
$storageSystem = Get-View $hostView.configManager.storageSystem
# Enable software iSCSI controller
$storageSystem.UpdateSoftwareInternetScsiEnabled($true)
# Add iSCSI Server for dynamic discovery
$storageSystem.AddInternetScsiSendTargets($iscsiHba, $target)
$storageSystem.UpdateInternetScsiAuthenticationProperties($iscsiHba,$iscsiauth)
# Scan for iSCSI devices
$storageSystem.RescanHba($iscsiHba)
}

Pour des besoins spécifiques (typiquement de performance et/ou de coût), il est parfois nécessaire de déplacer (à chaud bien sur) l’un des vmdk d’une VM sans pour autant déplacer les autres.

Pour cela il faut faire appel au script svmotion.pl disponible dans le VI Remote CLI ou inclus dans l’appliance VIMA.

Malheureusement, et contre toute attente, ce script n’est pas fonctionnel à 100%. En effet, la commande svmotion –interactive ne vous permet pas de déplacer qu’une partie des vmdk mais toute la VM.

Il faut pour cela taper la commande complète, comme par ex :

$ svmotion.pl –url=https://virtualcenter.domain.com/sdk –username=”domaine\user” –password=”password” –datacenter=VMDC –vm=”[old_datastore] VM/VM.vmx: new_datastore” –disks=”[old_datastore] VM/VM.vmdk: new_datastore, [old_datastore] VM/VM_1.vmdk: old_datastore”

Cette commande va déplacer la VM vers le nouveau datastore ainsi que le 1er vmdk et laisser le second sur l’ancien datastore.

Il n’est pas possible de déplacer UNIQUEMENT un vmdk avec cette version du script (cela pourrai changer avec ESX 4 d’après certaines rumeurs…) ce qui signifie que l’on déplace la vm avec ou sans les vmdk et non l’inverse.

Par conséquent, la seule solution pour ne déplacer qu’un vmdk facilement consiste à créer un vmdk supplémentaire à votre vm (1Mo), faire un svmotion du vmdk à déplacer et celui d’1Mo, puis de refaire l’opération inverse avec seulement celui d’1Mo pour “ramener” le vmx au bon endroit. C’est tordu mais ca fonctionne.

/!\ Il est impératif de repréciser à chaque fois l’emplacement d’origine et de destination des TOUS les vmdk dans la commande. /!\

Toutes ces manipulation peuvent être faites graphiquement avec le plugin VIP-SVmotion mais cela reste moins clair qu’en ligne de commande pour ce genre de manipulations.

Tout d’abord, nous vous conseillons vivement de consulter (si ce n’est pas déjà fait) le pdf de Carl A. Waldspurger sur les différentes techniques de “conservation” de la mémoire utilisé par VMware ESX.

Ce document traite notamment de l’un des points fort d’ESX, le Transparent Page Sharing. Pour faire simple, cette fonction fait pointer des pages mémoires identiques (aux seins de différentes VM) vers une page physique.

Voici l’exemple d’un host ESX 3.5 hébergeant 70 VM (presque toutes sous Windows 2003) qui ont 25Go de pages mémoire en commun. Ces 25Go n’occupent que 4Go de RAM physiquement :

D’après VMware, l’overhead de cette fonction n’excéderait pas 1%.

Malheureusement, d’après la récente expérience de Duncan le TPS ne ferait pas bon ménage avec le RVI.

Le RVI (fonctionnalité des CPU AMD) est considéré comme le second niveau de virtualisation matériel. Il permet une accélération matériel de la gestion des transactions vRAM <> pRAM (MMU). En effet, la gestion RAM physique/RAM virtuelle (dans les VM) est traditionnellement gérée de façon logiciel par l’hyperviseur. le RVI permet donc de s’affranchir du coût CPU qu’engendre cette gestion (virtualized MMU).

Jason nous en explique un peu plus sur le fonctionnement du RVI sur son blog et nous informe que la version d’Intel (l’EPT) de cette technologie devrait être disponible dans le courant de l’année.

A la demande de Duncan, Carl nous explique que le RVI fonctionne majoritairement en mode “large pages” (2Mo) ce qui n’est pas compatible avec le TPS (qui ne fonctionne que sur des pages de 4ko).

Cette explication est d’ailleurs confirmée par un white paper VMware sur l’utilisation des “larges pages” :

In ESX Server 3.5 and ESX Server 3i v3.5, large pages cannot be shared as copy‐on‐write pages. This means, the ESX Server page sharing technique might share less memory when large pages are used instead of small pages.

Nous ignorons encore de quelle différence il est question mais le véritable problème est une possible dégradation de performance en cas de memory overcommit trop important:

When free machine memory is low and before swapping happens, the ESX Server kernel attempts to share identical small pages even if they are parts of large pages. As a result, the candidate large pages on the host machine are broken into small pages.

1. Extraire le contenu de l’iso VMware-VMvisor-InstallerCD sur une clef formatée en FAT32
2. Télécharger la derniere version de syslinux et l’extraire n’importe où
3. Exécuter la commande “syslinux.exe -s -m -f -a x:” depuis le répertoire “win32″ de syslinux (où x: est la lettre de votre clef USB)
4. Sur la clef, renommez “isolinux.cfg” en “syslinux.cfg”

Parfait pour les serveurs sans lecteur CD !

En suivant une discussion sur le blog de Duncan Epping (Senior PSO Consultant chez VMware) concernant le design d’un cluster HA répartie sur 2 châssis de lames, nous somme tombés sur un post détaillant le fonctionnement précis de VMware High Availability (HA). Duncan nous a autorisé à le traduire.

Avec les dernières version d’ESX 3.5 & VirtualCenter 2.5, un cluster HA peut contenir 32 nœuds maximum. Contrairement à un cluster XenServer (par exemple…), les différents noeuds d’un cluster HA n’ont pas besoin d’un quorum pour communiquer entre eux. Cet avantage, on le paye forcement d’un inconvénient…

En fait, les nœuds d’un cluster HA ne communiquent pas totalement entre eux : Les 5 premiers (tant qu’ils restent online) serveurs  ajoutés au cluster (primary nodes) se communiquent, via le réseau, les réglages du cluster, leurs état et l’état des autres serveurs (secondary nodes). Les autres serveurs (1 à 27) communiquent leur état aux primary nodes. Tout cela chaque seconde (valeur par défaut, modifiable via l’option das.failuredetectioninterval).

L’un des 5 primary nodes assume le rôle de fail-over coordinator qui coordonnera le redémarrage des vm d’un ou des nœuds HS. Les VM sont redémarrées dans l’ordre où elles ont été coupées (priorité prise en compte).

Malheureusement, un nœud primaire n’est re-promu que si le nœud HS est placé en maintenance mode ou retiré du cluster. Par conséquent, si les 5 nœuds primaires “tombent” aucune vm ne sera redémarrée car aucun  fail-over coordinator ne sera disponible pour gerer cette action.

C’est pour cette raison qu’il est impossible de fixer la tolérance du cluster à plus de 4 nœuds :

Conséquence : En considerant un cluster de 32 nœuds répartis sur 2 châssis (16+16), il est probable que les 5 primary nodes soient dans le même châssis.

le fichier /var/log/vmware/aam/aam_config_util_listnodes.log contient la liste des nœuds et leur type (primary ou secondary) :

La ré-élection d’un primary node étant aléatoire, jouer avec le maintenance mode risque de vous faire perdre la tête, même si c’est la seule solution pour forcer un changement de type.

Ducan suggère une alternative plus sûre qui consiste à créer de plus petit clusters (dans notre cas, 4x 8 nœuds) et de les répartir sur les 2 châssis. Le but étant de diminuer la probabilité que plus de 4 nœuds “tombent” simultanément.

ESX 4 nous fera peut etre grace d’une alternative plus techniquement correct…

Thomas Ackerson de mainesysadmin.com à posté sur son blog un article pour configurer le syslog d’ESX et permettre de regrouper les logs de tous vos ESX vers un serveur syslog.

C’est evidement la meme méthode que pour un syslog standard puisque la COS d’ESX est une RHEL 3 :

• vi /etc/syslog.conf
• *.*    @syslog.domaine.com à ajouter à la fin du fichier
• esxcfg-firewall -o 514,udp,out,syslog pour ouvrir le firewall
• esxcfg-firewall -l pour relancer le firewall
• service syslog restart pour relancer le service syslog

Pour ESXi c’est encore plus simple, il suffit d’aller dans les Advanced Settings du serveur (ou d’utiliser la commande powershell Set-VMHostSysLogServer du VI Toolkit) :

Avec syslog-ng et php-syslog-ng, on obtient un outil indispensable :

Ce script permet, vous l’aurez compris, de déployer des VM à partir d’informations contenu dans un fichier csv, mais surtout d’un template existant dans Virtual Center

Nous nous sommes permis de modifier le script pour y ajouter la possibilité d’ajouter une liste de suffixes dns à la VM, la jonction à un domaine Active Directory, la sélection du Network Label après déploiement et l’affinité CPU.

Nous avons également rajouter une barre de défilement globale et individuelle :

Ce script vous permettra donc de lancer un déploiement massif de VM sans surcharger votre VC (les vm sont déployées en série) et ce avec des paramètres qui peuvent être très différents selon les VM (datastore, IP, Cluster, Ressource Pool, etc…)

N’hésitez pas à nous faire part de vos commentaires et/ou remerciements que nous ne manquerons pas de faire suivre. Thanks Rob !

create-vm.csv

create-vm-csv.ps1

/!\ le script ne vérifie pas (encore) l’espace disponible sur le datastore /!\

MAJ 09/03/2009 :Le symptôme est différent pour ESXi, l’install freeze :

MAJ 09/03/2009 : kduke nous informe (dans les commentaires de ce post) qu’il est possible de contourner le problème en plaçant le CPU ayant le stepping le plus récent en CPU0. Cette manipulation est conseillé par VMware.

Retour d’expérience :

Ce matin, après une installation d’ESX 3.5 (avec l’iso esx-3.5.0_Update_3-123630.iso) impossible de faire booter la machine (IBM eServer BladeCenter HS21 8853G3G). Après analyse du dump log, une seule piste : WARNING: VMK: 538: Initialization of vmkernel failed, status 0xbad0001

3 clics sur Google plus tard, une solution potentielle est donné par membre du forum VMware : les stepping des cpu de la machine ne serait pas identique.

Après download et boot de l’iso CPU Identification Utility (dispo sur le site de VMware), la solution apparaît :

C’est bien la différences des stepping qui est la cause du problème, après changement de cpu l’ESX boot (sans modification quelconque) et le CPU Identification Utility nous confirme :

Moralité : Sur un ESX, les stepping des différents cpu doivent être identiques au sein du même serveur.

Nous nous sommes permis de modifier ce script à notre convenance (avec l’aide d’Hugo), il n’est donc pas identique à celui d’origine.

diskinfo.ps1

Pour faire tourner ce script, vous avez besoin du package powershell et du VMware VI toolkit.

Voici un exemple du résultat :

check_esx3 est un script perl, développé par OP5, exploitant les API VMware pour intéroger un ESX 3(i) via l’https. Pour vous en servir, il vous faudra d’abord installer le VI Perl Toolkit ainsi que le Nagios::Plugin CPAN module.

Ce script vous permettra d’obtenir toutes sortes de renseignement sur vos ESXi (CPU, MEM, NET, IO, VMFS, RUNTIME, …) et de faire de jolis graphs sans forcer :

CHECK_ESX3.PL OK – cpu usage=4006.00 MHz(10.43%) | cpu_usagemhz=4006.00Mhz;; cpu_usage=10.43%;;

CHECK_ESX3.PL OK – mem usage=27537.21 MB(42.02%), overhead=6028.16 MB, swapped=0.00 MB | mem_usagemb=27537.21MB;; mem_usage=42.02%;; mem_overhead=6028.16MB;; mem_swap=0.00MB;;

Bonus : template cacti + scripts perl

il devient alors nécéssaire de killer le process en charge de la VM via la commande kill <id> -9

Pour trouver le process correspondant, il faut utiliser la commande ps -efww |grep <vmx> :

ps -efww |grep W2K3_STD_SP1_FR.vmx
root      2527     1  0 12:16 ?        00:00:00 /usr/lib/vmware/bin/vmkload_app /usr/lib/vmware/bin/vmware-vmx -ssched.group=host/user -# name=VMware ESX Server;version=3.5.0;licensename=VMware ESX Server;licenseversion=2.0 build-64607; -@ pipe=/tmp/vmhsdaemon-0/vmx5161adf574f530a4; /vmfs/volumes/6b1fe479-38e54d7a/W2K3_STD_SP1_FR/W2K3_STD_SP1_FR.vmx

Dans certain cas, il est aussi nécessaire d’exécuter la commande service mgmt-vmware restart si une tache reste bloquée sur le VC.

Avant d’en parler nous souhaitions vérifier qu’il était possible d’utiliser la même clef sur différentes machines tout en conservant le même paramétrage (réseau, iscsi, FC, etc…), c’est chose faite et cela fonctionne à merveille. Nous avons utilisé la clef sur un serveur IBM 3850 M2 puis sur un laptop IBM X61s :

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.