Notes de mise à jour de VMware ESXi 4.1 Update 2

Nous contacter
 

ESXi 4.1 Update 2 Installable | 27 OCT 2011 | Build 502767
ESXi 4.1 Update 2 Embedded | 27 OCT 2011 | Build 502767
VMware Tools | 27 OCT 2011 | Build 493255

Dernière mise à jour du document : 27 OCT 2011

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

Les informations suivantes décrivent quelques-unes des améliorations disponibles dans cette version de VMware ESXi :

  • Support de nouveaux processeurs — La mise à jour ESXi 4.1 Update 2 prend en charge AMD Opteron 6200 series (Interlagos) et AMD Opteron 4200 series (Valencia).

    Remarque : Pour les processeurs AMD Family 15h, ESX/ESXi 4.1 Update 2 traite chaque cœur dans une unité de calcul comme un cœur indépendant, sauf lors de l'application des licences. Pour l'application des licences, ESX/ESXi traite chaque unité de calcul comme un cœur. Par exemple, bien qu'un processeur avec 8 unités de calcul puisse fournir l'équivalent de 16 cœurs de processeur dans la mise à jour ESX/ESXi 4.1 Update 2, il utilise 8 licences seulement.
  • Support de pilote supplémentaire — La mise à jour ESXi 4.1 Upgrade 2 prend en charge les mises à jour du pilote RAID Dell PERC8.

Problèmes résolus –En outre, cette version résout divers problèmes documentés dans la section Problèmes résolus.

Haut de la page

Versions antérieures d'ESXi 4.1

Les fonctions et problèmes connus des versions antérieures d'ESXi 4.1 sont décrits dans les notes de mise à jour de chaque version. Pour consulter les notes de mise à jour antérieures d'ESXi 4.1, cliquez sur l'un des liens suivants :

Haut de la page

Avant de commencer

Compatibilité de version ESXi, vCenter Server et vSphere Client

La matrice de compatibilité vSphere fournit des détails sur la compatibilité des versions actuelles et précédentes des composants de VMware vSphere, dont ESXi, VMware vCenter Server, vSphere Client et d'autres produits VMware en option.

Compatibilité ESXi, vCenter Server et VDDK

Virtual Disk Development Kit (VDDK) 1.2.1 ajoute le support des versions ESXi 4.1 Update 2 et vCenter Server 4.1 Update 2. Pour de plus amples informations sur VDDK, voir https://www.vmware.com/support/developer/vddk/.

Compatibilité matérielle

  • En savoir plus sur la compatibilité matérielle

    Les listes de compatibilité matérielle sont disponibles dans le Guide de compatibilité Web. Le Guide Web de compatibilité matérielle est un point d'accès unique à tous les guides de compatibilité VMware et offre la possibilité de rechercher les guides et de sauvegarder les résultats de recherche sous format PDF. Par exemple, avec ce guide, vous pouvez vérifier que le serveur, les E/S, le stockage et les systèmes d'exploitation client sont compatibles.

    Inscrivez-vous pour être informé des mises à jour du Guide de compatibilité via Ceci est l'image RSS qui sert de lien d'accès à un flux RSS.
  • En savoir plus sur la compatibilité vSphere :

    Matrices de compatibilité VMware vSphere ( PDF)

Installation et mise à niveau

Lisez le Guide de configuration de vCenter Server et ESXi Installable pour un accompagnement étape par étape sur l'installation et la configuration d'ESXi Installable et de vCenter Server ou le Guide de configuration de vCenter Server et ESXi Embedded pour un accompagnement étape par étape sur la configuration d'ESXi Embedded et de vCenter Server.

Après une installation réussie d'ESXi Installable ou un démarrage réussi d' ESXi Embedded, vous devez procéder à plusieurs étapes de configuration. Notamment, pour l'octroi de licences, la mise en réseau et la sécurité. Reportez-vous aux guides suivants de la documentation vSphere pour un accompagnement sur ces tâches de configuration.

Si vous avez installé VirtualCenter 2.x, voir le Guide de mise à niveau vSphere pour les instructions d'installation. vCenter Server sur un système d'exploitation de 64 bits et la protection de la base de données de VirtualCenter.

Les fichiers MIB (Management Information Base) relatifs à ESXi ne sont pas livrés avec vCenter Server. Seuls les fichiers MIB liés à vCenter Server sont livrés avec vCenter Server 4.0.x. Vous pouvez télécharger tous les fichiers MIB à partir du site Web de VMware sur http://www.vmware.com/fr/download.

Mise à niveau de VMware Tools

VMware ESXi 4.1 Update 2 contient la dernière version de VMware Tools. VMware Tools est une suite d'utilitaires qui améliore les performances du système d'exploitation client de la VM. Reportez-vous aux Problèmes résolus de VMware Tools pour une liste des problèmes résolus dans cette version ESXi relative à VMware Tools.

Pour déterminer une version installée de VMware Tools, voir Vérification d'une version de VMware Tools (KB 1003947).

Mise à niveau ou migration vers ESXi 4.1 Update 2

ESXi 4.1 Update 2 offre les options suivantes pour la mise à niveau :

  • VMware vCenter Update Manager. Module vSphere qui prend en charge les mises à niveau directes d'ESXi 3.5 Update 5, ESXi 4.0.x et ESXi 4.1 vers ESXi 4.1 Update 1.
  • vihostupdate. Utilitaire de ligne de commande qui prend en charge les mises à niveau directes d'ESXi 4.0 et ESXi 4.1 Update 1 vers ESXi 4.1 Update 2. Cet utilitaire nécessite vSphere CLI. Pour plus d'informations, voir le Guide de mise à niveau vSphere. Pour appliquer le bundle VEM, exécutez la solution palliative en utilisant l'utilitaire vihostupdate . Ceci permet d'ajouter l'hôte ESXi 4.1 Update 2 Embedded à Cisco Nexus 1000 AV 2 vDS. .

Chemins d'accès de mise à niveau pris en charge pour la mise à niveau de l'hôte vers ESXi 4.1 Update 2 :

Livrables de mise à jour
Outils de mise à niveau pris en charge
Chemins de mise à niveau pris en charge vers ESXi 4. 1 Update 2

ESXi 3.5 Update 5

ESXi 4.0
inclut :
ESXi 4.0 Update 1
ESXi 4.0 Update 2
ESXi 4.0 Update 3

ESXi 4.1

upgrade-from-ESXi3.5-to-4.1_update02.463540.zip
VMware vCenter Update Manager avec ligne de base de mise à niveau de l'hôte

Oui

Non

Non
upgrade-from-esxi4.0-to-4.1-update02-463540.zip
  • VMware vCenter Update Manager avec ligne de base de mise à niveau de l'hôte
  • vihostupdate

Non

Oui

Non
update-from-esxi4.1-4.1_update02.zip
  • VMware vCenter Update Manageravec ligne de base de correctifs
  • vihostupdate
Non
Non
Oui

Remarques :

Correctifs contenus dans cette version

Cette version contient tous les bulletins d'ESXi qui ont été publiés avant la date de publication de ce produit. Reportez-vous à la page Télécharger correctifs de VMware pour plus d'informations sur les bulletins individuels.

En plus du format de fichier ZIP, la version ESXi 4.1 Update 2, intégrée et installable, est distribuée sous la forme d'un correctif qui peut être appliqué aux installations existantes du logiciel ESXi 4.1.

La version corrective ESXi410-Update02 contient les bulletins individuels suivants :

ESXi410-201110201-SG : Mises à jour du microprogramme ESXi 4.1
ESXi410-201110202-UG : Mise à jour ESXi 4.1Tools


ESXi 4.1 Update 2 contient également tous les correctifs dans les bundles déjà publiés suivants :

