Hypervisor.fr

Comme le précise le comparatif ESX/ESXi de VMware, les paramètres de configuration ne peuvent être modifiés par Remote CLI que si une licence Foundation, Standard, ou Enterprise est attachée à l’ESXi.

Il y a quelques jours, nous découvrions avec grand étonnement plaisir que VMware avait rendu les api RCLI pour ESXi read-write pour la version gratuite, grâce à l’update 3.

Mais en fait, non :

With the release of VMware ESXi 3.5 Update 3, some API calls became freely available.  As it turns out, these new APIs were opened up unintentionally.  This inadvertent change happened when VMware was resolving an API-related bug.

Only customers who downloaded the free version of ESXi have been affected.  VirtualCenter and VI (Foundation, Standard, Enterprise) customers are not affected.

My VMware contacts tell me that this bug will be fixed shortly, and the next release will lock down the RCLI again.

Merci à Rich Brambley pour l’info.

Tags: bug, Bullshit, ESXi, VMware

Vladan.fr à publié il y a 1 mois environ un tutorial “DIY” d’une clef USB ESX 3i.

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 :

Tags: ESX3i, Tips & Tricks

Virtualization.info nous rapporte un élément très intéressant de la roadmap Xen : Le projet Kerami sera inclus dans version 3.4 de l’hyperviseur open-source.

En deux mots, cette fonction est à peu de chose prêt équivalente à la fonction FT d’ESX 4.0

Comme le fait remarquer Alessandro Perilli, cela va certainement plaire à Citrix mais beaucoup moins à Marathon…

Tags: ESX 4.0, XEN

Kenon Owens (de chez VMware) nous rapporte sur son blog un comparatif de 2 benchmarks produits avec vConsolidate (Intel). Il en ressort qu’ESX 3.5 serrait de 22% à 125% plus performant qu’Hyper-V.

vConsolidate, à la manière de VMmark, “empile” des blocs identiques constitué de 5 VM typiques (web, bdd, mail, java et idle) jusqu’à ce que le serveur ateigne 100% de charge.

On regrettera malgré tout que ce bench n’ait pas été fait avec la meme version (même si Intel assure que les 2 sont comparables) et surtout pas avec la même config de RAM (32 x 2GB contre 16 x 4GB).

Cela fait tout de même très plaisir à Kenon : “This comparison proves that VMware ESX server is NOT a commodity!”

Tags: Benchmark, ESX, Hyper-V

MAJ 14/12/2008 : Le patch ne corrige pas le problème, pour le moment seulement un workaround.

MAJ 03/12/2008 : VMware a enfin rendu disponible le patch corrigeant ce problème.

A peine l’histoire du “timebomb” de l’update 2 oubliée, un nouveau bug frappe la dernière update (build 123630) d’ESX 3.5

Ce bug touche l’option “Virtual Machine Monitoring” qui reboot les VMs ne renvoyant plus de “heartbeat“. Lorsque cette option est activée dans un cluster HA/DRS et qu’une VM subit un Vmotion (vers un serveur ayant recu l’update en question) sur recommandation du DRS, il y a de fortes probabilitées que cette VM soit rebootée une fois le Vmotion terminé.

ivobeerens.nl nous apprend qu’il suffit de désactiver l’option pour contourner le problème et qu’une update sera disponible dans la journée du 20 novembre 2008 :

“I made a support request @ VMware. The told me today that 20 November patch 10 for VMware 3.5 Update 3 will be released. Patch 10 fixes SOME random reboot problems in Update 3. I hope it resolves this nasty issue.”

Le forum de vmware commence à flamber… (ici, ici et ici)

Autre détail, les VM sous Windows ayant souffert du problème présentent ce symptôme dans l’eventlog :

Tags: bug, ESX, VMware