MAJ 16/02/2010 : Si, comme nous, vous rencontrez cette erreur lors de la recréation de la partition vmfs locale, suivez cette kb :
MAJ 02/02/2010 : Comme annoncé par VMware, l’Update 1 d’ESXi 4.0 (build 208167) corrige ce problème (partition VMFS à supprimer avant l’upgrade) :
MAJ 12/08/2009 : Nous avons tenté un “repair” avec le CD d’install d’ESXi et un backup/restore avec la commande vicfg-cfgbackup (depuis une VIMA/vMA) sans succès. La MAJ semble pour le moment impossible dans cette situation. D’après radio moquette, il faudrait attendre ESXi 4.0 U1 !
A mesure de son adoption dans les datacenter, les effets de bords d’update/upgrade d’ESX(i) 4 apparaissent. Si l’on en croit la release note, la version embedded d’ESXi à beaucoup de mal à être mise à jour. Malheureusement elle n’est pas la seule car la version installable peut également souffrir des mêmes maux dans certaines circonstances :
Après plusieurs Upgrade effectuées sans l’ombre d’un bug (que ce soit avec VUM ou Host Update Utility), nous avons eu récemment cette déplaisante surprise :
Contrairement à ce que nous espérions, le mode de fonctionnement du Cluster HA de VMware n’a pas évolué avec l’arrivée d’ESX(i) 4. Le nombre de Primary Nodes est toujours limité à 5 et un cluster qui perdrait tous ses Primary Nodes se verrait toujours dans l’impossibilité de redémarrer ses VM sur ses Secondary Nodes.
Derrière “VMware HA” se cache la solution Legato AAM (Automated Availability Manager) acquise par EMC en 2003. Cette solution de cluster possède un mode Cli qui permet de nombreuses opérations manuelles dont la manipulation des rôles des différents noeuds.
Ces failles permettraient un memory leak du host au guest (interceptions de données provenant de la zone mémoire d’autres VM ?) et pire encore : exécuter du code sur le host via un guest (via le support Direct3D, actif par défaut sur ESX(i) 4.0).
Loading ...