ESXi410-201010401-SG Mises à jour du microprogramme
ESXi410-201010402-BG Updates VMware Tools

Pour plus d'informations sur le contenu de chaque correctif, reportez-vous aux documents énumérés sur la page de téléchargement.

Résolution des problèmes

Cette section décrit les problèmes résolus dans cette version dans les domaines suivants :

Les problèmes résolus précédemment documentés comme des problèmes connus sont marqués du symbole †.

Sauvegarde

  • Les machines virtuelles se mettent parfois hors tension lors de la création ou de la suppression de snapshots


    • vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file
    vmx| Msg_Post: Error
    vmx| [msg.checkpoint.continuesync.fail] Error encountered while restarting virtual machine after taking snapshot. The virtual machine will be powered off.

CIM et API

  • L'API RefreshDatastore n'affiche pas d'erreur lorsqu'elle est appelée dans une banque de données qui est hors ligne



  • L'hôte ESXi indique que le type de mémoire est inconnu

    • Inconnu

  • L'installation d'ESXi 4.1 Update 1 embedded et le redémarrage du système provoquent le vidage du cœur de world utilisateur



    • CoreDump: 1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003
    qlogic-fchba-provider-410.1.3.5-260247 (version 1.3.5) in esx41u2
  • Le serveur CIM envoie des alertes non valides à IBM Systems Director
    Le processus serveur CIM (sfcbd) sur l'hôte ESX peut envoyer des alertes OMC_IpmiAlertIndication non valides associées à l'absence de CPU au logiciel IBM Systems Director. Cette erreur se produit dans les serveurs lames tels que IBM LS22 7901-AC1.

    Ce problème est résolu dans cette version.
  • vCenter Server affiche uniquement un élément de configuration ProviderEnabled pour tous les VIB OEM installés
    Après l'installation des VIB des fournisseurs OEM, vCenter Server affiche uniquement l'élément de configuration ProviderEnabled /UserVars/CIMoemProviderEnabledpour tous les VIB des fournisseurs OEM que vous avez installés.

    Ce problème est résolu dans cette version. Désormais, si vous installez des VIB de fournisseurs OEM, les éléments de configuration /UserVars/CIMoem-<originalname>ProviderEnabled sont créés pour chaque VIB. Vous pouvez activer/désactiver chaque fournisseur séparément.

Système d'exploitation client

  • vMotion échoue par intermittence avec un message de dépassement de délai d'attente


    • error -1: Failed to launch virtual machine process. Failed to launch peer process.

Divers

  • Connexion impossible à l'hôte ESX 4.1 en utilisant les informations d'identification d'utilisateur non local
    Cette erreur est générée par les modifications apportées au fichier /etc/security/access.confdans ESX 4.1. L'entrée -:ALL:ALLdans le fichier access.confdans ESX 4.1 provoque l'échec de NIS ou de l'authentification de l'utilisateur non local.

    Ce problème est résolu dans cette version en ajoutant un nouveau paramètre plugins.vimsvc.shellAccessForAllUsersà vSphere Client. Maintenant, vous pouvez activer l'authentification d'utilisateur non local en affectant à plugins.vimsvc.shellAccessForAllUsersla valeur trueet en vous reconnectant à vCenter Server.
  • Déséquilibre NUMA après une opération vMotion des machines virtuelles (KB 2000740)
  • Si le nombre de cœurs CPU par socket dans une machine physique augmente, l'hôte ESXi nécessite plus de temps pour exécuter certaines tâches
    • Démarrage de la machine hôte
    • Ajout d'un hôte à un cluster HA
    • Collecte des données de diagnostic vm-support


  • Lorsque vous réinitialisez une machine virtuelle Windows 2003 Service Pack 2 R2 en utilisant vSphere 4.1, la machine virtuelle échoue avec un écran bleu

    • Redémarrer le client
  • Les longs messages syslog sont tronqués sur les hôtes ESXi
    Sur les hôtes ESXi, les messages de journal plus longs de 2 048 octets environ peuvent ne pas être écrits dans /var/log/messages.

    Ce problème est résolu dans cette version.
  • Le navigateur de banque de données ne peut pas gérer les liens symboliques dans les volumes NFS lorsqu'il est connecté à l'hôte ESX depuis vCenter 4.1 ou vSphere 4.1


  • Les messages dans les fichiers vpxalogsont répartis sur plusieurs lignes

    • vpxa
  • vSphere Client n'affiche pas de message d'alerte si Syslog n'est pas configuré



    • Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
  • Lorsqu'un contrôleur prend le contrôle d'un autre contrôleur, les banques de données qui se trouvent dans les LUN du contrôleur contrôlé peuvent devenir inactives


  • Dans ESXi 4.1, le processus hostd peut échouer fréquemment
    Les objets partagés entre le filtre de tâche et d'internationalisation provoquent l'échec fréquent du processus hostd.

    Ce problème est résolu dans cette version. Le correctif dans ESX 4.1 Update 2 clone l'objet au lieu de le partager.
  • La modification des snapshots à l'aide de la commande vim-cmd échoue dans certaines structures arborescentes de snapshots
    La modification des snapshots en utilisant la commande vim-cmd vmsvc/snapshot.removeou vim-cmd vmsvc/snapshot.revert
    échoue lorsqu'elle est appliquée à certaines structures arborescentes de snapshots.

    Ce problème est résolu dans cette version. Désormais, un identificateur unique, snapshotId, est créé pour chaque snapshot associé à une machine virtuelle. Vous pouvez obtenir l'identificateur snapshotId en exécutant la commande vim-cmd vmsvc/snapshot.get <vmid>. Vous pouvez utiliser la nouvelle syntaxe suivante avec les mêmes commandes :

    Retour au snapshot : vim-cmd vmsvc/snapshot.revert <vmid> <snapshotId> [suppressPowerOff/suppressPowerOn]
    Suppression d'un snapshot : vim-cmd vmsvc/snapshot.remove <vmid> <snapshotId>
  • Lorsque vous activez le mode de support technique distant (SSH) ou le mode de support technique local, un message d'avertissement similaire au message suivant s'affiche dans vCenter Server :

    Configuration Issues
    The Local Tech Support Mode for the host localhost.localdomain has been enabled.
    Remote Tech Support Mode(SSH) for the host <server> has been enabled

    Ce problème est résolu dans cette version. Désormais, vous pouvez désactiver cet avertissement en définissant le paramètre UserVars.SuppressShellWarning dans vCenter Server.
  • La machine virtuelle configurée avec le périphérique de relais fixe ne se met pas sous tension
    Une machine virtuelle configurée avec au moins 14 périphériques PCIe peut ne pas être mise sous tension si l'une d'entre elles correspond à un périphérique de relais fixe (FPT). Parfois, la machine virtuelle démarre une fois, mais ne se met plus sous tension par la suite. Un message d'erreur similaire au message suivant est consigné dans vmware.log:

    Mar 25 20:56:17.659: vcpu-0| Msg_Post: Error
    Mar 25 20:56:17.659: vcpu-0| [msg.pciPassthru.mmioOutsidePCIHole] PCIPassthru 005:00.0: Guest tried to map 32 device pages (with base address of 0x0) to a range occupied by main memory. This is outside of the PCI Hole. Add pciHole.start = "0" to the configuration file and then power on the VM.

    Ce problème est résolu dans cette version.

