On y découvre notamment le secret du format vmtar qui permet de d’optimiser le contenu des tardisks pour que TPS soit le plus efficace possible sur la zone mémoire utilisé par l’hyperviseur.

When the system image is built, the system tar archives that become the tardisks are constructed as usual. These tardisks are processed by the vmtar tool, which reorders the content to page align the binaries and add the number of pages needing fix-ups to their metadata header.

On retient également le principe de base qui fait d’ESXi un hyperviseur aussi léger qu’efficace :

Complexity is pushed to offline tools so that simplicity can be kept in the running system.

Ceux qui l’auraient raté peuvent également consulter la session TA8245 du VMworld 2010 “ESXi Internals: Better Understanding for Better Management and Troubleshooting” pendant laquelle VisorFS est également abordé.

]]> http://www.hypervisor.fr/?feed=rss2&p=3819 0 http://www.hypervisor.fr/?p=3631 http://www.hypervisor.fr/?p=3631#comments Sat, 25 Feb 2012 10:49:30 +0000 NiTRo http://www.hypervisor.fr/?p=3631 Juste une petite news vite fait pour vous dire qu’on a testé l’application HP iLO Mobile Toolbox pour iPad/iPhone et que c’est le top pour les réunions qui traînent en longueur… :

MAJ 12/12/2011 : Mise à jour des scripts pour assurer la cohérence hostname/HA

MAJ 15/12/2011 : Sur un cluster en v4 il nous a fallu désinstaller les agents aam manuellement et redémarrer le service hostd

Si vous avez besoin de changer le nom d’un ESXi connecté à un vCenter, la méthode officielle consiste à détacher le server du vcenter, le renommer et le rattacher au vcenter. En plus d’être fastidieuse, cette action occasionnera la perte de certaines informations telles que les  statistiques ou le Swapfile Location. Pas cool.

Heureusement pour nous, il existe une solution de contournement qui va encore nous faire tâter du PowerCLI : la méthode ReconnectHost à laquelle on peut passer un certain nombre d’arguments comme le hostname ou plutôt un FQDN valide car ce paramètre n’à pas à correspondre obligatoirement au hostname de l’ESXi.

vSphere/PowerCLI 4 :

Get-VMHost oldhostname.olddomain.com|Get-View|%{(Get-View $_.ConfigManager.NetworkSystem).UpdateDnsConfig((New-Object VMware.Vim.HostDnsConfig -property @{Hostname = "newhostname";domainName = "newdomain.com";dhcp = $_.Config.Network.DnsConfig.Dhcp;address = $_.Config.Network.DnsConfig.Address;searchDomain = $_.Config.Network.DnsConfig.SearchDomain}));$_.DisconnectHost();$_.ReconnectHost((New-Object VMware.Vim.HostConnectSpec -property @{HostName = "newhostname.newdomain.com"}))}

vSphere/PowerCLI 5 :

Get-VMHost oldhostname.olddomain.com|Get-View|%{(Get-View $_.ConfigManager.NetworkSystem).UpdateDnsConfig((New-Object VMware.Vim.HostDnsConfig -property @{Hostname = "newhostname";domainName = "newdomain.com";dhcp = $_.Config.Network.DnsConfig.Dhcp;address = $_.Config.Network.DnsConfig.Address;searchDomain = $_.Config.Network.DnsConfig.SearchDomain}));$_.DisconnectHost();$_.ReconnectHost((New-Object VMware.Vim.HostConnectSpec -property @{HostName = "newhostname.newdomain.com"}),$null)}

Le one-liner ci-dessus (attention à la version) effectue les actions suivantes :

• déconnexion de oldhostname.olddomain.com du vcenter (et dé-configuration d’HA le cas échéant)
• reconnexion de l’ESXi au vcenter avec le nouveau nom (si newhostname.newdomain.com est valide)
• change le hostname newhostname et newdomain.com de l’ESXi (ne nécessite pas de reboot depuis la v4)

/!\ Ce script ne met pas à jour les IQN et ne régénère pas les certificats des ESXi /!\

]]> http://www.hypervisor.fr/?feed=rss2&p=3508 1 http://www.hypervisor.fr/?p=2887 http://www.hypervisor.fr/?p=2887#comments Fri, 22 Apr 2011 21:04:00 +0000 NiTRo http://www.hypervisor.fr/?p=2887 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 !

Hobby Boards est un des sites très connus dans le petit monde du 1-Wire qui fournissent de quoi se monter un réseau de capteurs.

