ESX 4.1 Update 3 | 30 août 2012 | Build 800380
VMware Tools | 30 août 2012 | Build 784891

Dernière mise à jour du document : 13 septembre 2012

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 ESX :

  • Prise en charge de systèmes d'exploitation clients supplémentaires Cette version met à jour la prise en charge de nombreux systèmes d'exploitation clients. Pour une liste complète des systèmes d'exploitation clients pris en charge par cette version, consultez le Guide de compatibilité VMware.
  • Problèmes résolus Cette version corrige également divers bogues documentés dans la section Problèmes résolus.

Haut de la page

Versions antérieures d'ESX 4.1

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

Haut de la page

Avant de commencer

Compatibilité de version ESX, vCenter Server et vSphere Client

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

Compatibilité ESX, vCenter Server et VDDK

Virtual Disk Development Kit (VDDK) 1.2.2 ajoute la prise en charge des versions ESX 4.1 Update 3 et vCenter Server 4.1 Update 3. Pour de plus amples informations sur VDDK, voir http://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 :

    Matrice d'intéropérabilité des produits VMware

Installation et mise à niveau

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

Après une installation réussie, vous devez effectuer plusieurs étapes de configuration, en particulier pour l'attribution de licences, la mise en réseau et la sécurité. Pour vous guider dans ces tâches de configuration, reportez-vous aux guides suivants de la documentation vSphere.

Si VirtualCenter 2.x est installé, reportez-vous au Guide de mise à niveau vSphere pour plus d'informations sur l'installation de vCenter Server sur un système d'exploitation 64 bits et la préservation de votre base de données VirtualCenter.

Les fichiers MIB (Management Information Base) relatifs à ESX 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/download.

Mise à niveau de VMware Tools

VMware ESX 4.1 Update 3 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 machine virtuelle. Reportez-vous aux Problèmes résolus de VMware Tools pour une liste des problèmes résolus dans cette version d'ESX 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 ESX 4.1 Update 3

ESX 4.1 Update 3 offre les options suivantes pour la mise à niveau :

  • VMware vCenter Update Manager . Module vSphere qui prend en charge les mises à niveau directes d'ESX 3.5 Update 5a et les versions ultérieures, ESX 4.0.x et ESX 4.1, ESX 4.1 Update 1 et ESX 4.1 Update 2 vers ESX 4.1 Update 3. Pour plus d'informations, voir le Guide d'administration VMware vCenter Update Manager.
  • vihostupdate . Utilitaire de ligne de commande qui prend en charge les mises à niveau directes d'ESX 4.0.x, ESX 4.1, ESX 4.1 Update 1 et ESX 4.1 Update 2 vers ESX 4.1 Update 3. Cet utilitaire nécessite vSphere CLI. Pour plus d'informations, voir le Guide de mise à niveau vSphere.
  • esxupdate . Utilitaire de ligne de commande qui prend en charge les mises à niveau d'ESX 4.0.x, ESX 4.1, ESX 4.1 Update 1 et ESX 4.1 Update 2 vers ESX 4.1 Update 3. Pour plus d'informations, voir le Guide de gestion des correctifs ESX 4.1.
  • script esxupgrade.sh . Script qui prend en charge les mises à niveau depuis les hôtes ESX 3.5 Update 5a et plus récentes. Pour plus d'informations, voir l' article 1009440 dans la base de connaissances et le Guide de mise à niveau vSphere.

Chemins de mise à niveau pris en charge pour la mise à niveau de l'hôte vers ESX 4.1 Update 3 :

Type de mise à niveau

Outils de mise à niveau pris en charge
Chemins de mise à niveau pris en charge vers ESX 4. 1 Update 3

ESX 3.5 Update 5a

ESX 4.0
Inclut
ESX 4.0 Update 1
ESX 4.0 Update 2
ESX 4.0 Update 3

ESX 4.0 Update 4

ESX 4.1 :
Inclut
ESX 4.1 Update 1

ESX 4.1 Update 2

ESX-4.1.0-update3-800380.iso
  • VMware vCenter Update Manager avec ligne de base de mise à niveau de l'hôte ESX
  • esxupgrade.sh

Oui

Non

Non

upgrade-from-esx4.0-to-4.1-update03-800380.zip
  • VMware vCenter Update Manager avec ligne de base de mise à niveau de l'hôte
  • esxupdate
  • vihostupdate
    Remarque: Installez d'abord le bundle de pré-mise à niveau ( pre-upgrade-from-esx4.0-to-4.1-update03-800380.zip) si vous utilisez l'utilitaire vihostupdateou esxupdatepour effectuer une mise à niveau.

Non

Oui

Non

update-from-esx4.1-4.1_update03.zip
  • VMware vCenter Update Manageravec ligne de base de correctifs
  • esxupdate
  • vihostupdate

Non

Non

Oui

ESX 4.1 vers 4.1.x à l'aide des définitions de correctifs téléchargées depuis le portail VMware (en ligne) VMware vCenter Update Manager avec ligne de base de correctifs

Non

Non

Oui

Remarques :

Mise à jour des RPM et correctifs de sécurité

Pour connaître la liste des RPM mis à jour dans ESX 4.1 Update 3, consultez la Mise à jour des RPM et correctifs de sécurité . Ce document ne s’applique pas aux produits ESXi.

Mise à niveau de vSphere Client

Après avoir mis à niveau vCenter Server ou l’hôte ESX/ESXi vers vSphere 4.1 Update 3, vous devez mettre à niveau vSphere Client vers vSphere Client 4.1 Update 3. Utilisez la mise à niveau de vSphere Client pour accéder à vSphere 4.1 Update 3.

Correctifs contenus dans cette version

Cette version contient tous les bulletins d'ESX 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.

La version corrective ESX410-Update03 contient les bulletins individuels suivants :

ESX410-201208201-UG: Mise à jour des composants ESX 4.1 Core et CIM
ESX410-201208202-UG : Mise à jour du pilote ESX 4.1 Megaraid SAS
ESX410-201208203-UG : Mise à jour du pilote ESX 4.1 scsi-hpsa
ESX410-201208204-UG: Mise à jour du pilote ESX 4.1 e1000e
ESX410-201208205-UG: Mise à jour du pilote ESX 4.1 usbcore
ESX410-201208206-UG: Mise à jour du pilote ESX 4.1 usb-storage
ESX410-201208207-UG: Mise à jour du package ESX 4.1 e2fsprogs

La version corrective ESX410-Update03 Security-only contient les bulletins individuels suivants :

ESX410-201208101-SG : Mise à jour des composants ESX 4.1 Core et CIM
ESX410-201208102-SG: Mise à jour du package ESX 4.1 libxml2-python
ESX410-201208103-SG : Mise à jour du composant ESX 4.1 openssl
ESX410-201208104-SG : Mise à jour du package ESX 4.1 glibc-nscd
ESX410-201208105-SG : Mise à jour des bibliothèques ESX 4.1 popt et rpm-python
ESX410-201208106-SG : Mise à jour du package ESX 4.1 gnutls
ESX410-201208107-SG : Mise à jour du package ESX 4.1 perl

Résolution des problèmes

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

CIM et API

  • L'actuelle limite maximale de 256 descripteurs de fichiers du fournisseur Emulex CIM est insuffisante
    Le fournisseur Emulex CIM dépasse l'allocation SFCB de 256 descripteurs de fichiers, causant ainsi l'épuisement des ressources du socket des hôtes ESX.

    Pour résoudre ce problème, augmentez la limite du socket et optimisez les paires de sockets pré-allouées.
  • Le journal des événements systèmes (SEL) ESX 4.1 Update 2 est vide sur certains serveurs
    Le journal des événements système de vSphere Client peut se révéler vide si l'on exécute ESX 4.1Update 2 sur certains serveurs physiques. Les journaux IPMI de l'hôte ( /var/log/ipmi/0/sel) peuvent également être vides.
    Un message d'erreur similaire au suivant peut être consigné dans /var/log/messages:
    Dec 8 10:36:09 esx-200 sfcb-vmware_raw[3965]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff

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