Mise en réseau

  • Lorsque vous supprimez vNetwork Distributed Switch, l'hôte ESX affiche un message d'erreur


    • Call "HostNetworkSystem.UpdateNetworkConfig" for object "networkSystem-3739" on vCenter Server "loganvc29.eng.vmware.com" failed.
    Operation failed, diagnostics report: DVS DvsPortset-0 has 1 shadow or zombie port.
  • Le premier paquet qu'envoie la vNIC e1000 a une adresse MAC non valide

    • 00:00:00:xx:xx:xx.
  • L'hôte ESXi configuré avec vNetwork Distributed Switch (vDS) se déconnecte de vCenter Server et ne se reconnecte pas, même après plusieurs tentatives

    • dépassement de limite
  • La connectivité réseau peut échouer lorsque des VLAN sont configurés avec des cartes NIC physiques utilisant le pilote be2net ou ixgbe
    Dans vNetwork Distributed Switch, lorsque vous configurez un seul VLAN ou une plage d'ID VLAN pour des groupes de ports dvUplink, la connectivité réseau peut échouer pour le VLAN unique ou le VLAN affecté à l'ID VLAN le plus élevé de la plage d'ID VLAN si vous avez installé le pilote be2net ou ixgbe pour une carte NIC physique.

    Ce problème est résolu dans cette version.

Sécurité

  • Résout un dépassement d'entier dans SFCB

    Cette version résout un problème de dépassement d'entier dans SFCB, qui se produit lorsque la valeur par défaut de httpMaxContentLength est remplacée par 0 dans /etc/sfcb/sfcb.cfg. Ce problème peut permettre à des pirates de générer des dénis de service (endommagement de la mémoire de tas) ou d'exécuter du code arbitraire via un grand entier dans l'en-tête HTTP Content-Length.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ce problème CVE-2010-2054.
  • Met à jour le RMP pam

    Dans cette version, le RMP pam est mis à niveau vers ppam_0.99.6.2-3.27.5437.vmw qui résout plusieurs problème de sécurité avec les modules PAM.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a affecté les noms CVE-2010-3316, CVE-2010-3435 et CVE-2010-3853 à ces problèmes.
  • Échec de la migration à froid entre les hôtes ESX 4.1 qui se trouvent dans deux clusters différents


  • Met à jour les packages openssl
     
    Résumé du bogue : Dans cette version, les packages openssl sont mis à niveau de openssl098e vers openssl-0.9.8e.12.el5_5.7, ce qui résout deux problèmes de sécurité. Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ces problèmes CVE-2008-7270 et CVE-2010-4180.
  • Met à jour les bibliothèques NSS et NSPR
     
    Dans cette version, le texte de licence dans les fichiers source des bibliothèques Network Security Services (NSS) et Netscape Portable Runtime (NSPR) est mis à jour pour distribuer ces packages selon les conditions LGPL (Lesser General Public License) 2.1 et non pas MPL (Mozilla Public License). En outre, NSS et NSPR sont à jour avec nspr-4.8.6-1 et nss-3.12.8-4 pour résoudre plusieurs problèmes de sécurité.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ces problèmes CVE-2010-3170 et CVE-2010-3173.
  • Met à jour le RPM libuser
      
    Dans cette version, le RPM libuser est mis à jour avec la version 0.54.7-2.1.el5_5.2 pour résoudre un problème de sécurité. Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ce problème CVE-2011-0002.
  • Met à jour les RMP openldap et openldap-client
     
    Dans cette version, les RPM openldap et openldap-client sont mis à jour avec 2.3.43.12.el5_5.1 et 2.3.43-12.el5_6.7, ce qui résout plusieurs problèmes de sécurité avec les bibliothèques OpenLDAP.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ces problèmes CVE-2010-0211, CVE-2010-0212 et CVE-2011-1024.
  • Met à jour userworld glibc

    Résumé du bogue : Dans cette version, userworld glibc est mis à jour avec 2.5-58.el5_6.2 pour résoudre des problèmes de sécurité.
     
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ces problèmes CVE-2011-0536, CVE-2010-0296, CVE-2011-1071 et CVE-2011-1095.
  • Met à jour le pilote mpt2sas

    Dans cette version, le pilote mpt2sas est mis à jour pour résoudre des problèmes de sécurité qui permettent l'escalade des privilèges d'utilisateur local.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a affecté les noms CVE-2011-1494 et CVE-2011-1495 à ces problèmes.
  • Met à jour les pilotes Intel e1000 et e1000e

    La mise à jour résout un problème de sécurité dans les pilotes e1000 et e1000e Linux des cartes Intel PRO/1000 pour empêcher un pirate distant de contourner les filtres de paquet et d'envoyer des paquets manipulés.

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ce problème CVE-2009-4536.

Configuration des serveurs

  • Les opérations Syslog peuvent échouer lorsque l'hôte est inaccessible

    • syslogd
    syslogd
  • Dans ESXi, les modifications apportées au fichier /etc/pam.d/system-authpour modifier les paramètres ne persistent pas au cours des redémarrages du système.
    Les utilisateurs ne peuvent pas modifier le fichier /etc/pam.d/system-auth. Par conséquent les modifications apportées au fichier /etc/pam.d/system-authne persistent pas au cours des redémarrages du système. Maintenant, vous pouvez modifier les paramètres de mot de passe en modifiant le fichier /etc/pam.d/passwd.

    Ce problème est résolu dans cette version.

Stockage

  • Le basculement avec l'adaptateur HBA (host bus adapter) FalconStor génère l'état APD (All Paths Down) lors de l'utilisation des adaptateurs HBA QLogic QME2472 avec ESX 4.0


  • L'hôte ESX/ESXi ne détecte pas les fonctions iSCSI de l'adaptateur NC382i après une mise à niveau


  • Lorsque vous redémarrez un commutateur Fibre Channel dans l'hôte ESX/ESXi, l'état de la liaison du commutateur n'est pas restauré


  • Les informations cible pour les numéros d'unité logiques (LUN) Fiber Channel d'un module 3par connecté à l'hôte ESX ne s'affichent pas dans vSphere


  • Dans ESX/ESXi, les machines virtuelles ne peuvent pas détecter les fichiers de mappage de périphérique brut qui résident dans la baie de stockage Dell MD36xxi


    • KB 1037925
  • Les snapshots des volumes VMFS mis à niveau ne se montent pas sur les hôtes ESX 4.x
    Les snapshots des volumes VMFS3 mis à niveau depuis VMFS2 avec une taille de bloc supérieure à 1 Mo peuvent ne pas se monter sur les hôtes ESX 4.x. La commande esxcfg-volume -ld'énumération des volumes de snapshots VMFS détectés échouent avec le message d'erreur suivant :

    ~ # esxcfg-volume -l
    Error: No filesystem on the device

    Ce problème est résolu dans cette version. Désormais, vous pouvez monter ou résigner les snapshots des volumes VMFS3 mis à jour depuis VMFS2.
  • Les hôtes ESX avec le pilote intégré QLogic Fibre Channel échouent avec un écran de diagnostic violet lors de la recherche des LUN


  • Le paramètre d'utilisation de chemins non optimisés actifs (useANO) des périphériques ne persiste pas au cours des redémarrages du système


  • ESXi 4.1 consigne en continu des messages d'erreur internes SATA sur un système Dell PowerEdge


    • cpu2:4802)<6>ata1:soft resetting port
    cpu1:4802)<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
    cpu0:4802)<6>ata1.00: configured for UDMA/100
    cpu0:4802)<6>ata1: EH complete
    cpu0:4802)<3>ata1.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
    cpu0:4802)<3>ata1.00: (irq_stat 0x40000001)
    cpu0:4802)<3>ata1.00: tag 0 cmd 0xa0 Emask 0x40 stat 0x51 err 0x24 (internal error)

  • L'hôte ESX connecté à une unité de bande qui fait l'objet d'un accès en utilisant le pilote aic79xx échoue
    Un hôte ESX connecté à une unité de bande qui fait l'objet d'un accès en utilisant le pilote aic79xxAn peut échouer avec un écran d'erreur violet et afficher un message d'erreur similaire au message suivant lorsque le pilote tente d'accéder à une zone de mémoire libérée :

    Loop 1 frame=0x4100c059f950 ip=0x418030a936d9 cr2=0x0 cr3=0x400b9000

    Ce problème est résolu dans cette version.
  • L'état de chemin des numéros des unités logiques (LUN) connectées à l'hôte ESX/ESXi n'est pas mis à jour, même après les avoir reconnectées à l'hôte ESX/ESXi


