Mise à jour ESX 4.1 Update 2 | 27 OCT 2011 | Build 502767
VMware Tools | 27 OCT 2011 | Build 493255

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

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

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

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

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

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

Haut de la page

Versions antérieures d'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.1 ajoute le support des versions ESX 4.1 Update 2 et vCenter Server 4.1 Update 2. Pour de plus amples informations sur VDDK, voir https://www.vmware.com/support/developer/vddk/.

Compatibilité matérielle

  • En savoir plus sur la compatibilité matérielle

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

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

  • En savoir plus sur la compatibilité vSphere :

    Matrices de compatibilité VMware vSphere ( PDF)

Installation et mise à niveau

Lisez le Guide 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://downloads.vmware.com/fr/d/.

Mise à niveau de VMware Tools

VMware ESX 4.1 Update 2 contient la dernière version de VMware Tools. VMware Tools est une suite d'utilitaires qui améliore les performances du système d'exploitation client de la 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 2

ESX 4.1 Update 2 offre les options suivantes de mise à niveau :

  • VMware vCenter Update Manager . Le module vSphere prend en charge les mises à niveau directes d'ESX 3.5 Update 5a, ESX 4.0.x et ESX 4.1 et ESX 4.1 Update 1 vers ESX 4.1 Update 2. 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 et ESX 4.1 Update 1 vers ESX 4.1 Update 2. Cet utilitaire nécessite l'interface de ligne de commande 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 et ESX 4.1 Update 1 vers ESX 4.1 Update 2. 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. 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 2 :

Type de mise à niveau

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

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

ESX-4.1.0-update02-rc-463540.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-update02-463540.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-update02-463540.zip) si vous utilisez l'utilitaire vihostupdateou esxupdatepour effectuer une mise à niveau.

Non

Oui

Non

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

Remarques :

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 publication des correctifs logiciels ESX410-Update02 contient les bulletins suivants :

ESX410-201110201-SG : Mises à jour des composants ESX 4.1 Core et CIM
ESX410-201110202-SG : Mises à jour du client ESX 4.1 Openldap
ESX410-201110203-UG : Mises à jour du pilote de périphérique ESX 4.1 bnx2x
ESX410-201110204-SG : Mises à jour du composant ESX 4.1 Openssl
ESX410-201110205-UG : Mises à jour du pilote ESX 4.1 bnx2
ESX410-201110206-SG : Mises à jour du rpm ESX 4.1 libuser
ESX410-201110207-SG : Mises à jour du rpm ESX 4.1 pam
ESX410-201110208-UG : Mises à jour du rpm ESX 4.1 parted
ESX410-201110209-UG : Mises à jour du composant ESX 4.1 vaai
ESX410-201110210-SG : Mises à jour d'ESX 4.1 qlogic-fchba-provider
ESX410-201110211-UG : Mises à jour des pilotes ESX 4.1 sata-ahci
ESX410-201110212-UG : Mises à jour du pilote ESX 4.1 scsi-aic79xx
ESX410-201110213-UG : Mises à jour du pilote ESX 4.1 Megaraid SAS
ESX410-201110214-SG : Mises à jour des bibliothèques ESX 4.1 nss et nspr
ESX410-201110215-UG : Mises à jour du pilote de réseau ESX 4.1 tg3
ESX410-201110216-UG : Mises à jour du pilote de réseau ESX 4.1 igb
ESX410-201110217-UG : Mises à jour du pilote ESX 4.1scsi-qla2xxx
ESX410-201110218-UG : Mises à jour des composants ESX 4.1 webCenter
ESX410-201110218-UG : Mises à jour du rpm ESX 4.1 tzadata
ESX410-201110221-UG : Mises à jour du package ESX 4.1 esxupdate
ESX410-201110222-UG : Mises à jour du composant ESX 4.1 dhcp-cos
ESX410-201110223-UG : Mises à jour du pilote de périphérique ESX 4.1 nx-nic
ESX410-201110224-SG : Mises à jour du pilote de périphérique ESX 4.1 mptsas

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

Composants ESX410-201101201-SG Updates ESX 4.1 Core et CIM, krb5, openldap et pam-krb5
ESX410-201101202-UG Updates ESX 4.1 VMware-webCenter-esx
ESX410-201101203-UG Updates ESX 4.1 vmware-esx-esxupdate
Pilote de périphérique ESX410-201101204-UG Updates ESX 4.1 mptsas
ESX410-201101206-UG Updates ESX 4.1 bnx2xi device driver
Pilote de périphérique ESX410-201101207-UG Updates ESX 4.1 bnx2x
Pilote de périphérique sata ESX410-201101208-UG Updates ESX 4.1
ESX410-201101211-UG Updates ESX 4.1 VMware-esx-remove-rpms
ESX410-201101213-UG Updates vmware-esx-drivers-net-enic
ESX410-201101214-UG Updates vmware-esx-drivers-scsi-qla4xxx
ESX410-201101215-UG Updates ESX 4.1 vmware-esx-net-nx-nic
ESX410-201101216-UG Updates ESX 4.1 vmware-esx-vaai
ESX410-201101217-UG Updates vmware-esx-drivers-net-e1000e
Pilote ESX410-201101218-UG Updates net-cdc-ether, net-usbnet
ESX410-201101219-UG Updates vmware-esx-drivers-net-e1000
ESX410-201101220-UG Updates net-igb, net-tg3, scsi-fnic
Contrôleurs SAS HP ESX410-201101221-UG Updates ESX 4.1
Pilotes de périphérique ESX410-201101222-UG Updates mptsas, mptspi
Bibliothèque ESX410-201101225-UG Updates vmware-esx-pam-config
Packages ESX410-201101226-SG Updates glibc

