La solution la plus “connue”, même si c’est la moins pratique à notre avis, est le boot from SAN. En plus d’être longue à mettre en place, cette solution impose une dépendance forte au SAN qui peut poser de sérieux problèmes en cas d’incident sur la baie ou la fabric. A notre avis, le seul avantage de cette solution est la redondance liée au multipathing scsi.

La deuxième solution est évidemment le boot PXE, connue depuis qu’Autodeploy fait partie officiellement de l’arsenal de déploiement d’ESXi. Bien que pensé à la base pour du PXE, l’idée de dépendre du réseau pour booter ESXi ne fait pas encore l’unanimité. Il est possible de booter en PXE en repoussant un backup de la configuration (comme le faisait PXE Manager) mais la solution officielle de VMware est Autodeploy qui boot des ESXi vierges et repousse un host profile dessus. Pour peu que l’infrastructure DHCP/TFTP/vCenter soit hébergée sur les ESX managés par cette même infra, vous avez l’interdiction de couper le courant à vie.

La troisième solution est le boot from USB flash ou SD flash qui fut la solution “de lancement” d’ESX 3i en 2007 :

[...] Veso has thrown out hard disks in favor of embedding VMware’s new 32MB ESX 3i hypervisor in flash memory.

Cette solution à l’avantage d’être peut coûteuse, facile à mettre en place et indépendante. ESXi étant stateless, le nombre d’écritures sur la mémoire flash est très faible et réduit par conséquent les risques d’usure prématurée du support. C’est selon nous la solution la plus élégante et efficace, c’est donc celle ci que nous avons choisi pour libérer les 2 slots disques de nos blades.

Suite à de nombreux problèmes de contrôleurs, le cartes SD et micro SD ont pris le dessus sur les clefs USB en entreprise mais le principe reste identique donc nous testerons notre méthode de migration sur une clef kingston. Le principe est de restaurer un backup du bundle d’un ESXi visor-thin sur une nouvelle installation visor-usb.

visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment

Après avoir vérifié qu’aucune trace du “mode” d’installation n’était présente dans le fichier esx.conf du bundle, nous avons tout simplement utilisé vmplayer pour tester la migration sur un ESXi nested. Et pour ceux qui se demande comment nous avons booté sur une clef usb avec vmplayer, allez faire un tour chez Plop :

Comme vous pouvez le constater, la migration vers une clef usb se déroule sans accrocs et si VMware vous dit que ce n’est pas une méthode supportée, demandez leur de vous prouver que vous l’avez utilisé…

Vous pouvez par exemple générer la liste des requêtes SQL permettant de mettre à jour les hostname en fonction de l’ip correspondante, en powershell bien sur :

Get-View -ViewType hostsystem -property name|select name,@{n="vmk";e={[System.Net.Dns]::GetHostAddresses($_.name)|%{$_.IPAddressToString}}}|%{$sql = 'update PXE_HOST set HOSTNAME = "' + $_.name + '" where IP = "' + $_.vmk + '";';$sql}

Vous pouvez aussi en profiter pour traquer les doublons avec cette requète SQL :

SELECT HOSTNAME, COUNT(HOSTNAME) AS NumOccurrences FROM PXE_HOST GROUP BY HOSTNAME HAVING ( COUNT(HOSTNAME) > 1 );

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 !

Alors que nous nous intéressions de près à une solution de déploiement stateless PXE d’ESXi, il devenait évident qu’il allait falloir à un moment ou à un autre partager ou extraire les fichiers configBundle de la vMA (ou d’un Windows avec Power CLI) pour que le serveur TFTP puissent les transmettre aux ESXi lors du boot. Mais il y a aussi plus simple : installer les services DHCP et TFTP sur la vMA.

L’appliance de VMware est un RHEL 5 x64, nous avons donc fouillé dans les CD d’install originaux de cette version que nous avions sous la main (attention à la licence…) et en avons extrait dhcp-3.0.5-18.el5.x86_64.rpm et tftp-server-0.42-3.1.x86_64.rpm qui feront parfaitement l’affaire pour notre petite expérience

Pour rendre certaines manipulations plus simple, nous avons préalablement déverrouillé le compte root (dans le fichier /etc/passwd). Il faut ensuite installer les packages et configurer les services associés, puis autoriser le tftp dans le firewall. Nous avons également augmenté la taille des partitions pour plus de confort :

• rpm -i ./dhcp-3.0.5-18.el5.x86_64.rpm
• rpm -i ./tftp-server-0.42-3.1.x86_64.rpm
• /sbin/chkconfig –level 345 xinetd on
• /sbin/chkconfig –level 345 tftp on
• /sbin/chkconfig –level 345 dhcpd on
• ajouter -A RH-Firewall-1-INPUT -p udp -m udp –dport 69 -j ACCEPT dans /etc/sysconfig/iptables
• augmenter la taille des partitions de la vMA

Vous modifiez le dhcpd.conf selon vos besoins, ainsi que les réservations MAC/IP :

Il faut ensuite configurer la partie tftp tel que décrit par Jim McCann et William Lam.  Nous avons opté pour une arborescence organisée par version d’ESXi (installable & embedded) ainsi qu’un répertoire dédié aux configBundle et un autre pour les agents vpxa (vcenter) et aam (cluster HA) :

le répertoire pxelinux.cfg est quant à lui dédié aux réservations MAC/ESXi :

Voici un extrait d’un de nos fichiers de configuration pxelinux :

default menu.c32
menu title PXE Boot VMware ESXi ESX4i-8
timeout 30

label ESXi 4.0.0 b208167
menu label Boot VMware ESXi 4.0.0 b208167
kernel ./mboot.c32
append /eESX4.0b208167/vmkboot.gz — /eESX4.0b208167/vmk.gz — /eESX4.0b208167/sys.vgz — /eESX4.0b208167/cim.vgz — /eESX4.0b208167/oem.tgz — /eESX4.0b208167/license.tgz — /agents/vpxa-208111.vgz — /agents/aam-208111.vgz — /configBundle/configBundle-ESX4i-8.tgz
ipappend 2

label ESXi 4.0.0 b193498
menu label Boot VMware ESXi 4.0.0 b193498
kernel ./mboot.c32
append /eESX4.0b193498/vmkboot.gz — /eESX4.0b193498/vmk.gz — /eESX4.0b193498/sys.vgz — /eESX4.0b193498/cim.vgz — /eESX4.0b193498/oem.tgz — /eESX4.0b193498/license.tgz — /agents/vpxa-208111.vgz — /agents/aam-208111.vgz — /configBundle/configBundle-ESX4i-8.tgz
ipappend 2

Les configBundle sont recueillis par un script éxécuté par la crontab (le fichier esxi.csv peut contenir une liste de noms ou d’IP) :

awk -F’;’ ‘{ print $1 }’ ./esxi.csv | while read name
do
esxcfg-cfgbackup –server $name –username root –password ” -s /tftpboot/configBundle/configBundle-$name.tgz
done

Les agents vpxa et aam sont extraits du répertoire /bootbank d’un ESXi “type”. Ces agents évoluant au fil des version de vCenter, il faut les mettre à jour pour ne pas que le vCenter le fasse à chaque reboot des ESXi :

Lorsque tous les composants sont opérationnels, c’est magique :