Matériel pris en charge

  • Le périphérique USB MAI KEYLOK II connecté à un hôte n'est pas accessible sur les machines virtuelles Linux


Mise à niveau et installation

  • Au cours d'une installation d'ESX 4.1 Update1 ou des versions précédentes, vous ne pouvez pas changer la taille de bloc ni la taille de volume VMFS
    Lorsque vous installez ESX/ ESXi 4.1 Update1 ou des versions précédentes avec l'installation avancée, vous ne pouvez pas modifier la taille de partition ni la taille de bloc VMFS. Par défaut, le volume VMFS est créé pour la partition entière.
    Désormais, ESX/ESXi permet de définir la taille de bloc vmfs au cours de l'installation IU, texte et kickstart, ce qui résout le problème.

    Ce problème est résolu dans cette version.
  • Lorsque vous mettez à niveau ESX de la version 3.5 vers 4.1, l'utilisation CPU augmente dans la machine virtuelle NetWare 5.1 Service Pack 8


  • L'installation ESX 4.1 échoue sur un serveur lame Hitachi BS320 AC51A3 avec le contrôleur LSI SAS Mezzanine (LSI 1064E)
    Le problème est provoqué par une fonction expérimentale, une analyse de bus série FireWire, introduite dans ESX 4.1. Voir https://www.vmware.com/fr/support/policies/experimental.html pour la position officielle de VMware sur les fonctions expérimentales dans nos produits.

    Pour résoudre le problème dans cette version, désactivez FireWire. FireWire n'est pas officiellement compatible avec ESX 4.1 et les versions suivantes.

  • Un message d'avertissement s'affiche lors de l'installation d'ESXi 4.1 U2 à l'aide d'un script si vous définissez la commande --fstype dans le fichier kickstart
    Dans les versions antérieures d'ESXi 4.1, la commande --fstypeétait facultative pour l'installation ESXi à l'aide d'un script et vous pouviez affecter uniquement la valeur vmfs3. Depuis cette version, la commande --fstypeest supprimée de l'installation à l'aide d'un script. Désormais, un message de ce type s'affiche si vous définissez la commande --fstypedans le fichier kickstart au cours de l'installation à l'aide d'un script :
     
    warning:nfs:<host name>/ks.cfg:line xxx: argument "--fstype" to command "part" does not take a value
     
    Toutefois, l'installation aboutit.

Gestion des machines virtuelles

  • Dans ESX 3.5/4.0, lorsque vous naviguez sur l'hôte ESX via le navigateur MOB (Managed Object Browser), la valeur de réservation de CPU et la valeur de réservation de mémoire sont signalées comme étant indéfinies

    • [virtualMachineConfigSummary.cpuReservation]
    [virtualMachineConfigSummary.memoryReservation]

  • La personnalisation d'un clonage à chaud de machine virtuelle exécutant le système d'exploitation client Windows 2008 R2 échoue et le clone redémarre en boucle La personnalisation du clonage à chaud d'un système d'exploitation client Windows 2008 R2 échoue avec le message d'erreur "auto check not found"et la machine virtuelle redémarre en boucle.

    Ce problème est résolu dans cette version.
  • Dans vCenter, une machine virtuelle Windows 2000 Professionnel clonée affiche Windows 2000 comme système d'exploitation client dans le fichier vmxau lieu de Windows 2000 Professionnel




  • Dans ESX/ESXi 4.0, la propriété de statistique de performance maxSample dans PerfQuerySpec affiche une valeur erronée

    • PerfQuerySpec
  • vSphere Client affiche un espace provisionné incorrect pour une machine virtuelle hors tension


  • La suppression d'un snapshot provoque l'échec de l'agent de gestion VMware hostd
    Si vous supprimez un snapshot de machine virtuelle, l'agent de gestion VMware hostd peut échouer et afficher un suivi arrière de type :

    [2010-02-23 09:26:36.463 F6525B90 error 'App']
    Exception: Assert Failed: "_config != __null && _view != __null" @ bora/vim/hostd/vmsvc/vmSnapshot.cpp:1494

    Ce problème provient du fait que le fichier <vm_name>-aux.xmlsitué dans le même répertoire que le fichier de configuration de la machine virtuelle est vide. Lors de la création ou de l'enregistrement d'une machine virtuelle sur hôte, le contenu du fichier <vm_name>-aux.xmlest lu et l'objet _viewest rempli. Si le fichier XML est vide, l'objet _viewn'est pas rempli. Cette situation génère une erreur lors de la consolidation du snapshot.

    Ce problème est résolu dans cette version.
  • L'hôte ESX ne répond plus lorsque les requêtes SNMP sont envoyées en utilisant un fichier MIB
    Un hôte peut ne plus répondre si vous activez l'agent SNMP intégré sur l'hôte et envoyez des requêtes SNMP en utilisant le fichier MIB VMWARE-VMINFO-MIB.mibà des machines virtuelles en cours de migration, de clonage, de création ou de suppression.

    Ce problème est résolu dans cette version.
  • Une machine virtuelle exécutée dans des snapshots peut ne plus répondre si la valeur de limite IOPS du disque virtuel est modifiée
    Si vous remplacez la valeur de limite IOPS Unlimited d'un disque virtuel par une autre valeur dans une machine virtuelle exécutée avec un ou des snapshots ou qui crée un snapshot, la machine virtuelle peut ne pas répondre par intermittence pendant quelques secondes.

    Ce problème est résolu dans cette version.

vMotion et Storage vMotion

  • Lorsque vous exécutez vMotion sur plusieurs machines virtuelles, l'hôte ESX affiche des messages d'avertissement de manque de mémoire


    • WARNING: vmklinux26: AllocPages: gfp_mask=0xd4, order=0x0, vmk_PktSlabAllocPage returned 'Out of memory' in the vmkernel log during vMotion
  • Si vous tentez de placer HA (High Availability) et DRS (Distributed Resource Scheduler) en mode de maintenance ou d'exécuter une opération vMotion, vMotion échoue avec le message d'erreur Out of Memory.
    Lorsque vous exécutez simultanément des opérations vmotions ou placez un hôte 4.1 en mode de maintenance, qui fait partie d'un cluster DRS utilisant vCenter 4.1 ou vSphere 4.1, l'évacuation des machines virtuelles échoue avec les messages d'erreur suivants :

    Migration to host <> failed with error Out of memory (195887124). vMotion migration [184468762:1286284186972455] write function failed.

    Ce problème est résolu dans cette version.
  • Échec de vMotion du fait d'un fichier d'échange verrouillé