Voir la documentation listée dans la page de téléchargement pour plus d'informations sur le contenu de chaque correctif.

Résolution des problèmes

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

Les problèmes résolus déjà documentés comme des problèmes connus sont marqués du symbole â€.

Sauvegarde

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

  • Lors de la prise de snapshot, la machine virtuelle peut se mettre hors tension soudainement si vous exécutez simultanément une autre tâche, telle que consulter une banque de données. Des messages d'erreur similaires aux messages suivants sont consignés dans vmware.log :
    vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file
    vmx| Msg_Post: Error
    vmx| [msg.checkpoint.continuesync.fail] Error encountered while restarting virtual machine after taking snapshot. The virtual machine will be powered off.

    Cette erreur se produit lorsqu'un autre processus accède au même fichier nécessaire à la machine virtuelle pour une opération.
    Ce problème est résolu dans cette version.

CIM et API

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

  • Lorsque vous déconnectez un câble de stockage d'ESX 4.0, accédez à la banque de données créée sur le SAN FC en utilisant MOB (Managed Object Browser) et appelez la méthode RefreshDatastore sur la référence MoRef (Managed Object Reference) de la banque de données inactive. L'API RefreshDatastore n'affiche pas d'erreur.
    Ce problème est résolu dans cette version.
  • L'hôte ESX indique que le type de mémoire est inconnu

  • Si vous vérifiez l'état du matériel
    (Accueil>Inventaire>hôtes et clusters>État du matériel>CPU/mémoire)
    d'un hôte ESXi sur le serveur HP DL980 G7 connecté via Center 4.1, le type de mémoire est indiqué comme étant inconnu. Cette erreur se produit, car le modèle CIM (Common Interface Model) ne prend pas en charge le type de mémoire DDR3.
    Ce problème est résolu dans cette version.
  • L'installation d'ESXi 4.1 Update 1 embedded et le redémarrage du système provoquent le vidage du cœur de world utilisateur

  • Après avoir installé ESXi 4.1 Update 1 et exécuté un redémarrage, un vidage de cœur de world utilisateur est généré et le message d'erreur suivant s'affiche sur l'écran de la console (Alt-F11) :
    CoreDump: 1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003.
    Le qlogic-fchba-provider-410.1.3.5-260247 (version 1.3.5) in esx41u2fourni avec ESXi 4.1 Update 2 résout ce problème.
  • Le serveur CIM envoie des alertes non valides à IBM Systems Director
    Le processus serveur CIM (sfcbd) sur l'hôte ESX peut envoyer, au logiciel IBM Systems Director software, des alertes OMC_IpmiAlertIndication non valides associées à l'absence de CPU. Cette erreur se produit dans les serveurs lames tels que IBM LS22 7901-AC1.

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

Système d'exploitation client

  • vMotion échoue par intermittence avec un message de délai d'expiration
    vMotion échoue par intermittence avec un message de dépassement de délai d'attente et consigne le message d'erreur suivant dans le fichier journal hostd :
    error -1: Failed to launch virtual machine process. Failed to launch peer process.
    Ce message est consigné, car l'appel de résolution de nom est exécuté avant l'installation des gestionnaires de signaux.

    Ce problème est résolu dans cette version. Le correctif exécute le même appel de résolution de nom après l'installation des gestionnaires de signaux.

  • La fonction de connexion à chaud de la mémoire ne fonctionne pas sur les systèmes d'exploitation client 32 bits SLES 11
    Cette fonction n'est pas compatible avec ces systèmes d'exploitation. L'option de connexion à chaud de mémoire/CPU dans Éditer les paramètres > Options est désactivée dans cette version.