Système d'exploitation client

  • La machine virtuelle SMP échoue et une alerte du moniteur se déclenche lors de l'exécution de kexec
    Lorsqu'un noyau Linux se bloque, la fonction linux kexecpeut être utilisée pour activer un démarrage via un noyau spécial kdumpet favoriser la collecte des fichiers de vidage sur incident. Pendant ce type de redémarrage, un SMP client Linux configuré avec kexecpeut provoquer l'échec de la machine virtuelle et le déclenchement d'une alerte du moniteur. Il est possible de consigner des messages d'erreur tels que ceux listés ci-après :

    vcpu-0| CPU reset: soft (mode 2)
    vcpu-0| MONITOR PANIC: vcpu-0:VMM fault 14: src=MONITOR rip=0xfffffffffc28c30d regs=0xfffffffffc008b50


    Ce problème est résolu dans cette version.
  • Le système d'exploitation client d'une machine virtuelle signale une erreur de panique de noyau lorsque vous essayez d'installer Solaris 10 avec une taille de mémoire par défaut sur certaines versions d'ESX
    Quand vous essayez d'installer Solaris 10 sur ESX, le système d'exploitation client de la machine virtuelle signale une erreur de panique de noyau à l'aide du message suivant :
    panic[cpu0]/thread=fffffffffbc28340 ..page_unlock:...

    Ce problème est résolu dans cette version par l'augmentation de la taille de mémoire par défaut à 3 Go.

Divers

  • ESX échoue lorsque les commandes SCSI ne retournent pas les valeurs à la console de service
    Lorsque les commandes SCSI exécutées ne retournent pas les valeurs à la console de service, cette dernière affiche le message d'erreur suivant et ESX échoue :
    COS Panic: Lost heartbeat @ esxsc_panic+0x43/0x4f error message

    Ce problème est résolu dans cette version.
  • Sur ESX, la valeur du délai d'attente de connexion de l'initiateur iSCSI allouée au logiciel iSCSI et aux adaptateurs dépendants iSCSI est insuffisante.
    En cas de tentatives de connexions multiples et simultanées sur un hôte ESX, la connexion échoue en raison de la valeur insuffisante du délai d'attente de connexion.

    Pour résoudre ce problème, il convient de donner la possibilité aux utilisateurs de configurer la valeur du délai d'attente de connexion.
  • Sur les systèmes de fichiers visorfs, l'hôte ESX ne capture pas la sortie vdf de l'utilitaire vm-support
    L'option de capture de la sortie vdfn'est pas disponible dans ESX. Sans cette option, l'utilisateur peut éventuellement ne pas être informé de l'utilisation de l'espace Ramdisk.

    L'inclusion de la commande vdf –hdans vm-supportpermet de résoudre ce problème.
  • L'hôte ESX ne répond plus en raison d'un débordement du journal USB des périphériques IBM
    Il est possible qu'un hôte ESX ne réponde plus en raison d'un débordement constant de messages du journal USB similaires aux suivants pour les périphériques non-relais tels queRSA2 ou RNDIS/CDC Ether. Ce problème se produit même si aucune machine virtuelle n'est configurée pour utiliser l'option relais US.

    USB messages: usb X-Y: usbdev_release : USB passthrough device opened for write but not in use: 0, 1

    Ce problème est résolu dans cette version.
  • La suppression à chaud d'un disque SCSI échoue avec une erreur
    Après avoir ajouté à chaud un disque SCSI, la suppression à chaud de ce même disque peut échouer avec le message d'erreur disk not present. Des messages d'erreur similaires aux messages suivants sont consignés dans le fichier journal vmx:

    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve shares: A one-of constraint has been violated (-19)
    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve sched/limit/: A one-of constraint has been violated (-19)
    2010-06-22T19:40:26.214Z| vmx| scsi2:11: Cannot retrieve sched/bandwidthCap/: A one-of constraint has been violated (-19)
    2010-06-22T19:40:33.285Z| vmx| [msg.disk.hotremove.doesntexist] scsi2:11 is not present.
    2010-06-22T19:40:33.285Z| vmx| [msg.disk.hotremove.Failed] Failed to remove scsi2:11.


    Ce problème est résolu dans cette version.
  • Impossible de joindre l'hôte ESX à Active Directory lorsque le suffixe de domaine DNS est différent du nom de domaine Active Directory

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

Mise en réseau

  • Les limites de réseau d'une machine virtuelle ne fonctionnent pas correctement lorsque la limite est réglée sur une valeur supérieure à 2048 Mbps
    Sur un hôte ESX, si vous configurez Network I/O Control (NetIOC) pour régler la Limite d'hôte du Trafic de machine virtuelle sur une valeur supérieure à 2048 Mbps, la limite de bande passante n'est pas appliquée.

    Ce problème est résolu dans cette version.
  • L'hôte ESX échoue avec un écran violet après l'échec d'une opération vMotion
    Un hôte ESX peut échouer avec un écran de diagnostic violet affichant une erreur de type Exception 14après l'échec d'une opération vMotion.

    @BlueScreen: #PF Exception 14 in world 4362:vemdpa IP 0x418006cf1edc addr 0x588
    3:06:49:28.968 cpu8:4362)Code start: 0x418006c00000 VMK uptime: 3:06:49:28.968
    3:06:49:28.969 cpu8:4362)0x417f80857ac8:[0x418006cf1edc]Port_BlockNotify@vmkernel:nover+0xf stack: 0x4100afa10000
    3:06:49:28.969 cpu8:4362)0x417f80857af8:[0x418006d5c81d]vmk_PortLinkStatusSet@vmkernel:nover+0x58 stack: 0x417fc88e3ad8
    3:06:49:28.970 cpu8:4362)0x417f80857b18:[0x41800723a310]svs_set_vnic_link_state@esx:nover+0x27 stack: 0x4100afb3f530
    3:06:49:28.971 cpu8:4362)0x417f80857b48:[0x418007306a9f]sf_platform_set_link_state@esx:nover+0x96 stack: 0x417f80857b88
    3:06:49:28.971 cpu8:4362)0x417f80857b88:[0x41800725a31e]sf_set_port_admin_state@esx:nover+0x149 stack: 0x41800000002c
    3:06:49:28.972 cpu8:4362)0x417f80857cb8:[0x4180072bb5f0]sf_handle_dpa_call@esx:nover+0x657 stack: 0x417f80857cf8


    Ce problème a été relevé dans des environnements où le commutateur Cisco Nexus 1000v est utilisé.

    Ce problème est résolu dans cette version.
  • La plage d'adresses IP des VLAN ne s'affiche pas
    Si vous exécutez la commande esxcfg-info, Network Hint n'affiche pas certaines plages d'adresses IP VLAN sur une NIC physique. La plage d'adresses IP ne s'affiche pas non plus sur l'IU de vCenter Server. Un message d'erreur similaire au message suivant est consigné dans vmkernel.log :
    Dec 17 03:38:31 vmmon2 vmkernel: 8:19:26:44.179 cpu6:4102)NetDiscover: 732: Too many vlans for srcPort 0x2000002; won't track vlan 273

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

  • Le pilote e1000e du périphérique PCI ne prend pas en charge la fonction d'adresse MAC de substitution sur le sérialiseur/désérialiseur Intel 82571EB
    Le sérialiseur/désérialiseur Intel 82571EB du périphérique PCI ayant pour ID de périphérique 1060 prend en charge la fonction d'adresse MAC de substitution, mais le pilote e1000e de ce périphérique ne prend pas en charge cette fonction.

    Ce problème est résolu dans cette version.
  • Le serveur IBM échoue avec écran de diagnostic violet pendant une tentative d'injection de paquets de chemins lents
    Si les métadonnées associées au paquet de chemin lent sont copiées sans que ne soit vérifié si suffisamment de données ont été mappées, ces métadonnées seront déportées hors de la zone de cadre mappée et il en résultera une erreur de page. Ce problème est résolu en procédant au mappage des données nécessaires, de façon à inclure les métadonnées avant de les copier.
  • Lorsque vous désactivez la fusion sur ESX, l'hôte échoue avec un écran violet
    Sous ESX, lorsque vous utilisez vmxnet3comme vNIC dans certaines machines virtuelles et désactivez la fusion de paquets, l'hôte ESX échoue avec un écran violet au démarrage de la machine virtuelle.

    Ce problème est résolu en corrigeant la vérification de fusion et la logique d'assertion.
  • Lorsque l'association basée sur la charge modifie le mappage du port vNIC, vmkernel ne parvient pas à envoyer le Protocole de résolution d'adresse inverse (RARP)
    Si la passerelle basée sur la charge pNIC constitue la règle d'association du groupe de ports dvs et que le mappage vNIC-pNIC change en cas de saturation de certains pNIC, vmkernel ne peut envoyer des paquets RARP pour mettre à jour le commutateur physique, au regard de cette modification. De ce fait, les machines virtuelles perdent leur connectivité au réseau.

    Ce problème est résolu dans cette version.
  • La configuration de vSwitch est vide sur l'hôte ESX
    La configuration réseau d'un hôte ESX peut être vide sur vSphere Client. L'exécution de la commande esxcfg-vswitch -ldepuis la console du mode de support technique local échoue avec l'erreur :

    Failed to read advanced option subtree UserVars: Error interacting with configuration file
    /etc/vmware/esx.conf: Unlock of ConfigFileLocker failed : Error interacting with configuration file /etc/vmware/esx.conf: I am being asked to delete a .LOCK file that I'm not sure is mine. This is a bad thing and I am going to fail. Lock should be released by (0)


    Des messages d'erreur similaires aux messages suivants sont consignés dans hostd.log:

    [2011-04-28 14:22:09.519 49B40B90 verbose 'App'] Looking up object with name = "firewallSystem" failed.
    [2011-04-28 14:22:09.610 49B40B90 verbose 'NetConfigProvider'] FetchFn: List of pnics opted out
    [2011-04-28 14:22:09.618 49B40B90 info 'HostsvcPlugin'] Failed to read advanced option subtree UserVars: Error interacting with configuration file /etc/vmware/esx.conf: Unlock of ConfigFileLocker failed : Error interacting with configuration file /etc/vmware/esx.conf: I am being asked to delete a .LOCK file that I'm not sure is mine. This is a bad thing and I am going to fail. Lock should be released by (0)


    Ce problème est résolu dans cette version.
  • La connectivité réseau à une machine virtuelle configurée pour utiliser IPv6 peut échouer après l'installation de VMware Tools
    La connectivité réseau aux systèmes d'exploitation clients utilisant les versions du noyau 2.6.34 et ultérieures, et configurés pour utiliser IPv6 peut ne pas fonctionner après l'installation de VMware Tools.

    Ce problème est résolu dans cette version.
  • vSphere Client peut ne pas afficher l'adresse IPv6 sur certains systèmes d'exploitation clients
    Sur certains systèmes d'exploitation clients, les adresses IPv6 peuvent ne pas s'afficher dans vSphere Client, ainsi que dans la commande vmware-vim-cmd.

    Ce problème est résolu dans cette version.
  • L'exécution de la commande esxcli network connection list sur un hôte ESX engendre un message d'erreur
    La commande esxcli network connection listpeut générer un message d'erreur similaire aux messages suivants lorsque l'hôte ESX exécute des connexions IP brutes, telles que l'agent vSphere HA (FDM) et le ping ICMP :

    terminate called after throwing an instance of 'VmkCtl::Lib::SysinfoException' what(): Sysinfo error on operation returned status : Bad parameter. Please see the VMkernel log for detailed error information Aborted

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

