Prenez le contrôle de votre environnement multicloud

ESXi 4.1 Update 3 Installable | 30 août 2012 | Build 800380 ESXi 4.1 Update 3 Embedded | 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
• Versions antérieures d'ESXi 4.1
• Avant de commencer
• Installation et mise à niveau
• Correctifs contenus dans cette version
• Résolution des problèmes
• Problèmes connus

Nouveautés

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

• 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'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 :

• ESXi 4.1 Update 2
• ESXi 4.1 Update 1
• ESXi 4.1

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.2 ajoute la prise en charge des versions ESXi 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
  
  
• En savoir plus sur la compatibilité vSphere :
  
  Matrice d'intéropérabilité des produits VMware

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.

• Le Guide de configuration de vCenter Server et ESXi Installable ou le Guide de configuration de vCenter Server et ESXi Embedded pour des informations sur l'octroi de licences
• Le Guide de configuration ESXi pour des informations sur la mise en réseau et la sécurité

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/download.

Mise à niveau de VMware Tools

VMware ESXi 4.1 Update 3 contient la version la plus récente 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 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 3

ESXi 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'ESXi 3.5 Update 5, ESXi 4.0.x, ESXi 4.1, ESXi 4.1 Update 1 et ESXi 4.1 Update 2 vers ESXi 4.1 Update 3.
• vihostupdate. Utilitaire de ligne de commande qui prend en charge les mises à niveau directes d'ESXi 4.0, ESXi 4.1 Update 1 et ESXi 4.1 Update 2 vers ESXi 4.1 Update 3. 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 3 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 3 :

Livrables de mise à jour	Outils de mise à niveau pris en charge	Chemins d'accès de mise à niveau pris en charge vers ESXi 4.1 Update 3
		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.0 Update 4	ESXi 4.1: Inclut ESXi 4.1 Update 1 ESXi 4.1 Update 2
upgrade-from-ESXi3.5-to-4.1_update03.800380.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-update03-800380.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_update03.zip	VMware vCenter Update Manager avec ligne de base de correctifs vihostupdate	Non	Non	Oui
ESXi 4.1 vers 4.1.x à l'aide des définitions de correctifs téléchargés depuis le portail VMware (en ligne)	VMware vCenter Update Manager avec ligne de base de correctifs	Non	Non	Oui

Remarques :

• Pour une mise à niveau à partir de ESXi 3.5.x Update 5, l'approche prise en charge est VMware vCenter Update Manager. Pour plus d'informations, reportez-vous au Guide de mise à niveau vSphere et au Guide d'administration VMware vCenter Update Manager.
• Pour une mise à niveau d' ESXi 4.0.x, les approches prises en charge sont VMware vCenter Update Manager et la commande vihostupdate de vSphere CLI. Pour plus d'informations, reportez-vous au Guide d'administration VMware vCenter Update Manager.
• Pour une mise à niveau d' ESXi 4.1.x, les approches prises en charge sont VMware vCenter Update Manager et la commande vihostupdate de vSphere CLI.

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 êtes invité à mettre à niveau vSphere Client vers vSphere Client 4.1 Update 3. Employez 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'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 3, 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-Update03 contient les bulletins individuels suivants :

ESXi410-201208201-UG: Mises à jour du microprogramme ESXi 4.1
ESXi410-201208202-UG : Mise à jour de ESXi 4.1 Tools

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

ESXi410-201208101-SG : Mise à jour du microprogramme ESXi 4.1 Security-only
ESXi410-201208102-SG: Mise à jour de ESXi 4.1 Tools

Résolution des problèmes

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

• CIM et API
• Système d'exploitation client
• Divers
• Mise en réseau
• Sécurité
• Stockage
• Matériel pris en charge
• vCenter Server, vSphere Client et vSphere Web Access
• Gestion des machines virtuelles
• VMware HA et Fault Tolerance
• vMotion et Storage vMotion
• VMware Tools

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 ESXi.
  
  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) ESXi 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 ESXi 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 kexec peut être utilisée pour activer un démarrage via un noyau spécial kdump et favoriser la collecte des fichiers de vidage sur incident. Pendant ce type de redémarrage, un SMP client Linux configuré avec kexec peut 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 la taille de mémoire par défaut sur certaines versions d'ESXi
  Quand vous essayez d'installer Solaris 10 sur ESXi, 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