Divers

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

    Ce problème est résolu dans cette version en ajoutant un nouveau paramètre plugins.vimsvc.shellAccessForAllUsersà vSphere Client. Vous pouvez désormais activer l'authentification d'utilisateur non local en affectant à plugins.vimsvc.shellAccessForAllUsersla valeur trueet en se reconnectant à vCenter Server.
  • Déséquilibre NUMA après une opération vMotion des machines virtuelles (KB 2000740)
  • Ajoute un avertissement de déséquilibre de mémoire pour les hôtes ESX sur lesquels des nœuds NUMA sont activés
    Les performances des hôtes ESX sur lesquels des nœuds NUMA sont activés peuvent être affectées si la mémoire associée à l'un des nœuds NUMA est plus de 30 % supérieure à celle des autres nœuds. Désormais, l'avertissement suivant s'affiche si un déséquilibre de mémoire se produit sur un hôte ESX :

    A significant memory (DRAM) imbalance (more than 30 percent) was detected between NUMA nodes x(a MB) and y(b MB). This may impact performance.
  • Lorsque vous réinitialisez une machine virtuelle Windows 2003 Service Pack 2 R2 en utilisant vSphere 4.1, la machine virtuelle échoue avec un écran bleu

  • Dans vSphere 4.1 Client, si vous sélectionnez l'option Redémarrer le Client pour une machine virtuelle à multitraitement symétrique avec Windows 2003 Service Pack 2 R2 exécutée dans un noyau monoprocesseur, la machine virtuelle échoue avec un écran bleu.
    Ce problème est résolu dans cette version.
  • Les longs messages syslog sont tronqués sur les hôtes ESXi
    Sur les hôtes ESXi, les messages de journal plus longs de 2 048 octets environ peuvent ne pas être écrits dans /var/log/messages.

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

  • Lorsqu'il est connecté à l'hôte ESX via vCenter 4.1 ou vSphere 4.1, le navigateur de banque de données affiche des valeurs incorrectes pour les liens symboliques et le volume NFS.
    Le chemin des liens symboliques n'est plus standardisé et cela élimine l'erreur.
  • L'hôte ESX échoue avec un écran de diagnostic violet lorsque vous exécutez 'less /proc/scsi/*/*'depuis la console de service

  • Lorsque vous exécutez `less /proc/scsi/*/*` depuis la console, certains pilotes SCSI sont portés depuis Linux. Ces pilotes fournissent des entrées sous /proc/scsi/et écrivent plus de caractères que n'en a demandé le noyau, ce qui endommage la mémoire. Dans ce cas, l'hôte ESX échoue avec un écran de diagnostic violet.
    Ce problème est résolu dans cette version.
  • Les messages dans les fichiers vpxalogsont répartis sur plusieurs lignes

  • Dans ESXi 4.1, le serveur Syslog ne peut pas traiter automatiquement les messages Syslog vpxa, car les messages sont répartis sur plusieurs lignes.
    Ce problème est résolu dans cette version.
  • vSphere Client n'affiche pas de message d'alerte si Syslog n'est pas configuré

  • Si les informations de configuration ne sont pas trouvées lors du chargement du fichier syslog.conf, aucun message d'alerte associé aux problèmes de configuration ne s'affiche dans l'onglet du résumé de vSphere Client.
    Ce problème est résolu dans cette version. Désormais, le message suivant s'affiche dans l'onglet de résumé de vSphere si Syslog n'est pas configuré :
    Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
  • Lorsqu'un contrôleur prend le contrôle d'un autre contrôleur, les banques de données qui se trouvent dans les LUN du contrôleur contrôlé peuvent devenir inactives

  • Dans ce cas, ces banques de données restent inactives jusqu'à ce que vous exécutiez une nouvelle analyse manuellement.
    Ce problème est résolu dans cette version. Aucune analyse manuelle des banques de données n'est nécessaire lorsque les contrôleurs changent.
  • Dans ESXi 4.1, le processus hostd peut échouer fréquemment
    Les objets partagés entre le filtre de tâche et d'internationalisation provoquent l'échec fréquent du processus hostd.

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

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

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

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


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

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


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

Mise en réseau

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

  • La tentative de suppression de vNetwork Distributed Switch de la section de configuration génère le message d'erreur
    Call "HostNetworkSystem.UpdateNetworkConfig" for object "networkSystem-3739" on vCenter Server "loganvc29.eng.vmware.com" failed.
    Operation failed, diagnostics report: DVS DvsPortset-0 has 1 shadow or zombie port.

    Ce problème est résolu dans cette version.
  • Le premier paquet qu'envoie la vNIC e1000 a une adresse MAC non valide

  • Les derniers pilotes du système d'exploitation client écrivent des zéro dans RAL/RAH avant de définir une adresse MAC valide. Par conséquent, le premier paquet qu'envoie la vNIC e1000 a l'adresse MAC suivante : 00:00:00:xx:xx:xx.
    Ce problème est résolu dans cette version. La vNIC e1000 envoie un paquet uniquement lorsqu'une adresse MAC valide (RAL différent de zéro) est définie.
  • L'hôte ESXi configuré avec vNetwork Distributed Switch (vDS) se déconnecte de vCenter Server et ne se reconnecte pas, même après plusieurs tentatives

  • Le verrou global portset est présent pour l'activation de port, mais pas pour la désactivation de port. Lorsque la désactivation de port modifie les propriétés vDS, elle entre en conflit avec les autres états de port qui modifient les propriétés vDS. Du fait du conflit, la connexion réseau est perdue et l'hôte ESXi se déconnecte de vCenter Server. En outre, un message de dépassement de limiteapparaît dans le journal VMkernel.
    Ce problème est résolu dans cette version. Le correctif ajoute un verrou global portset pour la désactivation de port.
  • La connectivité réseau peut échouer lorsque des VLAN sont configurés avec des cartes NIC physiques utilisant le pilote be2net ou ixgbe
    Dans vNetwork Distributed Switch, lorsque vous configurez un seul VLAN ou une plage d'ID VLAN pour des groupes de ports dvUplink, la connectivité réseau peut échouer pour le VLAN unique ou le VLAN affecté à l'ID VLAN le plus élevé de la plage d'ID VLAN si vous avez installé le pilote be2net ou ixgbe pour une carte NIC physique.

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

Sécurité

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

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

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

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

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

  • Lorsque vous exécutez une migration à froid entre deux hôtes ESX 4.1 situés dans des clusters différents, la migration échoue.
    L'activation de VCB dans le pare-feu ESX résout ce problème.
  • Met à jour les packages openssl
     
    Résumé du bogue : Dans cette version, les packages openssl sont mis à niveau de openssl098e vers openssl-0.9.8e.12.el5_5.7, ce qui résout deux problèmes de sécurité. Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a nommé ces problèmes CVE-2008-7270 et CVE-2010-4180.
  • Met à jour les bibliothèques NSS et NSPR
     
    Dans cette version, le texte de licence dans les fichiers source des bibliothèques Network Security Services (NSS) et Netscape Portable Runtime (NSPR) est mis à jour pour distribuer ces packages selon les conditions LGPL (Lesser General Public License) 2.1 et non pas MPL (Mozilla Public License). En outre, NSS et NSPR sont à jour avec nspr-4.8.6-1 et nss-3.12.8-4 pour résoudre plusieurs problèmes de sécurité.

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

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

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

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

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

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

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

Configuration des serveurs

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

  • Le service Syslog ne démarre pas s'il est configuré pour se connecter à un hôte distant qui ne peut pas être résolu via DNS lorsque le démon syslogdest démarré. Cette situation provoque l'échec des processus de journalisation distante et locale.
    Ce problème est résolu dans cette version. Désormais, si l'hôte distant ne peut pas être résolu, la journalisation locale est affectée. Lorsque le démon syslogddémarre, il tente de résoudre l'hôte distant et de s'y connecter toutes les 10 minutes.
  • Dans ESXi, les modifications apportées au fichier /etc/pam.d/system-authpour éditer les paramètres de mot de passe ne persistent pas au cours des redémarrages du système.
    Les utilisateurs ne peuvent pas modifier le fichier /etc/pam.d/system-auth. Par conséquent les modifications apportées au fichier /etc/pam.d/system-authne persistent pas au cours des redémarrages du système. Maintenant, vous pouvez éditer les paramètres de mot de passe en modifiant le fichier /etc/pam.d/passwd.

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

Stockage

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

  • Le basculement avec l'adaptateur HBA FalconStor arrête tous les chemins lorsque l'un des contrôleurs IPStor est mis hors tension. Qlogic a publié un pilote mis à jour qui résout le problème d'usurpation d'identité WWPN. Les modules FalconStor utilisent cette méthode pour gérer le basculement.
    Ce problème est résolu dans cette version.
  • L'hôte ESX/ESXi ne détecte pas les fonctions iSCSI de l'adaptateur NC382i après une mise à niveau

  • Si vous ne configurez pas swiscsi en utilisant l'adaptateur dépendant Broadcom et mettez à niveau ESX/ESXi de la version 4.0 vers la version 4.1, l'hôte ESX/ESXi ne détecte pas les fonctions iSCSI de l'adaptateur NC382i.
    Ce problème est résolu dans cette version.
  • Lorsque vous redémarrez un commutateur Fibre Channel dans l'hôte ESX/ESXi, l'état de la liaison du commutateur n'est pas restauré

  • Lorsque vous forcez l'adaptateur HBA Qlogic ISP2532 à fonctionner en mode 4 Go et redémarrez le commutateur Fibre Channel, l'état de la liaison du commutateur Fibre Channel n'est pas restauré.
    Ce problème est résolu dans cette version.
  • Les informations cible pour les numéros d'unité logiques (LUN) Fiber Channel d'un module 3par connecté à l'hôte ESX ne s'affichent pas dans vSphere

  • Lorsque vous affichez les informations multichemins depuis Vmware Infrastructure Client connecté à l'hôte ESX ou vCenter Server, les informations cible de certains chemins des LUN actifs peuvent ne pas apparaître.
    Remplacez les valeurs vides des numéros de port par les nouvelles informations de chemin pour résoudre le problème.
  • Dans ESX/ESXi, les machines virtuelles ne peuvent pas détecter les fichiers de mappage de périphérique brut qui résident dans la baie de stockage Dell MD36xxi

  • Les machines virtuelles ne peuvent pas détecter les fichiers de mappage de périphérique brut qui résident dans la baie de stockage Dell MD36xxi si cette dernière n'est pas ajoutée à l'ensemble de règles de réclamation.
    Ce problème est résolu dans cette version. Le correctif ajoute les baies de stockage DELL MD36xxi, MD3600f et MD3620f à l'ensemble de règles de réclamation du plug-in SATP (Storage Array Type Plug-in) du plug-in NMP (Native Multipathing Plug-in). En outre, ces baies de stockage sont gérées par VMW_SATP_LSI SATP. Pour plus d'informations, voir KB 1037925.
  • Les snapshots des volumes VMFS mis à niveau ne se montent pas sur les hôtes ESX 4.x
    Les snapshots des volumes VMFS3 mis à niveau depuis VMFS2 avec une taille de bloc supérieure à 1 Mo peuvent ne pas se monter sur les hôtes ESX 4.x. La commande esxcfg-volume -ld'énumération des volumes de snapshots VMFS détectés échouent avec le message d'erreur suivant :

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


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

  • Lors du traitement des données des rapports, la fonction de découverte des LUN ne détermine pas si le nombre de LUN signalés est supérieur au nombre maximal de LUN pris en charge. Par conséquent, les hôtes ESX avec le pilote intégré QLogic Fibre Channel peut subir une exception 14 et échouer avec un écran de diagnostic violet.
    Ce problème est résolu dans cette version. La fonction de découverte des LUN détermine désormais si le nombre de LUN est supérieur au nombre maximal de LUN pris en charge (256).
  • Le paramètre d'utilisation de chemins non optimisés actifs (useANO) des périphériques ne persiste pas au cours des redémarrages du système

  • Pour les périphériques qui utilisent la règle de sélection de chemin circulaire du plug-in NMP (Native Multipathing Plug-in), la valeur FALSE du paramètre useANO est rétablie après un redémarrage du système si vous la remplacez par TRUE.
    Ce problème est résolu dans cette version. Le paramètre useANO persiste après le redémarrage du système.
  • ESXi 4.1 consigne en continu des messages d'erreur internes SATA sur un système Dell PowerEdge

  • Sur un système Dell PowerEdge R815 ou R715 qui utilise le contrôleur SATA SB600, SB700 ou SB800, ESXi 4.1 consigne en continu des messages d'erreur internes SATA similaires aux messages suivants dans le fichier /var/log/messages.
    cpu2:4802)<6>ata1:soft resetting port
    cpu1:4802)<6>ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
    cpu0:4802)<6>ata1.00: configured for UDMA/100
    cpu0:4802)<6>ata1: EH complete
    cpu0:4802)<3>ata1.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
    cpu0:4802)<3>ata1.00: (irq_stat 0x40000001)
    cpu0:4802)<3>ata1.00: tag 0 cmd 0xa0 Emask 0x40 stat 0x51 err 0x24 (internal error)

    Si le support n'est pas prêt ou s'il est absent dans le lecteur de CD-ROM SATA, une erreur interne appelle le gestionnaire des interruptions, ce qui accroît le volume des données de journalisation.
    Ce problème est résolu dans cette version.
  • L'hôte ESX connecté à une unité de bande qui fait l'objet d'un accès en utilisant le pilote aic79xx échoue
    Un hôte ESX connecté à une unité de bande qui fait l'objet d'un accès en utilisant le pilote aic79xxAn peut échouer avec un écran d'erreur violet et afficher un message d'erreur similaire au message suivant lorsque le pilote tente d'accéder à une zone de mémoire libérée :

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

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

  • Dans un LUN ayant plusieurs connexions à un hôte ESX, le chemin de connexion de l'hôte et du stockage ESX devient inactif et le reste, même après la reconnexion du câble. Une actualisation ou une recherche ne met pas à jour l'état du chemin. Seul un redémarrage activera la connexion.
    Ce problème est résolu dans cette version.

Matériel pris en charge

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

  • Lorsque vous connectez un périphérique USB MAI KEYLOK II à un hôte ESX dans un système d'exploitation CentOS 5.5, RHEL 5.4, Ubuntu 9.10 ou Ubuntu10.04, les machines virtuelles Linux présentent dans le système d'exploitation client ne peuvent pas y accéder. Le périphérique est visible dans le système d'exploitation client, mais les machines virtuelles Linux ne peuvent pas l'utiliser.
    Ce problème est résolu dans cette version.

Mise à niveau et installation

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

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

  • Dès la fin de la mise à niveau ESX de la version 3.5 vers la version 4.1, l'utilisation CPU dans la machine virtuelle Netware 5.1 Service Pack 8 augmente de plus de 50 %.
    Ce problème est résolu dans cette version.
  • Le pilote Megaraid_sas a été mis à niveau de 4.0.14.1-18 vers 5.30

  • Le pilote megaraid_sas a été mis à jour de la version 4.0.14.1-18 vers la version 5.30. La mise à niveau ajoute 11 nouveaux ID PCI au pilote megaraid_sas. La mise à niveau résout les problèmes des puces iMR et gen2.
    Ce problème est résolu dans cette version.
  • L'installation ESX 4.1 échoue sur un serveur lame Hitachi BS320 AC51A3 avec le contrôleur LSI SAS Mezzanine (LSI 1064E)
    Le problème est provoqué par une fonction expérimentale, une analyse de bus série FireWire, introduite dans ESX 4.1. Voir https://www.vmware.com/fr/support/policies/experimental.html pour la position officielle de VMware sur les fonctions expérimentales dans nos produits.

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

Gestion des VM

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

  • Lorsque vous naviguez sur l'hôte ESX 3.5/4.0 via le navigateur MOB (Managed Object Browser), (Content > ha-folder-root > ha-datacenter > ha-folder-vm > Click particular VM value -> summary -> config) au lieu de le connecter à vCenter Server, la valeur de réservation de CPU [virtualMachineConfigSummary.cpuReservation]
    et la valeur de réservation de la mémoire [virtualMachineConfigSummary.memoryReservation]de la machine virtuelle sont signalées comme étant indéfinies.
    Pour résoudre ce problème, extrayez les informations de réservation d'un fichier de configuration.
  • Après la mise à niveau d'ESX 4.0 vers ESX 4.0 update 1, un seul port sur une carte PCI série multiport fonctionne
    Lorsque vous mettez à niveau un hôte ESX d'ESX 4.0 vers ESX 4.0 update 1, un seul port de la carte série fonctionne, même si tous les ports de la carte série fonctionnaient correctement avant la mise à niveau. Lorsque vous mettez sous tension la machine virtuelle, le message d'erreur suivant peut apparaître sur la console :
    "serial0: The "/dev/ttyS1" file does not appear to be a serial port: Input/output error. Virtual device serial0 will start disconnected."

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

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

  • Dans vCenter, créez une machine virtuelle Windows 2000 Professionnel. En utilisant vCenter, clonez la machine virtuelle et vérifiez le fichier vmx de la nouvelle machine virtuelle. Le système d'exploitation client indiqué est Windows 2000 alors que la machine virtuelle clonée doit afficher Windows 2000 Professionnel.

    Ce problème est résolu dans cette version. Le correctif change les entrées des systèmes d'exploitation.
    .
  • Dans ESX/ESXi 4.0, la propriété de statistique de performance maxSample dans PerfQuerySpec affiche une valeur erronée

  • Lorsque vous interrogez les statistiques de performance, la propriété maxSample dans PerfQuerySpec retourne deux valeurs et non pas une. Cette erreur se produit, même après avoir défini la propriété maxSample pour qu'elle retourne une seule valeur. Ce problème est résolu dans cette version. La propriété maxSample affiche désormais la valeur correcte.
  • vSphere Client affiche un espace provisionné incorrect pour une machine virtuelle hors tension

  • L'hôte ESX ne tient pas compte de la réservation de mémoire lors du calcul de l'espace provisionné pour une machine virtuelle hors tension. Par conséquent, vSphere Client peut afficher des valeurs différentes pour l'espace provisionné lorsque la machine est mise sous tension ou hors tension.
    Ce problème est résolu dans cette version.
  • La suppression d'un snapshot provoque l'échec de l'agent de gestion VMware hostd
    Si vous supprimez un snapshot de machine virtuelle, l'agent de gestion VMware hostd peut échouer et afficher un suivi arrière de type :

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


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

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

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

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

vMotion et Storage vMotion

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

  • Lorsque vous exécutez vMotion sur plusieurs machines virtuelles sur deux hôtes ESX, la mémoire sur l'un des hôtes ESX est surchargée et l'allocation de page échoue. Cette situation génère un débordement de journal avec l'avertissement suivant :
    WARNING: vmklinux26: AllocPages: gfp_mask=0xd4, order=0x0, vmk_PktSlabAllocPage returned 'Out of memory' in the vmkernel log during vMotion
    Ce problème est résolu dans cette version.
  • Si vous tentez de placer HA (High Availability) et DRS (Distributed Resource Scheduler) en mode de maintenance ou d'exécuter une opération vMotion, vMotion échoue avec le message d'erreur Out of Memory.
    Lorsque vous exécutez simultanément des opérations vmotions ou placez un hôte 4.1 en mode de maintenance, qui fait partie d'un cluster DRS utilisant vCenter 4.1 ou vSphere 4.1, l'évacuation des machines virtuelles échoue avec les messages d'erreur suivants :

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

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

  • Une opération vMotion peut échouer avec des messages d'erreur indiquant que des fichiers d'échange sont verrouillés dans le répertoire workingdir sous la banque de données NAS.
    Ce problème est résolu dans cette version. Le correctif dans ESX 4.1 Update 2 appelle FSS_OpenFilePath à la place de FSS_OpenFile et fait aboutir l'opération vMotion.

VMware Tools

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

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

  • Sur une machine virtuelle Windows 2008 R2, lorsque vous ajoutez un disque dynamique et prenez un snapshot mis au repos, le gestionnaire de disque affiche un disque défaillant ou un message indiquant que le disque manque. Ce problème concerne les systèmes d'exploitation Windows suivants.
    Ce problème est résolu dans cette version.
  • Le fournisseur HGFS Windows provoque un blocage si une application appelle simultanément l'API WNetAddConnection2depuis plusieurs unités d'exécution

  • Le fournisseur Windows HGFS Dll provoque un blocage pour les applications, telles que eEye Retina, du fait de la mise en œuvre de fournisseur incorrecte de l'API Windows WNetAddConnection2ou WNetCancelConnectiondans un environnement à unités d'exécution multiples.
    Ce problème est résolu dans cette version.
  • Impossible d'utiliser la carte NIC (network interface card) VMXNET après l'installation de VMware Tools dans RHEL3 avec le dernier noyau dans ESX 4.1 U1

  • Certains pilotes dans VMware Tools prédéfini avec des modules RHEL 3.9 ne fonctionnent pas correctement avec le noyau 2.4.21-63 du fait de l'incompatibilité ABI (application binary interfaces). Par conséquent, certains pilotes de périphérique, tels que vmxnetet vsocket, ne se chargent pas lorsque vous installez 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 vmware-config-tools.pl et compilez. Vous compilez ainsi le module pour ce noyau ; les modules résultant devraient fonctionner avec le noyau actif.
  • Les systèmes d'exploitation clients Windows affichent un état de carte NIC incorrect après une mise à niveau de matériel virtuel

  • Lorsque vous mettez à niveau un hôte ESX d'ESX 3.5 vers ESX 4.1 et la version matérielle de l'hôte ESX de la version 4 vers la version 7 sur les systèmes d'exploitation clients Windows, l'état de la carte NIC s'affiche sous la forme
    “This hardware device is not connected to the computer (Code 45)”.
    Solution
    Désinstallez la carte NIC et réinstallez-la pour résoudre le problème.
    Ce problème est résolu dans cette version.
  • Installation de VMware Tools sur une machine virtuelle RHEL 2.1 échoue avec un message d'erreur

  • Lorsque vous tentez d'installer VMware Tools sur une machine virtuelle RHEL 2.1 exécutée sur ESX 4.1 en exécutant le script vmware-install.pl, le processus d'installation échoue avec le message d'erreur
    Creating a new initrd boot image for the kernel. Error opening /tmp/vmware-fonts2/system_fonts.conf Execution aborted.
    Ce problème est résolu dans cette version.
  • Des erreurs étranges s'affichent lors du redémarrage des machines virtuelles Linux après l'installation de VMware Tools
    Après avoir installé VMware Tools pour Linux, lorsque vous redémarrez le système d'exploitation client, le gestionnaire de périphériques du noyau Linux (udev) peut générer des erreurs étranges de ce type :

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


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

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

  • Par défaut, le service CUPS sur une machine virtuelle est désactivé. Toutefois, lorsque vous démarrez la mise à niveau de VMware Tools dans un système d'exploitation client SUSE Linux Enterprise Server 10 Service Pack 3 x86, le service CUPS démarre automatiquement. Désactivez le service CUPS dans SUSE Linux Enterprise 10 et Red Hat Enterprise Linux 5 en utilisant les commandes suivantes :
  • Sur SUSE Linux Enterprise 10
  • Exécutez
    chkconfig --level 2345 cups off
    chkconfig --level 2345 cupsrenice off
    et désactivez le service CUPS.
    Vérifiez l'état du service en utilisant la commande
    service cups status
    chkconfig -l|grep -i cups

    et vérifiez que le service est désactivé.
  • Sur Red Hat Enterprise Linux 5
  • Exécutez
    chkconfig --level 2345 cups off
    system-config-services.
    Ce problème est résolu dans cette version.
  • Le socket VMCI (Virtual Machine Communication Interface) sur le système d'exploitation client Linux ne répond plus lorsqu'une paire de files d'attente est détachée.
    • La machine virtuelle est indisponible.
    • Un échec d'invalidation busmem est signalé par le système d'exploitation client.

  • Si un homologue d'une connexion de socket de flux VMCI (par exemple, un serveur de socket de flux exécuté dans une machine virtuelle de serveur) se détache d'une paire de files d'attente lorsque l'état de connexion est En cours de connexion, l'autre paire (par exemple, un client de socket de flux avec une connexion bloquante) peut ne pas pouvoir se connecter.
    Le détachement de l'homologue a lieu si l'un des événements suivants se produit :
    Ce problème est résolu dans cette version. Le correctif dans ESX 4.1 Update 2 traite le détachement de l'homologue et propage le message d'erreur suivant à l'autre homologue :
    Connection reset by peer
  • Les modules de noyau de VMware Tools ne se chargent pas lors du changement de noyau
    Lorsque vous installez VMware Tools et changez de noyaux, les modules vsock et vmmemctl ne se chargent pas lors du démarrage. Le message d'erreur suivant apparaît lorsque vous exécutez une commande dmesg ou tentez de charger manuellement les modules du noyau incorrect :

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

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

  • Dans Windows, VirtualAlloc peut être forcé à allouer de la mémoire de haut en bas en utilisant la clé de registre AllocationPreference, comme indiqué dans le lien suivant : http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx.
    Sur ces machines virtuelles, le service VMware Tools échoue.
    Ce problème est résolu dans cette version.
  • Le service VMware Tools (vmtoolsd) peut échouer après avoir installé VMware Tools sur un client Linux avec un nom de système d'exploitation long

  • Si un système d'exploitation client Linux signale un nom de système d'exploitation complet de plus de 100 caractères, le service peut échouer. Pour plus d'informations, voir KB 1034633.
    Ce problème est résolu dans cette version. Le correctif augmente la taille maximale autorisée à 255 caractères pour le nom de système d'exploitation.
  • La configuration X11 est modifiée après l'installation de VMware Tools

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

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

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 :
    Fermeture de traitement de réponse en cours dans état inattendu :3 .Vous pouvez ignorer ce message. Ce message n'a aucune influence sur les résultats des commandes de la 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

  • 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.
  • 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 ESX 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 ESX, sélectionnez l'option Connecter à la mise sous tension dans la fenêtre Propriétés de la machine virtuelle avant de mettre sous tension la machine virtuelle.

Divers

  • L'exécution de resxtop ou esxtop pendant de longues périodes peut entraîner des problèmes de mémoire.
    L'utilisation de la mémoire par
    resxtop ou esxtop peut augmenter dans le temps en fonction de ce qui se passe sur l'hôte 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

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

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 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 le vSphere Client :
    1. Dans le panneau d'inventaire de vSphere Client, sélectionnez l'hôte, cliquez sur l'onglet Configuration, puis sur Paramètres avancés sous Software.
    2. Sélectionnez SCSI.
    3. Modifiez le paramètre Scsi.CRTimeoutDuringBootà 10 000.

Configuration des serveurs

  • La mise à niveau vers ESX 4.1 Update 1 é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 Update 1 é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 LDAO 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.
      • 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 sur le site http://kb.vmware.com/kb/1021454 pour plus d'informations sur la configuration de l'option de démarrage des hôtes 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 ESX sur les systèmes HP nécessitent le pilote HP NMI
          Les instances ESX 4.1 sur les systèmes HP nécessitent le pilote HP NMI pour assurer le bon fonctionnement des NMI. Le pilote NMI garantit que les NMI sont bien détectés et connectés. Sans ce pilote, les NMI signalant les erreurs matérielles sont ignorés par les systèmes HP exécutant ESX.
          Attention : L'échec de l'installation de ce pilote risque de provoquer une corruption des données silencieuse.

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


          Solution : mettez à niveau le microprogramme du module EqualLogic vers la version 4.1.4 ou une version ultérieure.
        • Après la mise à niveau de la baie de stockage, l'état d'accélération matérielle dans vSphere Client passe à Pris en charge après un court délai
          Lorsque vous mettez à niveau le microprogramme d'une baie de stockage vers une version prenant en charge la fonctionnalité VAAI, vSphere 4.1 n'enregistre pas immédiatement le changement. Le vSphere Client affiche temporairement Inconnu comme 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)sscsi_cmd_alloc returned NULL
          Mar 25 17:39:26 vmkernel: 0:00:08:47,632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Commande 0x28 (0x410005060600) au périphérique NMP
          "naa.600508b1001030304643453441300100" a échoué sur le chemin d'accès physique "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 Données de détection possibles : 0x
          Mar 25 17:39:26 0 0x0 0x0.
          Mar 25 17:39:26 vmkernel: 0:00:08:47 632 cpu1:4097)AVERTISSEMENT : NMP : nmp_DeviceRetryCommand: Périphérique
          "naa.600508b1001030304643453441300100": en attente de mise à jour rapide de l'état du chemin d'accès pour le basculement avec l'E/S bloqué. Aucune réservation antérieure
          n'existe sur le périphérique.
          Mar 25 17:39:26 vmkernel: 0:00:08:47.632 cpu1:4097)NMP: nmp_CompleteCommandForPath: Commande 0x28 (0x410005060700) au périphérique NMP
          a échoué "naa.600508b1001030304643453441300100" sur le chemin d'accès "vmhba0:C0:T0:L1" H:0x1 D:0x0 P:0x0 données de détection possibles : 0x
          Mar 25 17:39:26 0 0x0 0x0


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

        Mise à niveau et installation

        • La mise à 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.

        • 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 Update 1
          Lorsque vous effectuez une mise à niveau d'ESX 4.0 ou ESX 4.1 vers ESX 4.1 Update 1, 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 Update 1.

        • La sortie de la commande esxupdate - a n'affiche pas les pilotes intégrés lors de la mise à de l'hôte ESX de la version ESX 4.0 Update 2 vers ESX 4.1 Update 1
          Lorsque vous mettez à niveau l'hôte ESX d'ESX 4.0 Update 2 vers ESX 4.1 Update 1 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 Update 1.

        • La mise à niveau vers ESX 4.1 Update 1 é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 Update 1, 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 Update 1.

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

        vMotion et Storage vMotion

        • L'exécution de vicfg-snmp -r ou vicfg-snmp -D sur les systèmes ESX échouent
          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 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

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

          Solution : 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 doivent fonctionner avec le noyau actif.

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


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

        Haut de la page