Sécurité

  • La mise à jour vers le RPM glibc de la console de service ESX permet de résoudre plusieurs problèmes de sécurité
    Le RPM glibc de la console de service ESX est mis à jour vers la version glibc-2.5-81.el5_8.1 afin de résoudre plusieurs problèmes de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms CVE-2009-5029, CVE-2009-5064, CVE-2010-0830, CVE-2011-1089 , CVE-2011-4609 et CVE-2012-0864 à ces problèmes.
  • La mise à jour vers Apache Tomcat 6.0.35 résout plusieurs problèmes de sécurité
    Apache Tomcat a été mis à jour vers la version 6.0.35 afin de résoudre plusieurs problèmes de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms CVE-2011-3190, CVE-2011-3375, CVE-2011-4858 et CVE-2012-0022 à ces problèmes.
  • La mise à jour vers la console de service ESX Perl RPM résout plusieurs problèmes de sécurité
    La console de service ESX Perl RPM est mise à jour vers perl-5.8.8.32.1.8999.vmw afin de résoudre plusieurs problèmes de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms CVE-2010-2761, CVE-2010-4410, et CVE-2011-3597 à ces problèmes.
  • La mise à jour vers la console de service ESX popt, rpm, rpm-libs et les RPM rpm-python résout plusieurs problèmes de sécurité
    La console du service ESX popt, rpm, rpm-libs et les RPM rpm-python sont mis à jour vers les versions suivantes afin de résoudre plusieurs problèmes de sécurité :
    • popt-1.10.2.3-28.el5_8
    • rpm-4.4.2.3-28.el5_8
    • rpm-libs-4.4.2.3-28.el5_8
    • rpm-python-4.4.2.3-28.el5_8
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms CVE-2012-0060, CVE-2012-0061et CVE-2012-0815à ces problèmes.
  • La mise à jour vers la console de service ESX GnuTLS RPM résout plusieurs problèmes de sécurité
    La console de service ESX GnuTLS RPM est mise à jour vers la version 1.4.1-7.el5_8.2 afin de résoudre plusieurs problèmes de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms CVE-2011-4128, CVE-2012-1569et CVE-2012-1573à ces problèmes.
  • La mise à jour vers la console de service OpenSSL RPM résout un problème de sécurité
    La console du service OpenSSL RPM est mise à jour vers la version 0.9.8e-22.el5_8.3 afin de résoudre un problème de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a affecté le nom CVE-2012-2110 à ce problème.
  • La mise à jour de l'agent ThinPrint permet de supprimer l'appel de DLL
    Cette mise à jour supprime un appel à une DLL ThinPrint non-existante en guise de mesure de renforcement de la sécurité.
    VMware souhaite remercier Moshe Zioni de Comsec Consulting de nous avoir fait part de ce problème.
  • La mise à jour vers la console de service ESX RPM libmxl2 corrige un problème de sécurité
    Les RPM libmxl2 de la console de service ESX sont mis à jour vers libxml2-2.6.26-2.1.15.el5_8.2 et libxml2-python-2.6.26-2.1.15.el5_8.2 pour résoudre un problème de sécurité.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué le nom CVE-2012-0841 à ce problème.

Configuration des serveurs

  • L'hôte sur lequel le partage de page est désactivé échoue avec un écran violet
    Si vous exécutez une opération VMotion sur un hôte ESX sur lequel le partage de page est désactivé dans les options de démarrage, il est possible que l'hôte ESX échoue avec un écran violet.
    La désactivation du partage de page a une incidence importante sur les performances de l'hôte ESX. Le partage de page ne devant jamais être désactivé, l'option de configuration du partage de page est supprimée à partir de cette version.
  • L'hôte ESX consigne un état C1E incorrect
    Le vmkernel.loget la commande dmesg peuvent afficher le message suivant C1E enabled by the BIOS. Ce message peut aussi s'afficher même lorsque le C1E a été désactivé par le BIOS et ne pas s'afficher lorsque le C1E a été activé par le BIOS.

