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


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

CIM et API

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


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




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


  • CoreDump: 1480:Userworld sfcb-qlgc /var/core/sfcb-qlgc-zdump.003
    qlogic-fchba-provider-410.1.3.5-260247 (version 1.3.5) in esx41u2
  • Le serveur CIM envoie des alertes non valides à IBM Systems Director
    Le processus serveur CIM (sfcbd) sur l'hôte ESX peut envoyer, 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

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

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


  • L'hôte ESX échoue avec un écran de diagnostic violet lorsque vous exécutez 'less /proc/scsi/*/*'depuis la console de service

  • `less /proc/scsi/*/*`/proc/scsi/
  • Les messages dans les fichiers vpxalogsont répartis sur plusieurs lignes

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



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


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

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

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

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

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

    Ce problème est résolu dans cette version. Désormais, vous pouvez désactiver cet avertissement en définissant le paramètre UserVars.SuppressShellWarning dans vCenter Server.
  • La machine virtuelle configurée avec le périphérique de relais fixe ne se met pas sous tension
    Une machine virtuelle configurée avec au moins 14 périphériques PCIe peut ne pas 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


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

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

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

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

Sécurité

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

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

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

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

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


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

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

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

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

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

    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a 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

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


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


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


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


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


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

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

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


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


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


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

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

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

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


Matériel pris en charge

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


Mise à niveau et installation

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

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


  • Le pilote Megaraid_sas a été mis à niveau de 4.0.14.1-18 vers 5.30


  • 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

  • [virtualMachineConfigSummary.cpuReservation]
    [virtualMachineConfigSummary.memoryReservation]

  • 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 ESX/ESXi 4.0, la propriété de statistique de performance maxSample dans PerfQuerySpec affiche une valeur erronée

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


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

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

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

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

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

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

vMotion et Storage vMotion

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


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

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

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


VMware Tools

  • L'installation de VMware Tools sur une machine virtuelle avec le système d'exploitation Windows NT 4.0 génère un message d'erreur
    La tentative d'installer VMware sur une machine virtuelle avec le système d'exploitation Windows NT 4.0 aboutit. Toutefois, vSphere Client affiche l'état VMware Tools: Out of date.
    Ce problème est résolu dans cette version.
  • La mise à niveau VMware Tool échoue, car des dossiers dans /tmpsont supprimés dans des systèmes d'exploitation 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


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

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

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


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

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

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

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

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

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


  • Sur SUSE Linux Enterprise 10

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


    service cups status
    chkconfig -l|grep -i cups

  • Sur Red Hat Enterprise Linux 5

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

  • En cours de connexion


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

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

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



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


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

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

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

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