• Sur ESXi, la valeur du délai d'attente de connexion de l'initiateur iSCSI affectée aux adaptateurs iSCSI logiciel et dépendants est insuffisante
  Lorsque vous essayez simultanément de vous connecter plusieurs fois sur un hôte ESXi, le processus de connexion échoue à cause d'une valeur de délai d'attente de connexion insuffisante.
  
  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 des systèmes de fichiers visorfs, l'hôte ESXi ne capture pas la sortie vdf de l'utilitaire vm-support
  L'option de capture de la sortie vdf n'est pas disponible dans ESXi. Sans cette option, l'utilisateur peut éventuellement ne pas être informé de l'utilisation de l'espace Ramdisk.
  
  L'inclusion de la commande vdf –h dans vm-support permet de résoudre ce problème.

• L'hôte ESXi 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 ESXi ne réponde plus en raison d'un débordement constant de messages du journal USB similaires aux messages 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 ESXi à 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 de machines virtuelles ne fonctionnent pas correctement lorsque la limite est supérieure à 2048 Mbit/s
  Sur un hôte ESXi, si vous configurez Network I/O Control (NetIOC) pour définir la Limite d'hôte pour le Trafic de machine virtuelle avec une valeur supérieure à 2048 Mbit/s, la limite de bande passante n'est pas appliquée.
  
  Ce problème est résolu dans cette version.

• L'hôte ESXi échoue avec un écran violet après l'échec d'une opération vMotion
  Un hôte ESXi peut échouer avec un écran de diagnostic violet affichant une erreur de type Exception 14 aprè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 ESXi, l'hôte échoue avec un écran violet
  Sous ESXi, lorsque vous utilisez vmxnet3 comme vNIC dans certaines machines virtuelles et désactivez la fusion de paquets, l'hôte ESXi é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 vSwitch est vide sur l'hôte ESXi
  La configuration réseau d'un hôte ESXi peut être vide sur vSphere Client. L'exécution de la commande esxcfg-vswitch -l depuis 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 ESXi engendre un message d'erreur
  La commande esxcli network connection list peut générer un message d'erreur similaire aux messages suivants lorsque l'hôte ESXi 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é

• Une mise à jour vers la bibliothèque libxml2 résout plusieurs problèmes de sécurité
  La bibliothèque libxml2 est mise à jour afin de résoudre plusieurs problèmes de sécurité dans ESXi.
  Le projet CVE (Common Vulnerabilities and Exposures, cve.mitre.org) a attribué les noms CVE-2010-4008, CVE-2011-0216, CVE-2011-1944, CVE-2011-2834, CVE-2011-3905, CVE-2011-3919 et CVE-2012-0841 à ces problèmes.

• La mise à jour vers la bibliothèque ESXi userworld OpenSSL résout plusieurs problèmes de sécurité
  La bibliothèque ESXi userworld OpenSSL est mise à jour de la version 0.9.8p vers la version 0.9.8t afin de résoudre plusieurs problèmes de sécurité.
  Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a attribué les noms suivants CVE-2010-4180 , CVE-2010-4252 , CVE-2011-0014 , CVE-2011-4108 , CVE-2011-4109 , CVE-2011-4576 , CVE-2011-4577 , CVE-2011-4619 et CVE-2012-0050 à ces problèmes.

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

Configuration des serveurs

• Un hôte ESXi sur lequel le partage de page est désactivé échoue avec un écran violet
  Si vous effectuez une opération VMotion sur un hôte ESXi sur lequel le partage de page de l'option d'heure de démarrage est désactivé, l'hôte ESXi peut échouer avec un écran violet.
  La désactivation du partage de page a une incidence importante sur les performances de l'hôte ESXi. 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 ESXi consigne un état C1E incorrect
  Le vmkernel.log et la commande dmesg peuvent afficher le message 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 ESXi ne consigne pas tous les messages d'erreur, rendant ainsi difficile la résolution des 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 ESXi 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 l'épuisement de la mémoire du segment VMFS
  Si un hôte ESXi rencontre un volume VMFS endommagé, le pilot VMFS entraîne une fuite de mémoire du pilote VMFS et un épuisement 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 ESXi 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 ESXi 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 [host name] vmkernel: 107:01:39:59.667 cpu12:21263)VSCSIFs: 329: handle 9267(vscsi0:0):Invalid Opcode (0xd1)
  Nov 22 11:55:06 [host name] 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 ESXi 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 ESXi
  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 ESXi signale par erreur que le VMFS est corrompu. L'hôte ESXi 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 ESXi ne répond plus lorsque le module VMW_SATP_LSI ne dispose plus de suffisamment 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 ESXi peut échouer avec un écran violet lors de la resignature d'un volume VMFS
  Un hôte ESXi 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 ESXi é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 ESXi 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.

• L'hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un problème rencontré dans le module VMFS.
  Un hôte ESXi 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.