Stockage

  • Les messages du journal de stockage des composants PSA doivent être améliorés
    Le mécanisme de journalisation des erreurs de l'hôte ESX ne consigne pas tous les messages d'erreur, rendant ainsi difficile le diagnostic de problèmes de stockage.

    Ce problème est résolu en améliorant les messages de journaux relatifs aux composants PSA.
  • Le rétablissement d'un snapshot échoue lorsque les machines virtuelles référencent un fichier VMDK partagé
    Dans un environnement comportant deux machines virtuelles sous tension sur le même hôte ESX qui référencent un fichier VMDK partagé, les tentatives de rétablissement d'un snapshot sur l'une des machines virtuelles échouent et vSphere Client peut afficher une erreur File lock. Ce problème se produit avec les banques de données VMFS et NFS.

    Ce problème est résolu dans cette version.
  • Un volume VMFS endommagé provoque un épuisement de mémoire du segment VMFS
    Lorsqu'un hôte ESX rencontre un volume VMFS endommagé, le pilote VMFS peut subir une fuite de mémoire, ce qui provoque un épuisement de mémoire du segment VMFS. Ceci arrête toutes les opérations VMFS, entraînant des machines virtuelles orphelines et des banques de données manquantes. Les opérations de vMotion peuvent ne pas fonctionner et les tentatives de démarrage de nouvelles machines virtuelles peuvent échouer avec des erreurs concernant des fichiers manquants et un épuisement de mémoire. Ce problème peut avoir une incidence sur tous les hôtes ESX qui partagent le LUN endommagé et qui ont des machines virtuelles en cours d'exécution sur ce LUN.

    Ce problème est résolu dans cette version.
  • Le service VirtualCenter Agent échoue pendant une migration à froid
    Le service VirtualCenter Agent Service ( vpxa) peut échouer lors de la migration à froid d'une machine virtuelle. Des messages d'erreur similaires aux messages suivants sont consignés dans vpxd.log:

    [2011-11-02 12:06:34.557 03296 info 'App' opID=CFA0C344-00000198] [VpxLRO] -- BEGIN task-342826 -- vm-2851 -- vim.VirtualMachine.relocate -- 8D19CD22-FD15-44B9-9384-1DB4C1A7F7A2(ED8C34F5-CE61-4260-A8C1-D9CA5C2A1C4B)
    [2011-11-02 12:20:05.509 03296 error 'App' opID=CFA0C344-00000198] [VpxdVmprovUtil] Unexpected exception received during NfcCopy
    [2011-11-02 12:20:05.535 03296 error 'App' opID=CFA0C344-00000198] [migrate] (SINITAM02) Unexpected exception (vmodl.fault.HostCommunication) while relocating VM. Aborting.


    Ce problème est résolu dans cette version.
  • Un problème de délai d'attente du plug-in VMW_SATP_LSI provoque une annulation de chemin
    Dans certaines circonstances, les unités logiques (LU) des contrôleurs de stockage réclamées par le plug-in VMW_SATP_LSI peuvent ne pas répondre aux commandes d'évaluation de chemin émises par le plug-in dans un délai d'expiration de 5 secondes. Lorsque deux ou plusieurs hôtes vSphere partagent un accès aux LU concernées, il peut en résulter une annulation de chemin (voir Annulation de chemins d'accès).

    Dans cette version, la valeur du délai d'attente du plug-in VMW_SATP_LSI est portée à 10 secondes. Avant d'installer cette mise à jour, consultez votre fournisseur de stockage afin de déterminer la valeur du délai E/S du système d'exploitation client.
  • Impossible de créer une banque de données plus grande que 2 To-512 octets sur l'hôte ESX 4.x à l'aide de vSphere Client
    Avant la sortie de cette version, il était possible de créer une base de données plus grande que 2 To-512 octets à l'aide de l'interface de la ligne de commande de vSphere. Toutefois, cette configuration n'est plus prise en charge.

    Désormais, toute tentative de création d'une banque de données plus grande que 2 To-512 à l'aide de l'interface de la ligne de commande de vSphere échoue de façon normale.
  • Les messages d'avertissement sont consignés pendant une opération de récupération de pulsation
    VMFS peut produire des E/S vers un volume lorsqu'une opération de récupération de pulsation est en cours ou qu'une opération de réinitialisation virtuelle est effectuée sur un périphérique sous-jacent. Par conséquent, les messages d'avertissement similaires aux messages suivants sont consignés :

    WARNING: ScsiDeviceIO: 2360: Failing WRITE command (requiredDataLen=512 bytes) to write-quiesced partition naa.9999999999

    En outre, la console ESX signale un message d'alerte.

    Ces avertissements et ces alertes sont sans incidence et peuvent être ignorés.

    Dans cette version, les messages d'alerte sont supprimés et les avertissements sont modifiés en messages de journal.
  • L'installation de certaines versions de VMware Tools provoque un débordement de journal
    Lorsque vous installez certaines versions de VMware Tools, la version 8.3.7 par exemple, un débordement de messages similaire à ce qui suit peut être consigné dans vmkernel.log:

    Nov 22 11:55:06 vm_name-c vmkernel: 107:01:39:59.667 cpu12:21263)VSCSIFs: 329: handle 9267(vscsi0:0):Invalid Opcode (0xd1)
    Nov 22 11:55:06 vm_name-c vmkernel: 107:01:39:59.687 cpu5:9487)VSCSIFs: 329: handle 9261(vscsi0:0):Invalid Opcode (0xd1)


    Ce problème est résolu dans cette version.
  • Le plug-in SATP par défaut est modifié pour les baies LSI prises en charge par ALUA
    Sur les hôtes ESX 4.1Update2, le SATP (Storage Array Type Plugin) par défaut pour les baies LSI était VMW_SATP_LSI, qui ne prenait pas en charge la fonctionnalité ALUA (Asymmetric Logical Unit Access). À partir de cette version, le Plugin SATP pour les baies LSI qui prend en charge ALUA est modifié pour VMW_SATP_ALUA, de sorte que les baies TPGS / ALUA soient automatiquement réclamées par le plugin satp par défaut VMW_SATP_ALUA. Les baies de stockage suivantes sont réclamées par VMW_SATP_ALUA :
    Description du modèle de fournisseur
    • LSI INF-01-00
    • IBM ^1814* DS4000
    • IBM ^1818* DS5100/DS5300
    • IBM ^1746* IBM DS3512/DS3524
    • DELL MD32xx Dell MD3200
    • DELL MD32xxi Dell MD3200i
    • DELL MD36xxi Dell MD3600i
    • DELL MD36xxf Dell MD3600f
    • SUN LCSM100_F
    • SUN LCSM100_I
    • SUN LCSM100_S
    • SUN STK6580_6780 Sun StorageTek 6580/6780
    • SUN SUN_6180 Sun Storage 6180
    • SGI IS500 SGI InfiniteStorage 4000/4100
    • SGI IS600 SGI InfiniteStorage 4600

  • L'hôte ESX peut signaler des problèmes sur le volume VMFS corrompu lorsque vous supprimez des fichiers de répertoires qui ont plus de 468 fichiers sur un hôte ESX
    Une tentative de suppression d'un fichier dans un répertoire qui contient plus de 468 fichiers ou de suppression du répertoire lui-même peut échouer et il est possible que l'hôte ESX signale par erreur que le VMFS est corrompu. L'hôte ESX consigne les messages d'erreur similaires aux messages suivants dans le fichier  /var/log/vmkernel :

    cpu10:18599)WARNING: Fil3: 10970: newLength 155260 but zla 2
    cpu10:18599)Fil3: 7054: Corrupt file length 155260, on FD <70, 93>, not truncating

    Ce problème est résolu dans cette version.
  • L'hôte ESX peut échouer avec un écran de diagnostic violet en raison d'un problème rencontré dans le module VMFS.
    Un hôte ESX peut échouer avec un écran de diagnostic violet qui affiche des messages d'erreur similaires aux messages suivants en raison d'un problème dans le module VMFS.

    @BlueScreen: #PF Exception 14 in world 8008405:vmm0:v013313 IP 0x418001562b6d addr 0x28
    34:15:27:55.853 cpu9:8008405)Code start: 0x418000e00000 VMK uptime: 34:15:27:55.853
    34:15:27:55.853 cpu9:8008405)0x417f816af398:[0x418001562b6d]PB3_Read@esx:nover+0xf0 stack: 0x41000e1c9b60
    34:15:27:55.854 cpu9:8008405)0x417f816af468:[0x4180015485df]Fil3ExtendHelper@esx:nover+0x172 stack: 0x0
    34:15:27:55.854 cpu9:8008405)0x417f816af538:[0x41800154ded4]Fil3_SetFileLength@esx:nover+0x383 stack: 0xa00000001
    34:15:27:55.854 cpu9:8008405)0x417f816af5a8:[0x41800154e0ea]Fil3_SetFileLengthWithRetry@esx:nover+0x6d stack: 0x417f816af5e8
    34:15:27:55.854 cpu9:8008405)0x417f816af638:[0x41800154e38b]Fil3_SetAttributes@esx:nover+0x246 stack: 0x41027fabeac0
    34:15:27:55.854 cpu9:8008405)0x417f816af678:[0x41800101de7e]FSS_SetFileAttributes@vmkernel:nover+0x3d stack: 0x1000b000
    34:15:27:55.855 cpu9:8008405)0x417f816af6f8:[0x418001434418]COWUnsafePreallocateDisk@esx:nover+0x4f stack: 0x4100a81b4668
    34:15:27:55.855 cpu9:8008405)0x417f816af728:[0x418001434829]COWIncrementFreeSector@esx:nover+0x68 stack: 0x3
    34:15:27:55.855 cpu9:8008405)0x417f816af7b8:[0x418001436b1a]COWWriteGetLBNAndMDB@esx:nover+0x471 stack: 0xab5db53a0
    34:15:27:55.855 cpu9:8008405)0x417f816af908:[0x41800143761f]COWAsyncFileIO@esx:nover+0x8aa stack: 0x41027ff88180
    34:15:27:55.855 cpu9:8008405)0x417f816af9a8:[0x41800103d875]FDS_AsyncIO@vmkernel:nover+0x154 stack: 0x41027fb585c0
    34:15:27:55.856 cpu9:8008405)0x417f816afa08:[0x4180010376cc]DevFSFileIO@vmkernel:nover+0x13f stack: 0x4100077c3fc8


    Ce problème est résolu dans cette version.
  • L'hôte ESX ne répond plus lorsque le module VMW_SATP_LSI est à court de mémoire du segment
    Ce problème se produit sur les serveurs qui ont accès aux LUN réclamés par le module VMW_SATP_LSI. Une fuite de mémoire dans un module VMW_SATP_LSI force le module à manquer de mémoire. Des messages d'erreur similaires aux messages suivants sont consignés dans le fichier vmkernel.log :

    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2218: Heap VMW_SATP_LSI already at its maximumSize. Cannot expand.
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2481: Heap_Align(VMW_SATP_LSI, 316/316 bytes, 8 align) failed. caller: 0x41800a9e91e5
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: VMW_SATP_LSI: satp_lsi_IsInDualActiveMode: Out of memory.


    La fuite de mémoire du module VMW_SATP_LSI a été résolue dans cette version.
  • L'hôte ESX peut échouer avec un écran violet lors de la resignature d'un volume VMFS
    Un hôte ESX peut échouer avec un écran de diagnostic violet qui affiche des messages d'erreur similaires aux messages suivants lors de l'opération de resignature d'un volume VMFS.

    #DE Exception 0 in world 20519269:helper22-6 @ 0x418024b26a33
    117:05:20:07.444 cpu11:20519269)Code start: 0x418024400000 VMK uptime: 117:05:20:07.444
    117:05:20:07.444 cpu11:20519269)0x417f84b2f290:[0x418024b26a33]Res3_ExtendResources@esx:nover+0x56 stack: 0x4100ab400040
    117:05:20:07.445 cpu11:20519269)0x417f84b2f2e0:[0x418024af9a58]Vol3_Extend@esx:nover+0x9f stack: 0x0
    117:05:20:07.445 cpu11:20519269)0x417f84b2f4f0:[0x418024afd3f6]Vol3_Open@esx:nover+0xdc9 stack: 0x417f84b2f668
    117:05:20:07.446 cpu11:20519269)0x417f84b2f6a0:[0x4180246225d1]FSS_Probe@vmkernel:nover+0x3ec stack: 0x417f84b2f6f0
    117:05:20:07.446 cpu11:20519269)0x417f84b2f6f0:[0x41802463d0e6]FDS_AnnounceDevice@vmkernel:nover+0x1dd stack: 0x3133306161336634


    Ce problème est résolu dans cette version.
  • L'hôte ESX échoue avec un écran violet et le message d'erreur Mémoire insuffisante des minuteurs lors d'une opération de recomposition de VMware View
    Un hôte ESX peut échouer avec un écran de diagnostic violet affichant des messages d'erreur et une arborescence des appels de procédures similaires aux messages suivants lors d'une opération de recomposition de VMware View :

    @BlueScreen: Out of memory for timers
    0:20:06:44.618 cpu38:4134)Code start: 0x418033600000 VMK uptime: 0:20:06:44.618
    0:20:06:44.619 cpu38:4134)0x417f80136cf8:[0x418033658726]Panic@vmkernel:nover+0xa9 stack: 0x417f80136d78
    0:20:06:44.619 cpu38:4134)0x417f80136d28:[0x41803367958e]TimerAlloc@vmkernel:nover+0x10d stack: 0x9522bf175903
    0:20:06:44.619 cpu38:4134)0x417f80136d78:[0x418033679fbb]Timer_AddTC@vmkernel:nover+0x8a stack: 0x4100b8317660
    0:20:06:44.620 cpu38:4134)0x417f80136e08:[0x41803384d964]SCSIAsyncDeviceCommandCommon@vmkernel:nover+0x2f7 stack: 0x41037db8c
    0:20:06:44.620 cpu38:4134)0x417f80136e58:[0x41803383fbed]FDS_CommonAsyncIO@vmkernel:nover+0x48 stack: 0x410092dea0e8


    Ce problème est résolu dans cette version.
  • Les données du pilote Emulex LPe12000 sont corrompues pendant la gestion de l'adresse limite 4G DMA
    Dans l'hôte ESX, lorsque le pilote Emulex LPe12000 ne peut définir la valeur dma_boundarydu modèle hôte, cette valeur dma_boundary est définie sur zéro. De ce fait, les adresses de la liste SG outrepassent la limite définie pour le pilote, ce qui engendre une corruption des données.

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

