Hypervisor.fr

La vSphere Management Assistant (aka vMA/VIMA) devient indispensable lorsqu’il s’agit d’administrer ESXi en masse. A ce titre, nous utilisons régulièrement la commande  <esxcfg-cfgbackup> qui permet comme vous le savez/devinez le backup de la config d’un ESXi et la restaurer en cas de besoin (pour un changement de serveur par exemple).

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.

Read more …

Tags: ESXi, PXE, VIMA

Slashdot nous rapporte qu’Hyper-V R2 est vulnérable à un bug des processeurs Nehalem (identifié depuis 2 mois). Intel semble avoir “convaincu” Microsoft de ne pas faire de communication officielle et le seul correctif disponible à l’heure actuelle désactive certaines fonctionnalités d’économie d’énergie.

Extrait que la kb Microsoft :

This problem occurs because spurious interrupts are generated on the computer that uses Intel code-named Nehalem processors. These interrupts are caused by a known erratum that is described in the following Intel documents.

Tags: bug

Officiellement, il n’est pas possible d’augmenter la taille d’un vmdk si un ou plusieurs snapshot en dépendent :

You cannot increase the size of a virtual machine’s hard disk after you create a snapshot of the virtual machine.

There is no workaround.

Au fil des version d’ESX, on a droit à plusieurs scénarii. Pour les plus anciennes versions d’ESX 3.5, le resize est possible en GUI mais la VM refusera de booter après.

Pour les version les plus récentes d’ESX 3.5, si la VM est OFF il ne se passe strictement rien après le changement de taille mais si la VM est démarrée on a droit à un simple message d’erreur après tentative.

VMware a fini par réagir avec la version 4 en bridant la fonctionnalité via la GUI :

La raison de cette limitation semble évidente mais comme nous l’a habilement fait remarqué un collègue, “cela pourrai être géré par le système”. Après un bref googling, nous trouvons la clef de l’énigme chez sanbarrow, un vétéran de la communauté vmware et créateur de MOA (aka Multi Operating system Administration / Addicts) :

fix Extent description to the size after expand

Voici la procédure en détail (VM OFF) :

• Augmenter la taille du vmdk avec vmkfstools
• Relever la nouvelle taille dans la section “Extent description”
• Remplacer l’ancienne valeur dans le vmdk du (ou des) snapshot
• Reloader la vm (vim-cmd ou vmware-cmd)

Comme toujours, si vous ou l’un de vos équipiers étiez grillés par VMware, Hypervisor.fr nierait avoir eu connaissance de vos agissements. Ce post s’autodétruira dans cinq secondes.

Tags: snapshot

Présent au VMUG d’hier dans les locaux de VMware, nous avons eu l’opportunité de voir une alpha de CVP (bare-metal client hypervisor) annoncé au vmworld 2009 à Cannes. Heureusement, Olivier PARCOLLET (un des fondateurs du VMUG Français) avait son caméscope :

Tags: VMUG

MAJ 10/12/2009 : Une nouvelle version de l’Update 1 pour ESX 4.0 a été republiée pour contourner le bug : l’Update 1 A

MAJ 27/11/2009 : Il semblerai que ce bug soit uniquement lié aux serveurs HP.

Si vous avez des hosts ESX 4.0 (ESXi n’est pas concerné) avec des agents installés (IBM Director, HP Insight, etc…) NE FAITES PAS l’upgrade (avec VUM) vers la version 4.0 U1 AVANT d’avoir désactivé ces agents :

Upgrading ESX 4.0 to 4.0 U1 using Update Manager fails or times out and rebooting the host results in a purple diagnostic screen

[...]

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

Tags: bug