• Les données du pilote Emulex LPe12000 sont corrompues pendant la gestion de l'adresse limite 4G DMA
  Dans l'hôte ESXi, lorsque le pilote Emulex LPe12000 ne peut définir la valeur dma_boundary du modèle hôte, la 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 ESXi sur le serveur IBM BladeCenter HX5 UEFI
  Lorsque vous essayez de modifier la règle d'alimentation d'un hôte ESXi qui s'exécute sur un serveur IBM BladeCenter HX5 UEFI, les paramètres de gestion de l'alimentation de vSphere Client affichent le message suivant :
  
  Technology: Not Available
  Active Policy: Not Supported.
  
  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 ESXi se déconnecte de vCenter Server
  Une erreur sfcb-vmware_base TIMEOUT peut provoquer un échec des services hostd et vpxa, ainsi qu'une déconnexion intermittente de l'hôte ESXi 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 .vmx devient 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 ESXi 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 ESXi. 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 ESXi 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 ESXi. 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/BlockGuestBPDU sur 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 ESXi peut échouer
  Sur un hôte ESXi, 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 par défaut sur ESXi 4.1 définit disk.enableUUID sur 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_MODULES dans /etc/sysconfig/kernel sont 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 ESXi 4.1 Update 1
  Sur les machines virtuelles exécutant ESXi 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.conf peuvent ê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 ESXi 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 ESXi 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
  
vsock

Haut de la page

Problèmes identifiés

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

• CIM et API
• Système d'exploitation client
• Divers
• Mise en réseau
• Stockage
• Matériel pris en charge
• Mise à niveau et installation
• vMotion et Storage vMotion
• VMware Tools

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 ESXi 4.1 Update 3
  Solution : supprimez /UserVars/CIMoemPrividerEnabled en 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 ESXi 4.1 Update 3
  Solution :
  
  1. exécutez la commande suivante pour désactiver les fournisseurs OEM :
     esxcfg-advcfg -s 0 /UserVars/CIMoem- ProviderEnabled
  2. Redémarrez le service sfcbd en 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

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

• 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 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 -n pour changer le nombre total d'itérations, il est préférable d'exécuter resxtop seulement 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-pciid pour 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 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 Embedded à une version 4.0(4) SV1(3a) de Cisco Nexus 1000V par vCenter Server.
  
  Solution
  Pour ajouter un hôte ESXi 4.1.x Embedded dans Cisco Nexus 1000V version 4.0(4) SV1(3a), utilisez l'utilitaire vihostupdate pour appliquer le bundle VEM sur les hôtes ESXi.
  Effectuez les étapes suivantes pour ajouter un hôte ESXi 4.1.x 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.x Embedded à vCenter Server.
  5. Ajoutez ESXi 4.1.x compatible AV.2 VEM bits à un hôte ESXi en exécutant la commande suivante à partir de vSphere CLI :
     vihostupdate.pl --server -i -b
     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.x a été ajouté à Cisco Nexus 1000V version 4.0(4)SV1(3a).

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, 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 ê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 du port iSCSI.
  
  
• Grand nombre de messages relatifs au stockage dans le fichier journal /var/log/messages
  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 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 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 (G7 et versions antérieures) nécessitent le pilote HP NMI pour assurer 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 ESXi.
  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.

• Certains BIOS Dell peuvent avoir des entrées de routage d'interruption en double dans la table ACPI (KB 1013804)

• 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" 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 multi-chemins d'accès d'ESXi 3.5 vers ESXi 4.0.x vers ESXi 4.1 Update 3 avec VMware vCenter Update Manager échoue
  Après une mise à niveau d'ESXi 3.5 vers ESXi 4.0.x avec VMware vCenter Update Manager, les tentatives de mise à niveau de l'installation ESXi vers ESXi 4.1 Update 3 échouent avec un message similaire au message suivant :
  
  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 3
  • ESXi 3.5 vers ESXi 4.0 Update 2 vers ESXi 4.1 Update 3
  • ESXi 3.5 vers ESXi 4.0 Update 3 vers ESXi 4.1 Update 3
  • ESXi 3.5 vers ESXi 4.0 Update 4 vers ESXi 4.1 Update 3
  • ESXi 3.5 vers ESXi 4.0 vers ESXi 4.1 Update 3
  
  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 3.
  
  
• 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 found aprè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

• 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 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 en raison 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 : 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 état de périphérique NIC incorrect après une mise à niveau du matériel virtuel
  Lorsque vous mettez à niveau un hôte ESXi d'ESXi 3.5 vers ESXi 4.1 et la version matérielle d'ESXi de la version 4 vers la version 7 sur les systèmes d'exploitation clients Windows, l'état du périphérique 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ôme dans le Gestionnaire de périphériques en suivant les étapes mentionnées dans : http://support.microsoft.com/kb/315539.
  
  
• 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érifier et mettre à niveau Tools 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