Matériel pris en charge

  • Impossible de modifier la règle d'alimentation d'un hôte ESX sur le serveur IBM BladeCenter HX5 UEFI
    Lorsque vous essayez de modifier la règle d'alimentation d'un hôte ESX qui s'exécute sur un serveur IBM BladeCenter HX5 UEFI, les paramètres de gestion de l'alimentation sur vSphere Client affichent le message suivant :

    Technology: Not Available
    Active Policy: Not Supported.


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

Mise à niveau et installation

  • L'installation d'ESX en mode graphique génère un affichage non aligné sur des serveurs spécifiques Dell PowerEdge 12G
    Lorsque vous installez ESX en mode graphique sur des serveurs 12G, l'alignement de l'écran d'installation est incorrect. Ce problème a été observé sur tous les serveurs 12G. L'utilisation du pilote vesa pour le programme d'installation résout ce problème.

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

vCenter Server, vSphere Client et vSphere Web Access

  • Les services hostd et vpxa échouent et l'hôte ESX se déconnecte de vCenter Server
    Une erreur sfcb-vmware_base TIMEOUTpeut provoquer un échec des services hostd et vpxa, ainsi qu'une déconnexion intermittente de l'hôte ESX de vCenter Server. Des messages d'erreur similaires aux messages suivants sont consignés dans /var/log/messages:

    Jan 30 12:25:17 sfcb-vmware_base[2840729]: TIMEOUT DOING SHARED SOCKET RECV RESULT (2840729)
    Jan 30 12:25:17 sfcb-vmware_base[2840729]: Timeout (or other socket error) waiting for response from provider
    Jan 30 12:25:17 sfcb-vmware_base[2840729]: Request Header Id (1670) != Response Header reqId (0) in request to provider 685 in process 3. Drop response.
    Jan 30 12:25:17 vmkernel: 7:19:02:45.418 cpu32:2836462)User: 2432: wantCoreDump : hostd-worker -enabled : 1


    Ce problème est résolu dans cette version.
  • vSphere Client affiche des données incorrectes pour une machine virtuelle
    Les diagrammes de présentation des performances de vSphere Client peuvent afficher des données pour machine virtuelle, même pour la période pendant laquelle la machine virtuelle était hors tension.

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