VMware Tools

  • L'installation de VMware Tools sur une machine virtuelle avec le système d'exploitation Windows NT 4.0 génère un message d'erreur
    La tentative d'installer VMware sur une machine virtuelle avec le système d'exploitation Windows NT 4.0 aboutit. Toutefois, vSphere Client affiche l'état VMware Tools: Out of date.
    Ce problème est résolu dans cette version.
  • La mise à niveau VMware Tool échoue, car des dossiers dans /tmpsont supprimés dans des systèmes d'exploitation client Linux
    Lorsque vous mettez à niveau VMware Tools d'ESX 3.5 vers ESX 4.0, la mise à niveau peut échouer, car des distributions Linux suppriment régulièrement les anciens fichiers et dossiers dans /tmp. La mise à niveau VMware Tools nécessite ce répertoire dans /tmppour les mises à niveau automatiques.
    Ce problème est résolu dans cette version.
  • La machine virtuelle Windows perd la connectivité réseau après la mise à niveau VMware Tools
    Lorsque vous mettez à niveau VMware Tools, ayant le pilote HGFS (Host Guest File System ) installé, d'ESX 3.5 vers ESX 4.x, le pilote HGFS peut ne pas être installé correctement. Par conséquent, l'onglet d'ordre de fournisseur de réseau de la machine virtuelle Windows sous Connexions réseau > Avancé > Paramètres avancés affiche des informations incorrectes et la machine virtuelle peut perdre la connectivité réseau.

    Ce problème est résolu dans cette version. Désormais, la version antérieure du pilote HGFS et toutes les entrées de registre associées sont désinstallées correctement au cours de la mise à niveau.
  • Lorsque vous prenez un snapshot mis au repos d'une machine virtuelle Windows 2008 R2, le disque supplémentaire dans la machine virtuelle échoue
    • Windows 2003
    • Windows Vista
    • Windows 2008
    • Windows 7


  • Le fournisseur HGFS Windows provoque un blocage si une application appelle simultanément l'API WNetAddConnection2depuis plusieurs unités d'exécution

    • WNetAddConnection2WNetCancelConnection
  • Impossible d'utiliser la carte NIC (network interface card) VMXNET après l'installation de VMware Tools dans RHEL3 avec le dernier noyau dans ESX 4.1 U1

    • vmxnetvsocket
    Solution
  • Les systèmes d'exploitation clients Windows affichent un état de carte NIC incorrect après une mise à niveau de matériel virtuel


    • “This hardware device is not connected to the computer (Code 45)”
    Solution

  • Installation de VMware Tools sur une machine virtuelle RHEL 2.1 échoue avec un message d'erreur

    • vmware-install.pl
    Creating a new initrd boot image for the kernel. Error opening /tmp/vmware-fonts2/system_fonts.conf Execution aborted.
  • Des erreurs étranges s'affichent lors du redémarrage des machines virtuelles Linux après l'installation de VMware Tools
    Après avoir installé VMware Tools pour Linux, lorsque vous redémarrez le système d'exploitation client, le gestionnaire de périphériques du noyau Linux (udev) peut générer des erreurs étranges de ce type :

    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{model}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'SUBSYSTEMS'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'ATTRS{vendor}'
    May 4 16:06:11 rmavm401 udevd[23137]: add_to_rules: unknown key 'AT

    Ce problème est résolu dans cette version. Désormais, le programme d'installation de VMWare Tools pour Linux détecte le périphérique et écrit uniquement des règles spécifiques du système.
  • Les entrées de fichier de configuration sont remplacées sur les machines Linux lors de l'installation de VMware Tools
    Lorsque vous installez ou mettez à jour VMware Tools sur des machines virtuelles, le programme d'installation de VMware Tools peut remplacer les entrées dans les fichiers de configuration (telles que /etc/updated.conf pour Redhat et Ubuntu et /etc/sysconfig/locate pour SuSE) effectuées par des outils de développement tiers. Cela peut affecter les travaux cron exécutant updatedb sur ces machines virtuelles.

    Ce problème est résolu dans cette version.
  • Le service CUPS (Common UNIX Printing System) désactivé démarre automatiquement lorsque VMware Tools est installé ou mis à niveau sur une machine virtuelle SUSE Linux Enterprise Server 10 Service Pack 3, x86


  • Sur SUSE Linux Enterprise 10

    • chkconfig --level 2345 cups off
    chkconfig --level 2345 cupsrenice off


    service cups status
    chkconfig -l|grep -i cups

  • Sur Red Hat Enterprise Linux 5

    • chkconfig --level 2345 cups off
    system-config-services
  • Le socket VMCI (Virtual Machine Communication Interface) sur le système d'exploitation client Linux ne répond plus lorsqu'une paire de files d'attente est détachée.
    • La machine virtuelle est indisponible.
    • Un échec d'invalidation busmem est signalé par le système d'exploitation client.

    • En cours de connexion


    Connection reset by peer
  • Les modules de noyau de VMware Tools ne se chargent pas lors du changement de noyau
    Lorsque vous installez VMware Tools et changez de noyaux, les modules vsock et vmmemctl ne se chargent pas lors du démarrage. Le message d'erreur suivant apparaît lorsque vous exécutez une commande dmesg ou tentez de charger manuellement les modules du noyau incorrect :

    vmmemctl: disagrees about version of symbol module_layout
    vsock: disagrees about version of symbol module_layout

    Ce problème est résolu dans cette version. Le correctif dans ESX 4.1 Update 2 recrée les modules VMware Tools lors du changement des noyaux.
  • Le service VMware Tools (vmtoolsd) échoue sur les machines virtuelles 64 bits Windows lorsque l'allocation de mémoire virtuelle est forcée de haut en bas en utilisant une clé de registre



  • Le service VMware Tools (vmtoolsd) peut échouer après avoir installé VMware Tools sur un client Linux avec un nom de système d'exploitation long


  • La configuration X11 est modifiée après l'installation de VMware Tools

    Après avoir installé VMware Tools sur une machine virtuelle SuSe Linux Enterprise Server (SLES), la configuration X11 est modifiée. Par conséquent, le paramètre régional du clavier est remplacé par Albanian, la configuration de la souris et d'écran est vide et VNC échoue.

    Ce problème est résolu dans cette version.

 

Haut de la page

Problèmes identifiés

Cette section décrit les problèmes connus dans cette version dans les domaines suivants :

Les problèmes connus qui n'ont pas été documentés auparavant sont marqués du symbole *.

CIM et API

  • L'élément de configuration /UserVars/CIMoemProviderEnabled n'est pas supprimé lorsque vous effectuez une mise à niveau vers ESX 4.1 Update 2 *
    Solution : Supprimez /UserVars/CIMoemPrividerEnableden exécutant la commande suivante :

    esxcfg-advcfg-L /UserVars/CIMoemProviderEnabled

  • Les éléments de configuration OEM ProviderEnabled sont activés par défaut lorsque vous effectuez une mise à niveau vers ESX 4.1 Update 2 *
    Solution :
    1. Exécutez la commande suivante pour désactiver les fournisseurs OEM :
      esxcfg-advcfg -s 0 /UserVars/CIMoem-<originalname>ProviderEnabled
    2. Redémarrez le service sfcbden exécutant la commande :
        /etc/init.d/sfcbd-watchdog restart
  • La bibliothèque SFCC ne définit pas la méthode SetBIOSAttribute dans le fichier XML généré
    Lorsque la bibliothèque SFCC (Small Footprint CIM Client) tente d'exécuter la méthode     SetBIOSAttribute de la classe CIM_BIOSService par le biais de SFCC, un fichier XML contenant l'erreur suivante sera renvoyé par SFCC : CODE ERREUR="13" DESCRIPTION="La valeur fournie est incompatible avec le type" . Ce problème survient lorsque l'ancienne bibliothèque SFCC ne prend pas en charge le type de paramètre de la méthode de réglage dans le fichier XML généré. En raison de ce problème, vous ne pouvez pas appeler la méthode SetBIOSAttribute. La bibliothèque SFCC dans les hôtes ESXi 4.1 ne définit pas le type de paramètre de la méthode dans le fichier XML du flux socket qui est généré.

    Voici quelques suggestions de solutions :
    • IBM met à jour la version CIMOM
    • IBM corrige la version CIMOM avec ce correctif
    • IBM utilise sa propre version de la bibliothèque SFCC