L’intérêt des produits Hobby Boards est d’utiliser le RJ45 comme connectique pour relier les capteurs, ce qui rend possible des montages reliés par des baies de brassage classique.

Nous utilisons, depuis quelques temps déjà, 2 capteurs Humidity/Temp et un adaptateur série (pour maximiser la comparabilité avec les systèmes embedded type WRT54G) connectés à un Linux grâce à OWFS (one wire filesystem) qui permet de monter les capteurs dans le filesystem de l’OS pour facilement les interroger via un script. Couplé à cacti, on obtient de beau graphiques :

(on voit clairement ici que le capteur ne craint pas le gel…)

(à l’intérieur c’est nettement plus stable…)

Vous trouverez une compilation de liens dans la rubrique “links” (étonnamment) d’Hobby Boards. Évidement c’est beaucoup plus fun et moins cher qu’une solution snmp/ip/web/kifélecafé/holinewouane…

Get-VMHost|?{$_.PowerState -eq "poweredOn"}|?{($_|Get-VMHostAdvancedConfiguration -Name Net.FollowHardwareMac).values -contains "0"}|Set-VMHostAdvancedConfiguration -Name Net.FollowHardwareMac -Value "1"

Sur ESXi, si vous devez remplacer une carte réseau utilisée par une interface vmkernel de management ou si vous restaurez la configuration d’un serveur sur un autre (panne hardware par ex), vous vous retrouver dans une situation où l’adresse MAC de la carte réseau du (ou des) “vmkernel port” a changée. Pour que ce changement soit bien effectif, et pour éviter que l’ESXi ne communique avec l’ancienne MAC (problématique en cas de boot PXE/DHCP ou de sécurité réseau renforcé), il faut activer le paramètre indiqué dans cette kb :

The MAC address of vmk0 management network might not get updated after you replace or assign a new MAC address to the NIC
[...]
esxcfg-advcfg -s 1 /Net/FollowHardwareMac

Sinon, on obtient ceci :

Par contre ce n’est valable que pour l’interface de management :

[ESXi on an SD Card] For ESXi, it is 1GB if installing on flash/SD. It is also 1GB if installing on disk, but 5GB is recommended for auto creation of the scratch partition. That partition is not required and can be created after the fact but it’s easier and more trouble-free to have the system create it. Note that it is never created on flash/SD, so for that support, the number is always 1GB and the scratch will go elsewhere.

Maintenant vous n’avez plus d’excuses.

Cette update est accompagnée de la fin du support Général pour ESX(i) 3.5 et pour VC 2.5 fixée au 21/05/2010. La fin du support étendu est quant à lui fixé au 21/05/2013, ce qui laisse encore un peu de temps pour l’upgrade.

Pour les plus parano, la liste des EOS pour vSphere est disponible ici

]]> http://www.hypervisor.fr/?feed=rss2&p=1703 5 http://www.hypervisor.fr/?p=1644 http://www.hypervisor.fr/?p=1644#comments Fri, 04 Dec 2009 11:58:48 +0000 NiTRo http://www.hypervisor.fr/?p=1644 La 5ème Update d’ESX(i) 3.5 est disponible depuis ce matin. Il s’agit principalement de correction de bug et d’update de drivers mais aussi du support de nouveaux guest OS pour ceux qui n’ont pas encore migré sous ESX(i) 4.0

VMware recommande l’update des VMtools en cas de mise à jour des hosts et attire notre attention sur la matrice de compatibilité vcenter/esx(i).

ESXi 3.5 U5 Installable Release Notes
ESXi 3.5 U5 Embedded Release Notes
ESX 3.5 U5 Release Notes

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 :

Get-View -ViewType HostSystem |?{$_.config.product.ProductLineId -eq "embeddedEsx"} |?{$_.Runtime.ConnectionState -eq "connected"}|%{Get-VMHostFirmware -VMHost $_.Name -BackupConfiguration -DestinationPath C:\temp\}

Les plus observateurs aurons remarquez que le backup passe maintenant par la cmdlet Get-VMHostFirmware mais pour restaurer un bundle, c’est toujours Set-VMHostFirmware qu’il faut utiliser. En local sur l’ESXi (aka “ESXi shell”) c’est avec la commande vim-cmd que ça se passe.

Un des gros avantages d’ESXi est qu’il a été à l’origine conçu pour être booté via PXE. Pour cette raison entre autres, la config complète (hors VM bien sûr) d’ESXi est backupée toutes les heures (par la crontab /var/spool/cron/crontabs/root) sous la forme d’un package (state.tgz) qui servira au prochain boot (statefull ou stateless) ou à la cmdlet Set-VMHostFirmware. Le script suivant sauvegarde le configBundle de chaque ESXi, facilement utilisable dans une tache planifiée sur votre vCenter :