Gestion des machines virtuelles

  • Le fichier VMX peut être corrompu pendant une opération de suspension du snapshot
    Lorsque vous créez un snapshot mis au repos d'une machine virtuelle à l'aide du service VSS, du pilote SYNC de VMware Tools ou d'un agent de sauvegarde, hostd écrit dans le fichier .vmx. Par conséquent, le fichier .vmxdevient vide.

    Ce problème est résolu dans cette version.
  • La machine virtuelle échoue avec une alerte du moniteur si la pagination est désactivée
    Un message d'erreur similaire au message suivant est consigné dans vmware.log:

    Aug 16 14:17:39.158: vcpu-0| MONITOR PANIC: vcpu-1:VMM64 fault 14: src=MONITOR rip=0xfffffffffc262277 regs=0xfffffffffc008c50

    Ce problème est résolu dans cette version.
  • Les machines virtuelles Windows 2003 sur un hôte ESX avec un CPU basé sur l'architecture NetBurst mettent longtemps à redémarrer
    Le redémarrage d'une machine virtuelle Windows 2003 Server avec des pages mémoire partagées dure approximativement de 5 à 10 minutes si un CPU basé sur l'architecture NetBurst est installé sur l'hôte ESX. Cependant, vous pouvez arrêter cette même machine virtuelle et la mettre sous tension sans allonger la durée du démarrage.

    Ce problème est résolu dans cette version.
  • La tâche de reconfiguration de la machine virtuelle échoue parfois en raison d'un blocage
    Dans certains scénarios, la tâche de reconfiguration d'une machine virtuelle échoue en raison d'un blocage. Le blocage survient pendant l'exécution des opérations de reconfiguration et de modification des banques de données.

    Ce problème est résolu dans cette version.
  • La suppression d'une machine virtuelle entraîne la suppression des disques virtuels non associés
    Si vous créez un snapshot de machine virtuelle et que vous supprimez par la suite la machine virtuelle, les disques virtuels indépendants ou non indépendants qui ont auparavant été détachés de la machine virtuelle peuvent également être supprimés.

    Ce problème est résolu dans cette version.
  • Les valeurs d'espace de la configuration PCI du VMDirectIO entre ESX et la machine virtuelle sont incohérentes
    Lorsque vous définissez le chemin VMDirectIO pour un adaptateur d'interface réseau en mode intercommunication et l'assignez à une machine virtuelle, l'état du bit de désactivation/interruption du registre de contrôle de périphérique (INTx) s'affiche comme activé pour la machine virtuelle et désactivé pour ESX. Cette situation est incorrecte, car la valeur INTx doit être activée dans les deux cas.

    Ce problème est résolu dans cette version.
  • Les trames BPDU (Bridge Protocol Data Unit) envoyées à partir du NIC relié par pont désactive la liaison montante physique
    Lorsque vous activez le garde BPDU sur le port du commutateur physique, les trames BPDU envoyées à partir du NIC virtuel relié par pont provoquent la désactivation de la liaison montante physique et, par conséquent, la perte de cette liaison.
    Identifiez l'hôte ayant envoyé les paquets BPDU et paramétrez esxcfg-advcfg -s 1 /Net/BlockGuestBPDUsur cet hôte. Cette action filtre et bloque les paquets BPDU en provenance du NIC virtuel. Les machines virtuelles dotées de NIC virtuels reliés par pont ne doivent être mises sous tension qu'après avoir activé ce filtre, ce qui permettra à ce dernier de prendre effet.

    Ce problème est résolu dans cette version.
  • Impossible de supprimer les paramètres extraConfig d'une machine virtuelle à l'aide d'API
    Ce problème est résolu dans cette version.

VMware HA et Fault Tolerance

  • La machine virtuelle FT secondaire sur l"hôte ESX peut échouer
    Sur un hôte ESX, une machine virtuelle secondaire avec Fault Tolerance installée avec l'adaptateur VMXNET 3 peut échouer. Des messages d'erreur similaires aux messages suivants sont consignés dans vmware.log :

    Dec 15 16:11:25.691: vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    Dec 15 16:11:25.691: vmx| Vix: [115530 guestCommands.c:2468]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    Dec 15 16:11:30.287: vcpu-0| StateLogger::Commiting suicide: Statelogger divergence
    Dec 15 16:11:31.295: vmx| VTHREAD watched thread 4 "vcpu-0" died


    Ce problème ne survient pas sur les machines virtuelles installées avec un adaptateur E1000.

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

vMotion et Storage vMotion

  • Lorsque vous migrez les machines virtuelles Windows 2008 de ESX4.0 vers ESX4.1 puis effectuez une opération Storage vMotion, les snapshots mis au repos échouent
    Une opération Storage vMotion sur ESX 4.1 par défaut définit disk.enableUUIDsur vrai pour une machine virtuelle Windows 2008, permettant ainsi une mise au repos de l'application. L'opération suivante de mise au repos de snapshot échoue jusqu'à ce que la machine virtuelle entreprenne un cycle d'alimentation.

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

VMware Tools

  • Le service VMware Snapshot Provider (vmvss) n'est pas supprimé lors de la désinstallation de VMware Tools sur les systèmes d'exploitation clients Windows 2008 R2

    Ce problème est résolu dans cette version.
  • Certaines machines virtuelles SLES ne redémarrent pas après la mise à niveau de VMware Tools
    Après avoir mis à niveau VMware Tools sur certaines machines virtuelles SLES telles que SLES 10 SP4 et SLES 11 SP2, les tentatives de redémarrage de la machine virtuelle peuvent échouer avec un message d'erreur waiting for sda2....... not responding. Ce problème se produit parce que les options INITRD_MODULESdans /etc/sysconfig/kernelsont supprimées pendant le processus de désinstallation de VMware Tools.

    Ce problème est résolu dans cette version. Cependant, ce problème peut encore survenir si vous effectuez une mise à niveau d'une version antérieure de VMware Tools vers la version de VMware Tools disponible dans cette version. Voir le document d'information technique 7005233 sur le site Web de Novell.
  • Le délai d'attente de la mise à niveau de VMware Tools expire sur ESX 4.1 Update 1
    Sur les machines virtuelles exécutant ESX 4.1 Update 1, le délai d'attente des tentatives de mise à niveau de VMware Tools peut expirer. Des messages d'erreur similaires aux messages suivants sont consignés dans vmware.log :

    Nov 30 15:36:34.839: vcpu-0| TOOLS INSTALL finished copying upgrader binary into guest. Starting Upgrader in guest.
    Nov 30 15:36:34.840: vcpu-0| TOOLS INSTALL Sending "upgrader.create 1"
    Nov 30 15:36:34.902: vcpu-0| TOOLS INSTALL Received guest file root from upgrader during unexpected state...ignoring.
    Nov 30 15:36:34.904: vcpu-0| GuestRpc: Channel 6, unable to send the reset rpc.
    Nov 30 15:36:34.905: vcpu-0| GuestRpc: Channel 6 reinitialized.


    Ce problème est résolu dans cette version.
  • Le service VMware Tools échoue lors du démarrage d'une machine virtuelle Windows 2008 R2
    Le service VMware Tools ( vmtoolsd.exe) échoue pendant le processus de démarrage du système d'exploitation client Windows 2008 R2. Cependant, vous pouvez démarrer ce service manuellement lorsque le processus de démarrage du système d'exploitation est terminé.

    Ce problème est résolu dans cette version.
  • Esxtop échoue lors d'une tentative de capture par lots sur un serveur disposant de 128 CPU
    Lorsque vous tentez une capture par lots sur un serveur disposant de 128 CPU logiques, esxtop échoue. Cette situation se produit en raison de la taille limitée du tampon de l'en-tête. L'augmentation de la taille du tampon de l'en-tête résout ce problème.
  • La désinstallation ou la mise à niveau de VMware Tools supprime les entrées personnalisées dans le fichier modprobe.conf
    Les modifications que vous effectuez dans le fichier /etc/modprobe.confpeuvent être écrasées lors de la désinstallation ou de la mise à niveau de VMware Tools.

    Ce problème est résolu dans cette version.
  • La virtualisation IP du bureau à distance Windows Server 2008 R2 64 bits peut ne pas fonctionner sur ESX 4.0 Update 1
    La virtualisation IP, qui vous permet d'allouer des adresses IP uniques aux sessions RDP, peut rencontrer des problèmes de fonctionnement sur un système Windows Server 2008 R2 64 bits opérant sur ESX 4.0 Update 1. Cette situation survient parce que les dll vsock ont été enregistrés par des fichiers exécutables distincts de 32 et 64 bits. De ce fait, les ID des catalogues se désynchronisent entre les catalogues Winsock 32 et 64 bits du vSock LSP.

    Ce problème est résolu dans cette version.
  • La mise à niveau de VMware Tools ne remplace pas le pilote VMCI requis pour la virtualisation IP du bureau à distance
  • Lorsque vous effectuez une mise à niveau de VMware Tools d'une version antérieure à une version plus récente, la virtualisation IP échoue. Ce problème survient parce que l'hôte ESX ne peut vérifier la version du nouveau pilote VMCI, ni installer les fichiers DLL vsock.

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