Système d'exploitation client

  • Le système d'exploitation client peut ne pas répondre après l'ajout à chaud de plus de 3 Go de mémoire
    Le système d'exploitation client Redhat 5.4-64 peut ne pas répondre si vous démarrez avec un périphérique IDE attaché et exécutez une opération d'ajout à chaud pour faire passer la mémoire de moins de 3 Go à plus de 3 Go.

    Solution : N'utilisez pas l'ajout à chaud pour faire passer la taille de la mémoire de la machine virtuelle de 3 072 Mo ou moins à plus de 3 072 Mo. Mettez hors tension la machine virtuelle pour effectuer cette reconfiguration. Si le système d'exploitation client ne répond déjà plus, redémarrez la machine virtuelle. Ce problème ne se produit que lorsque le repère de 3 Go est franchi pendant que le système d'exploitation fonctionne.
  • Erreur d'installation du système d'exploitation client Windows NT avec les machines virtuelles disposant de la version matérielle 7
    Lorsque vous installez Windows NT 3.51 dans une machine virtuelle disposant de la version matérielle 7, le processus d'installation ne répond plus. Cela arrive immédiatement après l'écran de démarrage bleu avec l'apparition de la version Windows NT 3.51. Il s'agit d'un problème connu dans le kernel Windows NT 3.51. Les machines virtuelles avec la version matérielle 7 contiennent plus de 34 bus PCI et le noyau Windows NT prend en charge les hôtes qui ont une limite de 8 bus PCI.

    Solution : S'il s'agit d'une nouvelle installation, effacez la machine virtuelle existante et créez-en une nouvelle. Au cours de la création de la machine virtuelle, sélectionnez la version 4 du matériel. Vous devez utiliser l'assistant Nouvelle machine virtuelle afin de sélectionner un chemin d'accès personnalisé pour changer la version du matériel. Si vous avez créé la machine virtuelle avec la version matérielle 4, puis l'avez mise à niveau vers la version matérielle 7, utilisez VMware vCenter Converter pour rétrograder la machine virtuelle à la version matérielle 4.
  • L'installation de package VMware Tools OSP sur les systèmes d'exploitation client SLES 11 affiche un message indiquant que les packages ne sont pas pris en charge
    Lorsque vous installez des packages VMware Tools OSP sur le système d'exploitation client SUSE Linux Enterprise Server 11, un message d'erreur de ce type s'affiche :     Les packages suivants ne sont pas pris en charge par leur fournisseur .

    Solution : Ignorez ce message. Les packages OSP ne contiennent pas de balise signalant qu'ils sont supportés par le fournisseur. Cependant, ces packages sont supportés.
  • La compilation de modules pour le noyau VMware n'est prise en charge que pour le noyau en cours d'exécution
    VMware prend actuellement en charge la compilation des modules de noyau uniquement pour le noyau en cours d'exécution.

    Solution : Démarrez le noyau avant de compiler les modules pour ce noyau.

  • Aucune connectivité réseau après le déploiement et la mise sous tension d'une machine virtuelle
    Si vous déployez une machine virtuelle créée en utilisant l'assistant de personnalisation sur un hôte ESXi et mettez sous tension la machine virtuelle, cette dernière peut perdre la connectivité réseau.

    Solution :    Après avoir déployé chaque machine virtuelle sur l'hôte ESXi, sélectionnez l'option Connecter à la mise sous tension dans la fenêtre Propriétés de la machine virtuelle avant de mettre sous tension la machine virtuelle.

Divers

  • L'exécution de resxtop ou esxtop pendant de longues périodes peut entraîner des problèmes de mémoire.
    L'utilisation de la mémoire par     resxtop ou esxtop peut augmenter dans le temps en fonction de ce qui se passe sur l'hôte ESXi contrôlé. Cela implique que si un délai par défaut de 5 secondes entre deux affichages est utilisé, resxtop ou esxtop devrait s'arrêter après environ 14 heures.

    Solution : Bien que vous puissiez utiliser l'option -npour changer le nombre total d'itérations, il est préférable d'exécuter resxtopseulement si vous avez besoin des données. Si vous avez à recueillir des statistiques resxtopou esxtopsur une longue période, arrêtez et redémarrez resxtopou esxtoppériodiquement au lieu d'exécuter une instance resxtopou esxtoppendant des semaines ou des mois.
  • Longueur de l'ID de groupe dans vSphere Client plus courte que la longueur de l'ID de groupe dans vCLI
    Si vous spécifiez un ID de groupe en utilisant vSphere Client, vous ne pouvez utiliser que neuf caractères. Cela étant, vous pouvez spécifier jusqu'à dix caractères si vous spécifiez l'ID de groupe en utilisant le vCLI     vicfg-user .

    Solution : Aucune

  • Un message d'avertissement s'affiche lorsque vous exécutez la commande esxcfg-pciid
    Lorsque vous essayez d'exécuter la commande esxcfg-pciidpour lister les contrôleurs et les adaptateurs Ethernet, un message d'avertissement de ce type peut s'afficher :
    Nom court de fournisseur AMD Inc ne correspond pas au nom de fournisseur existant Advanced Micro Devices [AMD]
    mappage pilote noyau pour id périphérique 1022:7401 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
    mappage pilote noyau pour id périphérique 1022:7409 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
    mappage pilote noyau pour id périphérique 1022:7411 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
    mappage pilote noyau pour id périphérique 1022:7441 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu

    Ce problème survient lorsque les fichiers périphériques-descripteurs de plateforme et les fichiers du descripteur pilote spécifiques contiennent des descriptions pour le même périphérique.

    Solution : Vous pouvez ignorer ce message d'avertissement.
  • Échec de l'ajout de l'hôte d'ESXi 4.1 Update 1 Embedded dans Cisco Nexus 1000V version 4.0 (4) SV1 (3a)
    Vous pourriez ne pas être en mesure d'ajouter l'hôte d'ESXi 4.1 Update 1 Embedded à une version 4.0(4) SV1(3a) de Cisco Nexus 1000V par vCenter Server.

    Solution
    Pour ajouter un hôte ESXi 4.1 Update 1 Embedded dans Cisco Nexus 1000V version 4.0(4) SV1(3a), utilisez l'utilitaire vihostupdatepour appliquer le bundle VEM sur les hôtes ESXi.
    Effectuez les étapes suivantes pour ajouter un hôte ESXi 4.1 Update 1 Embedded :
    1. Configurez Cisco Nexus 1000V version 4.0(4)SV1(3a).
    2. Configurez vCenter Server avec le plug-in VUM installé.
    3. Connectez Cisco Nexus 1000V version 4.0(4)SV1(3a) à vCenter Server.
    4. Créez un centre de données et ajoutez l'hôte ESXi 4.1 Update 1 Embedded à vCenter Server.
    5. Ajoutez ESXi 4.1 Update 1 compatible AV.2 VEM bits à un hôte ESXi en exécutant la commande suivante à partir de vSphere CLI :
      vihostupdate.pl --server <Server IP> -i -b <VEM offline metadata path>
      Les messages suivants seront affichés sur la console de service :
      Entrez le nom d'utilisateur :
      Entrez le mot de passe :
      Veuillez patientez, installation des correctifs en cours...
    6. Après la mise à jour des correctifs, naviguez sur Afficher mise en réseau dans vCenter Server et ajoutez l'hôte à Cisco Nexus 1000V version 4.0(4)SV1(3a).
    7. Vérifiez que l'hôte ESXi 4.1 Update 1 a été ajouté à Cisco Nexus 1000V version 4.0(4)SV1(3a).