$backpath = "c:\bundle_backup\"
$eVMHs = Get-View -ViewType HostSystem |?{$_.config.product.ProductLineId -eq "embeddedEsx"} |?{$_.Runtime.ConnectionState -eq "connected"}
	Foreach	($eVMH in $eVMHs)
	{Set-VMHostFirmware -VMHost $VMH.name -BackupConfiguration -DestinationPath $backpath}

Sur le screenshot, vous pouvez constater que pour 39 ESXi, la taille totale du backup dépasse à peine 1Mo. En détail, le configBundle d’un host standalone pèse environ 10ko et celui d’un host membre d’un cluster HA pèse environ 100ko (à cause de l’agent AAM). Malgré sa petite taille, ce bundle contient chaque paramètre de la configuration de l’ESXi, y compris le certificat SSL. Ce qui signifie qu’il est possible d’échanger une machine sans impact grâce à ce bundle.

/!\ le bundle est lié à la version de l’ESXi dont il provient et ne peut doit être restauré que sur un ESXi de version identique /!\

En prévision d’une upgrade massive d’un châssis, nous avons testez 2 kit de 16Go dans une HS21 [8853C2G] sur ESXi 3.5 U4 avec succès :

If any problem is detected during the boot process, the system automatically boots from the previously used bank of memory.

Suite à une update, le serveur reboot et fini en PSOD :

Après un hard reset, le serveur à booté sur la version précédente du firmware et nous avons pu constaté la cause du problème (aussi corrigé automatiquement d’ailleurs) en relançant une update avec VUM :

Après reboot, le nouveau firmware est opérationel :

Respect !

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”.

“Récemment, VMware a demandé à Veeam d’interrompre le support de la version gratuite d’ESXi par Veeam Backup et Replication afin d’être en accord avec la nouvelle politique de licence de VMware,” poursuit Ratmir Timashev. “Compte tenu de cette demande de VMware et de notre étroit partenariat technologique, Veeam Backup et Replication ne supportera dorénavant plus la version ESXi Free Edition. Néanmoins nous continuerons à supporter la version gratuite d’ESXi pour nos clients existants qui ont acquis une version antérieure à Backup & Replication 3.1.”

Pour les petites entreprises et les agences, Veeam conseille aux nouveaux clients d’acquérir VMware vSphere Essentials et la nouvelle offre Veeam Essentials. L’achat conjoint de ces deux offres a une valeur identique à celle de l’achat de Veeam Backup pour la version d’ESXi Free Edition. Et elle offre en plus Veeam Monitor et Veeam Reporter, pour une valeur ajoutée supplémentaire non négligeable.

Les voies du capitalisme sont impénétrables…

Ken Cline, un membre reconnu de la communauté et depuis peu Senior Consultant chez VMware, a bouclé il y a quelques jours son “Great vSwitch Debate”. Tout a commencé sur le forum VMware et a fini sur son blog par un énorme article en 8 parties.

Il est question d’à peu près tout ce qu’un admin VMware doit savoir sur le fonctionnement d’un vSwitch et des config optimales en fonction du nombre de cartes réseau physiques disponibles.

La partie 3 est particulièrement intéressante techniquement car Ken détaile les différentes méthodes de load-balancing. On y apprend, par exemple, l’utilisation des ports d’un vSwitch en fonction de la séquence de démarrage des vm :

Incontournable pour n’importe quel vAdmin…

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

Merci à “Windows” qui se verra remettre son mojito comme promis !

Xtravirt est le spécialiste du “VI3 in a box”. Leurs whitepapers pour faire tourner ESX sur VMware Workstation sont en effet bien connu de la communauté VMware, mais la licence pour Workstation restait le point faible de cette technique.

Il semble que ce soit de l’histoire ancienne si l’on en croit la récente publication des whitepapers “How to Install ESX 3.5 and ESXi as a VM on VMware Server 2.0″ et “How to Install VMware ESX3.5 on VMware Player as a VM”.

Malheureusement, nous n’avons pas été en mesure d’accomplir une install stable que ce soit pour ESX ou pour ESXi sur VMware Server 2.0 alors que cela ne nous a posé aucun problème sur Workstation 6.5

Un membre d’Xtravirt confirme pourtant sur VM/ETC que cela ne pose aucun problème. Un mojito offert à celui ou celle qui nous envoi un screenshot le prouvant !