Sauvegarde

  • Les commandes de console de service VCB génèrent des messages d'erreur dans la console de service ESX
    Lorsque vous exécutez des commandes de console de service VCB dans la console de service des hôtes ESX, un message de ce type peut s'afficher :

    Closing Response processing in unexpected state:3
    canceling invocation: server=TCP:localhost:443, moref=vim.SessionManager:ha-sessionmgr, method=logout

    Closing Response processing in unexpected state:3
    [.... error 'App'] SSLStreamImpl::BIORead (58287920) failed: Thread pool shutdown in progress
    [.... error 'App'] SSLStreamImpl::DoClientHandshake (58287920) SSL_connect failed with BIO Erro


    Vous pouvez ignorer ces messages. Ces messages n'ont pas d'impact sur les résultats de commandes de console de service VCB.

    Solution : Aucune.

CIM et API

  • 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é. Vous ne pouvez pas appeler la méthode SetBIOSAttribute à cause de ce problème. La bibliothèque SFCC dans les hôtes ESX 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

  • La fenêtre d’installation n’est pas correctement affichée durant l'installation du système d'exploitation client RHEL 6.1 (KB 2003588).
  • 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 des paquets VMware Tools OSP sur les systèmes d'exploitation clients 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 paquets 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.

Divers

  • Un hôte ESX/ESXi 4.1 U2 sur lequel est installé vShield Endpoint 1.0 échoue avec un écran de diagnostic violet qui mentionne VFileFilterReconnectWork (KB 2009452).

  • 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 ESX 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 resxtop ou esxtop sur une longue période, arrêtez et redémarrez resxtop ou esxtop périodiquement au lieu d'exécuter une instance resxtop ou esxtop pendant 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-pciiddans la console de service pour énumérer les contrôleurs et les adaptateurs Ethernet, vous pouvez voir un message d'avertissement comme suit :
    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.

Mise en réseau

  • Certaines versions du pilote VMXNET 3 ne parviennent pas à initialiser le périphérique lorsque le nombre de vCPU n'est pas une puissance de deux (KB 2003484).

  • 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 d'avoir 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, l'activation de LRO sur un périphérique VMXNET2 ou VMXNET3 sur une machine virtuelle acheminant le trafic exécutant un système d'exploitation client Linux peut affecter les 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.
  • Les adaptateurs réseau de console de service et VMkernel récemment créés disparaissent après un cycle d'alimentation
    Si un hôte ESX est en cycle d'alimentation dans l'heure de création d'un nouvel adaptateur VMkernel ou de console de service sur un vDS, le nouvel adaptateur peut disparaître.

    Solution : si vous devez exécuter un cycle d'alimentation sur un hôte ESX dans l'heure de création d'un adaptateur VMkernel ou de console de service, exécutez
    esxcfg-boot -r dans l'interface de ligne de commande de l'hôte avant de redémarrer l'hôte.

Configuration des serveurs

  • La mise à niveau vers ESX 4.1.x échoue lorsque LDAP est configuré sur l'hôte et que le serveur LDAP n'est pas accessible
    La mise à niveau d'ESX 4.x vers ESX 4.1.x échoue lorsque vous avez configuré LDAP sur l'hôte ESX et que le serveur LDAP n'est pas accessible.

    Solution : pour résoudre ce problème, procédez de l'une des manières suivantes :

    • Définissez les paramètres suivants dans le fichier /etc/ldap.conf.
      • Pour permettre aux connexions au serveur LDAP d'expirer, affectez à bind_policyla valeur soft.
      • Pour définir le délai d'expiration du serveur LDAP en secondes, affectez à bind_timelimitla valeur 30.
      • Pour définir le délai d'expiration LDAP par interrogation en secondes, affectez à timelimitla valeur 30.

         

    • Désactivez et activez LDAP après la mise à niveau.
      1. Désactivez LDAP en exécutant la commande esxcfg-auth --disableldapdepuis la console de service avant la mise à niveau.
      2. Activez LDAP en exécutant la commande esxcfg-auth --enableldap --enableldapauth --ldapserver=xx.xx.xx.xx --ldapbasedn=xx.xx.xxdepuis la console de service après la mise à niveau.

Stockage

  • Un hôte ESX échoue avec un écran violet lorsqu'un LUN est ajouté à certains systèmes d'exploitation clients, par intervalles de 10 secondes *
    L'écran de diagnostic violet affiche des messages d'erreur similaires aux messages suivants :

    20:16:16:49.575 cpu0:4120)Code start: 0x41801d800000 VMK uptime: 20:16:16:49.575
    20:16:16:49.576 cpu0:4120)0x417f800c7c18:[0x41801ddb5cf4]fnic_fcpio_cmpl_handler@esx:nover+0x8ef stack: 0x1dc0
    20:16:16:49.577 cpu0:4120)0x417f800c7c68:[0x41801ddb4aa0]fnic_wq_copy_cmpl_handler@esx:nover+0xaf stack: 0x417f800c7d18
    20:16:16:49.577 cpu0:4120)0x417f800c7c88:[0x41801ddb97dd]fnic_isr_msix_wq_copy@esx:nover+0x18 stack: 0x22
    20:16:16:49.578 cpu0:4120)0x417f800c7cc8:[0x41801dc7fd64]Linux_IRQHandler@esx:nover+0x43 stack: 0x83
    20:16:16:49.578 cpu0:4120)0x417f800c7d58:[0x41801d8323e1]IDTDoInterrupt@vmkernel:nover+0x348 stack: 0x4100b1a77ed0
    20:16:16:49.579 cpu0:4120)0x417f800c7d98:[0x41801d8326ba]IDT_HandleInterrupt@vmkernel:nover+0x85 stack: 0x12927df33a3a96
    20:16:16:49.580 cpu0:4120)0x417f800c7db8:[0x41801d83300d]IDT_IntrHandler@vmkernel:nover+0xc4 stack: 0x417f800c7ec0


    Il s'agit d'un problème connu qui survient dans les environnements qui utilisent la carte d'interface virtuelle (VIC) Cisco UCS M81KR.

    Solution : Utilisez le pilote async. Consultez Cisco pour déterminer la version correcte.

  • 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 distante ou d'une console de service ne configure pas l'opération iSCSI sur une carte réseau VMkernel dont le nom de périphérique logique dépasse 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 la console de service échoueront parce qu'elles sont incapables de 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 être compatible avec l'exigence 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 de port.


  • 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 ESX*
    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'expiration pour les commandes synchrones au cours du démarrage en affectant la valeur de 10000 au paramètre Scsi.CRTimeoutDuringBoot.

    Pour modifier le paramètre depuis 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

  • ESX 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, ESX 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 pour plus d'informations sur la configuration de l'option de démarrage des hôtes ESX.
  • 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 sur la console au sujet de l'interruption Lint1 ou de 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 sur la console ou une 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 d'ESX sur les systèmes HP nécessitent le pilote HP NMI
    Les instances d'ESX 4.1 sur les systèmes HP (G7 et versions antérieures) nécessitent le pilote HP NMI pour garantir le bon fonctionnement des interruptions non masquables (NMI). Le pilote NMI garantit que les NMI sont bien détectés et connectés à IML. Sans ce pilote, les NMI signalant les erreurs matérielles sont ignorés par les systèmes HP exécutant ESX.
    Attention :Si ce pilote n'est pas installé, certains événements NMI peuvent être ignorés par le SE. En l'absence de prise en compte des événements NMI, le système peut devenir instable.

    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 aussi 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. vSphere Client affiche temporairement Inconnu comme l'état de l'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 ESX sur la plateforme HP G6 avec P410i ou P410 Smart Array Controller
    Certains de ces hôtes peuvent montrer un ralentissement des performances au cours de la mise sous tension de la machine virtuelle ou de la génération des E/S du 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 ce 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" failed on physical path "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Possible sense data: 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


    Ce problème est provoqué par l'absence d'un module de mémoire cache sur batterie.
    Sans module de mémoire cache sur batterie, le contrôleur fonctionne en mode Zero Memory Raid, ce qui limite de façon importante le nombre de commandes simultanées que le contrôleur peut traiter.

    Solution : Installez le module de HP 256MB P-series Cache Upgrade à partir du site Web de HP.