Mise en réseau

  • La connectivité réseau et le système échouent lors de l'exécution des opérations de contrôle sur les cartes NIC physiques
    Dans certains cas, lorsque plusieurs cartes NIC X-Frame II s2io partagent le même bus PCI-X, les opérations de contrôle, telles que le changement de MTU, sur la carte NIC physique provoquent la perte de la connectivité réseau et l'échec du système.

    Solution : Évitez de placer plusieurs cartes NIC X-Frame II s2io dans des emplacements qui partagent le même bus PCI-X. Si une telle configuration est nécessaire, évitez d'effectuer des opérations de contrôle sur les cartes NIC physiques quand les machines virtuelles effectuent des E/S réseau.
  • Les performances TCP peuvent être dégradées sur les machines virtuelles acheminant le trafic avec LRO activé
    Certains modules Linux ne peuvent pas gérer les paquets générés par LRO. De ce fait, avoir LRO activé sur un périphérique VMXNET 2 ou VMXNET 3 sur une machine virtuelle acheminant le trafic sous système d'exploitation client Linux peut entraîner de mauvaises performances TCP. LRO est activé par défaut sur ces périphériques.

    Solution : Dans les machines virtuelles acheminant le trafic qui exécutent des systèmes d'exploitation client Linux, incluez le paramètre de délai de chargement disable_lro=1 de module du pilote Linux VMXNET2 ou VMWNET3.
  • Problèmes de mémoire lorsqu'un hôte utilise plus de 1 016 dvPorts sur un vDS
    Le nombre maximal de dvPorts par hôte sur vDS est de 4 096, mais des problèmes de mémoire peuvent survenir lorsque le nombre de dvPorts pour un hôte est proche de 1016. Dans ce cas, vous ne pouvez pas ajouter de machines virtuelles ni d'adaptateurs virtuels au vDS.

    Solution : Configurez un maximum de 1016 dvPorts par hôte sur un vDS.
  • La reconfiguration de VMXNET3 NIC peut réveiller la machine virtuelle
    La reconfiguration d'une carte NIC VMXNET3 alors que Wake-on-LAN est activé et que la machine virtuelle est en veille permet à la machine virtuelle de reprendre.

    Solution : Remettez manuellement la machine virtuelle en veille après la reconfiguration (par exemple, après avoir effectué un ajout à chaud ou une suppression à chaud) d'une VMXNET3 vNIC.

Stockage

  • Impossible de configurer iSCSI sur NIC avec des noms longs des périphériques logiques
    L'exécution de la commande     esxcli swiscsi nic add -n à partir d'une interface de ligne de commande vSphere (vCLI) ne configure pas l'opération iSCSI sur une carte NIC VMkernel dont le nom de périphérique logique contient plus de 8 caractères. Les pilotes tiers NIC qui utilisent des noms vmnic et vmknic contenant plus de 8 caractères ne peuvent pas fonctionner avec la fonction de liaison du port iSCSI dans les hôtes ESX et peuvent afficher des messages d'erreur d'exception dans l'interface de ligne de commande distante. Des commandes, telles que esxcli swiscsi nic list, esxcli swiscsi nic add, esxcli swiscsi vmnic list , à partir de l'interface vCLI échoueront parce qu'elles ne peuvent pas gérer les noms longs vmnic créés par les pilotes tiers.

    Solution : Le pilote tiers NIC doit restreindre ses noms vmnic à une taille inférieure ou égale à 8 octets pour respecter la condition de liaison du port iSCSI.
    Remarque : Si le pilote n'est pas utilisé pour la liaison du port iSCSI, le pilote peut encore utiliser des noms allant jusqu'à 32 octets. Cela fonctionnera également avec iSCSI sans la fonction de liaison du port iSCSI.

  • Grand nombre de messages relatifs au stockage dans le fichier journal VMkernel
    Lorsque ESX démarre sur un hôte avec plusieurs chemins d'accès physiques aux périphériques de stockage, le fichier journal VMkernel enregistre un grand nombre de messages relatifs au stockage de type :
    Nov 3 23:10:19 vmkernel: 0:00:00:44.917 cpu2:4347)Vob: ImplContextAddList:1222: Vob add (@&!*@*@(vob.scsi.scsipath.add)Add path: %s) failed: Dépassement de capacité du contexte VOB
    Le système peut consigner des messages similaires au cours des réanalyses du stockage. Ces messages sont normaux et n'indiquent pas de mauvais fonctionnement. Vous pouvez les ignorer en toute sécurité.

    Solution : Désactivez leur affichage si vous ne souhaitez plus les voir.
  • Les conflits permanents de réservation dans les LUN partagés peuvent allonger la durée du démarrage des hôtes ESXi*
    La durée du démarrage des hôtes partageant des LUN sur un réseau SAN peut augmenter sensiblement. Cette situation peut être provoquée par des conflits entre les réservations LUN SCSI.

    Solution : Pour résoudre ce problème et accélérer le démarrage, définissez 10 secondes comme délai d'attente pour les commandes synchrones au cours du démarrage en affectant la valeur 10000 au paramètre Scsi.CRTimeoutDuringBoot.

    Pour modifier le paramètre depuis le vSphere Client :
    1. Dans le panneau d'inventaire de vSphere Client, sélectionnez l'hôte, cliquez sur l'onglet Configuration, puis sur Paramètres avancés sous Software.
    2. Sélectionnez SCSI.
    3. Modifiez le paramètre Scsi.CRTimeoutDuringBootà 10 000.

Matériel pris en charge

  • ESXi peut ne pas démarrer lorsque l'option de démarrage allowInterleavedNUMANodes est FALSE
    Sur un hôte IBM eX5 avec une extension MAX 5, ESXi ne démarre pas et affiche un message     SysAbort sur la console de service. Ce problème peut survenir lorsque l'option de démarrage allowInterleavedNUMANodes n'est pas réglée sur VRAI. La valeur par défaut de cette option est FAUX.

    Solution : Réglez l'option de démarrage     allowInterleavedNUMANodes sur VRAI. Voir KB 1021454 sur le site http://kb.vmware.com/kb/1021454 pour plus d'informations sur la configuration de l'option de démarrage des hôtes ESXi.
  • Erreurs de mappage de périphérique PCI sur HP ProLiant DL370 G6
    Lorsque vous exécutez des opérations E/S sur le serveur HP ProLiant DL370 G6, un écran violet ou des alertes peuvent s'afficher pour l'interruption Lint1 ou NMI. Le serveur HP ProLiant DL370 G6 a deux hub E/S Intel (IOH) et un défaut du BIOS dans les définitions de structure ACPI Direct Memory Access Remapping (DMAR), entraînant une description de certains périphériques PCI sous la mauvaise unité de remappage DMA. Tout accès DMA par ces périphériques PCI incorrectement décrits provoque une erreur IOMMU et le périphérique reçoit une erreur d'E/S. Selon le périphérique, cette erreur d'E/S peut provoquer un message d'alerte NMI ou une interruption Lint1 ou erreur système avec un écran violet.

    Solution : Mettez à jour le BIOS vers la version 2010.05.21 ou une version ultérieure.
  • Les installations ESXi sur les systèmes HP nécessitent le pilote HP NMI
    Les instances ESXi 4.1 sur les systèmes HP nécessitent le pilote HP NMI pour assurer le bon fonctionnement des NMI. Le pilote NMI garantit que les NMI sont bien détectés et connectés. Sans ce pilote, les NMI signalant les erreurs matérielles sont ignorés par les systèmes HP exécutant ESXi.
    Attention : L'échec de l'installation de ce pilote risque de provoquer une corruption des données silencieuse.

    Solution : Téléchargez et installez le pilote NMI. Le pilote est disponible en tant que package hors-ligne sur le site Web HP. Voir également KB 1021609 sur http://kb.vmware.com/kb/1021609.
  • Les machines peuvent fonctionner en lecture seule lorsqu'elles sont exécutées sur une banque de données iSCSI déployée sur la solution de stockage EqualLogic
    Les machines virtuelles peuvent fonctionner en lecture seule si vous utilisez un module EqualLogic avec une ancienne version du microprogramme. Le microprogramme peut éventuellement supprimer l'E/S de la file d'attente et amener les machines virtuelles à fonctionner en lecture seule après l'échec de l'E/S.

    Solution : mettez à niveau le microprogramme du module EqualLogic vers la version 4.1.4 ou une version ultérieure.
  • Après la mise à niveau de la baie de stockage, l'état d'accélération matérielle dans vSphere Client passe à Pris en charge après un court délai
    Lorsque vous mettez à niveau le microprogramme d'une baie de stockage vers une version prenant en charge la fonctionnalité VAAI, vSphere 4.1 n'enregistre pas immédiatement le changement. Le vSphere Client affiche temporairement Inconnu comme état d'accélération matérielle.

    Solution : Ce délai est sans incidence. L'état d'accélération matérielle passe à Pris en charge après une courte période.
  • Ralentissement des performances au cours de la mise sous tension de la machine virtuelle ou des E/S disque sur ESXi sur la plateforme HP G6 avec P410i ou P410 Smart Array Controller
    Les performances de ces hôtes peuvent diminuer au cours de la mise sous tension de la machine virtuelle ou de la génération d'E/S de disque. Le symptôme principal est une dégradation des performances E/S qui génère un grand nombre de messages d'erreur de type /var/log/messages:
    Mar 25 17:39:25 vmkernel: 0:00:08:47 438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:25 vmkernel: 0:00:08:47.438 cpu1:4097)scsi_cmd_alloc returned NULL
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Command 0x28 (0x410005060600) to NMP device
    "naa.600508b1001030304643453441300100" a échoué sur le chemin d'accès physique "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Données de détection possibles : 0x
    Mar 25 17:39:26 0 0x0 0x0.
    Mar 25 17:39:26 vmkernel: 0:00:08:47 632 cpu1:4097)AVERTISSEMENT : NMP: nmp_DeviceRetryCommand: Périphérique
    "naa.600508b1001030304643453441300100": en attente de mise à jour rapide de l'état du chemin d'accès pour le basculement avec l'E/S bloqué. Aucune réservation antérieure
    n'existe sur le périphérique.
    Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Commande 0x28 (0x410005060700) au périphérique NMP
    a échoué "naa.600508b1001030304643453441300100" sur le chemin d'accès "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 données de détection possibles : 0x
    Mar 25 17:39:26 0 0x0 0x0

    Solution : Installez le module de Mise à niveau du cache de HP 256Mo P-series à partir de http://h30094.www3.hp.com/product.asp?mfg_partno=462968-B21&pagemode=ca&jumpid=in_r3924/kc.

Mise à niveau et installation

  • La mise à jour multichemin d'ESXi 3.5 vers ESXi 4.0.x vers ESXi 4.1 Update 2 en utilisant VMware vCenter Update Manager échoue *
    Après une mise à niveau d'ESXi 3.5 vers ESXi 4.0.x en utilisant VMware vCenter Update Manager, les tentatives de mise à niveau de l'installation ESX vers ESXi 4.1 Update 2 échouent avec un message d'erreur de type :

    VMware vCenter Update Manager a subi une défaillance inconnue. Check the Tasks and Events tab and log files for details

    La mise à niveau échoue pour les chemins de mise à niveau suivants :

    • ESXi 3.5 vers ESXi 4.0 Update 1 vers ESXi 4.1 Update 2
    • ESXi 3.5 vers ESXi 4.0 Update 2 vers ESXi 4.1 Update 2
    • ESXi 3.5 vers ESXi 4.0 Update 3 vers ESXi 4.1 Update 2
    • ESXi 3.5 vers ESXi 4.0 vers ESXi 4.1 Update 2

    Solution : Redémarrez l'hôte après la mise à niveau vers ESXi 4.0.x, puis effectuez la mise à niveau vers ESXi 4.1 Update 2.

  • La mise à niveau de l'hôte vers ESX/ESXi 4.1 Update 1 échoue si elle est effectuée avec Update Manager 4.1 (KB 1035436)

  • L'installation de vSphere Client peut échouer avec une erreur
    Lorsque vous installez vSphere Client, le programme d'installation peut tenter de mettre à niveau un environnement d'exécution obsolète de Microsoft Visual J #. La mise à niveau n'aboutit pas et l'installation vSphere Client échoue avec l'erreur : Le programme d'installation Microsoft Visual J# 2.0 Second Edition retourne le code d'erreur 4113.

    Solution : Désinstallez toutes les versions antérieures de Microsoft Visual J# et installez vSphere Client. Le programme d'installation contient un package Microsoft Visual J# mis à jour.
  • L'accès simultané à deux installations ESXi sur des lecteurs flash USB entraîne l'affichage par le système de messages de panique
    Si vous démarrez un système qui a accès à plusieurs installations ESXi avec le même numéro de version sur deux lecteurs flash USB, le système affiche des messages de panique.

    Solution : Détachez un des lecteurs flash USB et redémarrez le système.

vMotion et Storage vMotion

  • vMotion est désactivé après un redémarrage de l'hôte ESXi 4.1
    Si vous activez vMotion sur un hôte ESXi et redémarrez l'hôte ESXi, vMotion n'est plus activéune fois le processus de redémarrage terminé.

    Solution : Pour résoudre ce problème, réinstallez la dernière version de l'image ESXi fournie par votre fournisseur de systèmes.

  • Les opérations de connexion à chaud échouent après le déplacement du fichier d'échange
    Les opérations de connexion à chaud échouent pour les machines virtuelles sous tension dans un cluster ou sur un hôte autonome et génèrent l'erreur failed to resume destination; VM not foundaprès le déplacement du fichier d'échange.

    Solution : Exécutez l'une des tâches suivantes :
    • Redémarrez les machines virtuelles affectées pour y enregistrer le nouvel emplacement du fichier d'échange, puis effectuez les connexions à chaud.
    • Déplacez les machines virtuelles affectées en utilisant vMotion.
    • Interrompez les machines virtuelles affectées.

VMware Tools

  • PR 632995 : Impossible d'utiliser la carte d'interface réseau VMXNET après l'installation de VMware Tools in RHEL3 avec le dernier kernel corrigé sur ESXi 4.1 U1 *
    Certains pilotes dans les modules VMware Tools prédéfinis avec RHEL 3.9 ne fonctionnent pas correctement avec le noyau 2.4.21-63 du fait de l'incompatibilité ABI. Par conséquent, certains pilotes, tels que vmxnet et vsocket, ne se chargent pas lorsque vous installez sur VMware Tools sur REHL3.9.

    Solution : Solution Démarrez dans le noyau 2.4.21-63. Installez la source et le package gcc du noyau 2.4.21-63. Exécutez la commande vmware-config-tools.pl, --compile. Vous compilez ainsi les modules pour ce noyau ; les modules résultant devraient fonctionner avec le noyau actif.

  • VMware Tools n'exécute pas de mise à niveau automatique lorsqu'une machine virtuelle Microsoft Windows 2000 est redémarrée
    Lorsque vous configurez VMware Tools pour la mise à niveau au cours d'un cycle d'alimentation en sélectionnant l'option de vérification et de mise à niveau des outils avant chaque option de mise sous tension dans le volet Avancé dans la fenêtre des propriétés des machines virtuelles, VMware Tools n'effectue pas de mise à niveau dans les systèmes d'exploitation client Microsoft Windows 2000.

    Solution :         Mettez à niveau manuellement VMware Tools dans le système d'exploitation client Microsoft Windows 2000.

 

 

Haut de la page