Mise à niveau et installation

  • La mise à niveau vers ESX 4.1 Update 2 échoue si vous appliquez le bulletin de pré-mise à niveau pre-upgrade-from-ESX4.0-to-4.1.0-1.4.348481-release.zip
    Après avoir appliqué le bulletin de pré-mise à niveau pre-upgrade-from-ESX4.0-to-4.1.0-1.4.348481-release.zipsur les hôtes avec les mises à jour et les correctifs publiés après septembre 2010, qui incluent ESX400-201009001 et ESX 4.0 Update 3, lorsque vous tentez une mise à niveau vers ESX 4.1 Update 2, la mise à niveau échoue et provoque l'erreur suivante :

    Encountered error RunCommandError:
     This is an unexpected error. Please report it as a bug.
    Error Message - Command '['/usr/bin/vim-cmd', 'hostsvc/runtimeinfo']'
    terminated due to signal 6


    Ce problème ne se produit pas si vous appliquez le bulletin de pré-mise à niveau pre-upgrade-from-esx4.0-to-4.1-502767.zip.

    Solution : appliquer le bulletin esxupdate pre-upgrade-from-esx4.0-to-4.1-502767.zipavant d'appliquer le lot de mise à niveau.

    Remarque : utiliser ce bulletin uniquement si vous effectuez une mise à niveau en utilisant l'utilitaire esxupdate. Vous n'avez pas besoin d'appliquer ce bulletin pour une mise à niveau en utilisant le gestionnaire de mise à jour de VMware Update Manager.

  • La mise à niveau d'hôte vers ESX/ESXi 4.1 Update 1 échoue si vous l'effectuez en utilisant 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.

  • La console de service ESX affiche des messages d'erreur lors de la mise à niveau d'ESX 4.0 ou ESX 4.1 vers ESX 4.1.x
    Lorsque vous effectuez une mise à niveau d'ESX 4.0 ou ESX 4.1 vers ESX 4.1.x, la console de service peut afficher des messages d'erreur de ce type :
    Sur l'hôte ESX 4.0 : Erreur lors de la vérification de la version : The system call API checksum doesn't match"
    Sur l'hôte ESX 4.1 : Vmkctl & VMkernel Mismatch,Signature mismatch between Vmkctl & Vmkernel

    Vous pouvez ignorer les messages.

    Solution :redémarrez l'hôte ESX 4.1.x.

  • La sortie de la commande esxupdate -a n'affiche pas les pilotes intégrés lors de la mise à niveau de l'hôte ESX de la version ESX 4.0 Update 2 vers ESX 4.1.x
    Lorsque vous mettez à niveau l'hôte ESX d'ESX 4.0 Update 2 vers ESX 4.1.x en utilisant l'utilitaire esxupdate, la sortie de la commande esxupdate -an'affiche pas les pilotes intégrés.

    Solution
    Exécutez la commande d'information esxupdate -b <ESX410-Update01>pour afficher les informations sur tous les bulletins de pilotes intégrés et asynchrones disponibles pour la version ESX 4.1.x.

  • La mise à niveau vers ESX 4.1.x échoue lorsqu'une version antérieure d'IBM Management Agent 6.2 est configurée sur l'hôte
    Lorsque vous mettez à niveau un hôte d'ESX 4.x vers ESX 4.1.x, la mise à niveau échoue et des messages d'erreur apparaissent dans ESX et VUM :

    • Dans ESX, l'hôte consigne le message suivant dans le fichier esxupdate.log : DependencyError: VIB rpm_vmware-esx-vmware-release-4_4.1.0-0.0.260247@i386 breaks host API vmware-esx-vmware-release-4 <= 4.0.9.
    • Dans VUM, l'onglet Tâche et événements affiche le message suivant : Remediation did not succeed : SingleHostRemediate: esxupdate error, version: 1.30, "operation: 14: There was an error resolving dependencies.

    Ce problème se produit lorsque l'hôte ESX 4.x exécute une version antérieure d'IBM Management Agent 6.2.

    Solution : installez IBM Management Agent 6.2 sur l'hôte ESX 4.x et mettez-le à niveau vers ESX 4.1.x.

  • L'analyse de l'hôte ESX par rapport au bulletin ESX410-Update01 ou ESX410-201101226-SG affiche un message d'état d'incompatibilité
    Lorsque vous utilisez VUM pour exécuter une analyse par rapport à un hôte ESX contenant le bulletin ESX410-Update01 ou ESX410-201101226-SG, le résultat de l'analyse peut indiquer un état d'incompatibilité.

    Solution :
  •  
    • Ignorez le message d'état d'incompatibilité et continuez avec le processus de correction.
    • Supprimez le message d'état d'incompatibilité en installant le bulletin ESX410-201101203-UG et exécutez l'analyse.

vMotion et Storage vMotion

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

Interface de ligne de commande de vSphere

  • L'exécution de vicfg-snmp -r ou vicfg-snmp -D sur les systèmes ESX échoue
    Sur un système ESX, lorsque vous tentez de réinitialiser les paramètres SNMP en cours en exécutant la commande
    vicfg-snmp -r ou de désactiver l'agent SNMP en exécutant la commande vicfg-snmp -D , la commande échoue. Cet échec survient, car la commande tente d'exécuter la commande esxcfg-firewall qui se verrouille et ne répond plus. Lorsque esxcfg-firewall ne répond pas, la commande vicfg-snmp -r ou vicfg-snmp -D génère un dépassement du délai d'expiration et signale une erreur. Le problème ne se pose pas sur les systèmes ESXi.

    Solution : le démarrage du système ESX supprime le fichier de verrouillage et applique la commande précédemment exécutée
    vicfg-snmp qui a entraîné le verrouillage. Toutefois, les tentatives d'exécuter vicfg-snmp -r ou vicfg-snmp -D aboutissent encore à une erreur.

VMware Tools

  • Impossible d'utiliser la carte d'interface réseau VMXNET après l'installation de VMware Tools dans RHEL3 avec le dernier noyau corrigé sur ESX 4.1 U1
    Certains pilotes dans VMware Tools préconfigurés avec les modules RHEL 3.9 ne fonctionnent pas correctement avec le noyau 2.4.21-63 du fait d'une 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 : 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 de ce noyau ; les modules résultant devraient fonctionner avec le noyau actif.

  • Les systèmes d'exploitation clients Windows affichent un statut de carte NIC incorrect après une mise à niveau du matériel virtuel
    Lorsque vous mettez à niveau l'hôte ESX d'ESX 3.5 vers ESX 4.1 et la version de matériel ESX de la version 4 vers la version 7 sur les systèmes d'exploitation clients Windows, le statut de la carte NIC s'affiche sous la forme
    This hardware device is not connected to the computer (Code 45).

    Solution : désinstallez puis réinstallez la carte réseau. Désinstaller également les cartes réseau correspondantes qui sont affichées comme fantômedans le Gestionnaire de périphériques en suivant les étapes mentionnées dans : http://support.microsoft.com/kb/315539.

Haut de la page