ESX 4.1 Update 1 | 10 février 2011 | Build 348481
VMware Tools  | 10 février 2011 | Build 348481

Dernière mise à jour du document : 10 février 2011

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

Les informations suivantes présentent les points principaux de quelques unes des améliorations disponibles dans cette version de VMware ESX :

  • Prise en charge de bases de données supplémentaires pour vCenter et VMware vCenter Update Manager . vCenter 4.1 Update 1 et VMware Vcenter Update Manager 4.1 Update 1 prennent en charge l'utilisation de Microsoft SQL Server 2008 R2 et des bases de données Oracle 11 G R2.
  • Interface utilisateur pour configurer VMware Vcenter Update Manager . vSphere 4.1 Update 1 présente une nouvelle interface graphique pour la configuration post-installation de VMware vCenter Update Manager (VUM) et VMware vCenter Update Manager Download Service. Cette interface graphique peut être utilisée pour des tâches de configuration telles que la réinitialisation du mot de passe utilisé par VMware vCenter Update Manager pour s'authentifier sur sa base de données, le remplacement des certificats SSL utilisés par VMware vCenter Update Manager, le ré-enregistrement de l'extension VMware vCenter Update Manager avec vCenter et la configuration du serveur proxy et des détails d'authentification utilisés par VMware vCenter Update Manager Download Service.
  • Évolutivité améliorée . ESX 4.1 Update 1 prend en charge jusqu'à 160 processeurs logiques.
  • Amélioration des performances pour certaines bases de données et charges de travail des services de terminaux . ESX 4.1 Update 1 propose des améliorations de débit très importantes ainsi qu'une meilleure utilisation CPU et des migrations considérablement réduites pour certaines bases de données et charges de travail des services de terminaux.
  • Prise en charge de systèmes d'exploitation client supplémentaires . ESX 4.1 Update 1 ajoute la prise en charge d'Ubuntu 10.10, Solaris 10 U9 et RHEL 6. Pour une liste complète des systèmes d'exploitation client pris en charge par cette version, consultez le Guide de compatibilité VMware.

Problèmes résolus :de plus, cette version offre un certain nombre de correctifs de bogues qui ont été documentés dans la section Problèmes résolus.

Début de la page

Versions antérieures d'ESX 4.1

Les fonctions et problèmes connus de la version précédente d'ESX 4.1 sont décrits dans les notes de mise à jour. Pour afficher les notes de mise à jour de la version antérieure, cliquez sur le lien suivant :

Début de la page

Avant de commencer

Compatibilité de version ESX, vCenter Server et vSphere Client

Les Matrices de compatibilité vSphere fournissent des détails sur la compatibilité des versions actuelles et précédentes des composants de VMware vSphere, dont ESX, vCenter Server, vSphere Client et autres produits VMware.

Compatibilité ESX, vCenter Server et VDDK

Virtual Disk Development Kit (VDDK) 1.2 ajoute la prise en charge des versions ESX 4.1 Update 1 et vCenter Server 4.1 Update 1. Pour de plus amples informations sur VDDK, voir http://www.vmware.com/support/developer/vddk/.

Compatibilité matérielle

  • Pour en savoir plus sur la compatibilité matérielle

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

    Inscrivez-vous pour être prévenu des mises à jour du Guide de compatibilité via Ceci est l'image RSS qui sert de lien à 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'octroi 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.

Il se peut que les versions postérieures à VMware vSphere ne prennent pas en charge la version 2 de VMFS (VMFS2). VMware recommande la mise à niveau ou la migration vers la version 3 ou ultérieure de VMFS. Reportez-vous au Guide de mise à niveau vSphere.

Les versions postérieures à VMware vCenter Server ne prendront pas en charge une installation sur des systèmes d'exploitation Windows 32 bits. Vous ne pouvez installer vCenter Server 4.1 que sur les plateformes Windows à 64 bits. Si vous avez installé VMware VirtualCenter 2.x, voir le Guide de mise à niveau vSphere pour plus d'informations sur l'installation de vCenter Server sur un système d'exploitation à 64 bits en conservant la base de données de VirtualCenter.

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

Mise à niveau de VMware Tools

VMware ESX 4.1 Update 1 nécessite une mise à niveau de VMware Tools. VMware Tools est une suite d'utilitaires qui améliorent 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 1

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

  • VMware vCenter Update Manager . [Informations requises]
  • vihostupdate . Utilitaire de ligne de commande qui prend en charge les mises à niveau directes d'ESX 4.0 vers ESX 4.1 Update 1. Cet utilitaire nécessite vSphere CLI. Reportez-vous au Guide de mise à niveau vSphere.
  • esxupdate . Utilitaire de ligne de commande d'ESX 4.0 vers ESX 4.1 Update 1. Voir le Guide de gestion des correctifs ESX 4.1.
  • script esxupgrade.sh . Pour les hôtes ESX 3.5 n'ayant pas d'accès au réseau. Voir l' Article 1009440 de la base de connaissance. Si l'hôte a accès au réseau, vous pouvez utiliser vCenter Update Manager pour réaliser les mises à niveau. Pour les hôtes ESX 3.0.x, vous devez d'abord effectuer une mise à niveau vers ESX 4.0 ou vers une version d'ESX 4.0 Update en utilisant vSphere Host Update Utility 4.0 ou vCenter Update Manager 4.0. Vous pouvez ensuite effectuer une mise à niveau vers ESX 4.1 Update 1 en utilisant vCenter Update Manager 4.1 ou l'utilitaire esxupdate ou vihostupdate . Pour des instructions détaillées, voir le Guide de mise à niveau vSphere.

Plusieurs outils de mise à niveau qui ont été pris en charge dans les versions antérieures d'ESX ne le sont plus dans la version actuelle. Ces outils comprennent une mise à niveau graphique à partir d'un CD, une mise à niveau en mode texte à partir d'un CD, une mise à niveau tarball au moyen de la console de service, une mise à niveau en script à partir d'un CD ou du serveur PXE au moyen d' esxupdate , et une mise à niveau en script à partir d'un CD ou du serveur PXE à l'aide de commandes kickstart. VMware Update Manager est le seul outil qui soit pris en charge pour effectuer des mises à niveau d'ESX 3.5.x vers ESX 4.1.

Lorsque vous effectuez une mise à niveau d'ESX 4.0 vers ESX 4.1 Update 1 en utilisant le fichier zip de mise à niveau hors ligne, la sortie de la commande esxupdate -a queryaffiche le bulletin de cumul d'ESX 4.1 Update1 tel qu'ESX410-U01 au lieu d'ESX410-Update01. [Pour vérifier si cette information doit être ajoutée ici.]

Cette version contient des correctifs de l'outil esxupdatequi peuvent affecter la fonctionnalité d'application de correctifs ou de mise à niveau. Avant de mettre à niveau vers ESX 4.1 Update 1, installez le correctif ESX410-201101203-UG.

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

Type de mise à niveau

Outils de mise à niveau pris en charge

ESX 3.5
Update 5a

ESX 4.0

comprend :
Update 1
Update 2

ESX 4.1  

ESX-4.1.0-update01-345122.iso (hors ligne)

VUM : ligne de base de mise à niveau de l'hôte

Oui

Non

Non

Bundle hors ligne ESX 4.0-4.1 Update 1

  • Ligne de base de mise à niveau de l'hôte de VUM
  • esxupdate
  • vihostupdate
  • Installez le bulletin de pré-mise à niveau si vous envisagez d'utiliser l'utilitaire vihostupdate ou esxupdate pour télécharger le nouveau programme d'installation sur l'hôte ESX.

Non

Oui

Non

update-from-esx4.1-4.1_update01.zip (hors ligne)
  • Ligne de base des correctifs VUM –
  • esxupdate
  • vihostupdate
Non Non Oui

ESX410-Update01 (en ligne)

Ligne de base des correctifs VUM –

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 de correctifs logiciels ESX410-Update01 contient les bulletins individuels suivants : [Informations en attente]

ESX410-201101201-SG Mises à jour ESX 4.1 Composants cœur et CIM
ESX410-201101202-UG Updates ESX 4.1 VMware-webCenter-esx
ESX410-201101203-UG Mises à jour ESX 4.1 vmware-esx-esxupdate
ESX410-201101204-UG Mises à jour ESX 4.1 pilote de périphérique mptsas
ESX410-201101206-UG Mises à jour ESX 4.1 pilote périphérique bnx2xi
ESX410-201101207-UG Updates ESX 4.1 pilote périphérique bnx2x
ESX410-201101208-UG Mises à jour ESX 4.1 pilote périphérique sata
ESX410-201101211-UG Updates ESX 4.1 VMware-esx-remove-rpms
ESX410-201101212-SG Mises à jour ESX 4.1 krb5, openldap, pam-krb5
ESX410-201101213-UG Mises à jour vmware-esx-drivers-net-enic
ESX410-201101214-UG Mises à jour vmware-esx-drivers-scsi-qla4xxx
ESX410-201101215-UG Updates ESX 4.1 vmware-esx-net-nx-nic
ESX410-201101216-UG Mises à jour ESX 4.1 vmware-esx-vaai
ESX410-201101217-UG Mises à jour vmware-esx-drivers-net-e1000e
ESX410-201101218-UG Mises à jour net-cdc-ether, pilote net-usbnet
ESX410-201101219-UG Updates vmware-esx-drivers-net-e1000
ESX410-201101220-UG Updates net-igb, net-tg3, scsi-fnic
ESX410-201101221-UG Mises à jour ESX 4.1 Contrôleurs HP SAS
ESX410-201101222-UG Mises à jour, pilotes de périphérique mptsas, mptspi
ESX410-201101225-UG Mises à jour vmware-esx-pam-config library
ESX410-201101226-SG Mises à jour paquets glibc

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

Problèmes résolus

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

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

Sauvegarde

  • Impossible de prendre un snapshot mis au repos de la machine virtuelle Windows 2008 R2 qui exécute vCenter Server 4.1
    Lorsque vous créez un snapshot de la machine virtuelle Windows 2008 R2 qui a vCenter Server 4.1 d'installé, l'opération de création snapshot peut ne pas s'achever. Ce problème se produit sur les machines virtuelles Windows Server 2008 R2 lorsque la base de données ADAM est installée et si le volume du snapshot est en lecture seule. Les applications de sauvegarde telles que VMware Date Recovery ne parviennent pas à sauvegarder la machine virtuelle et signalent l'erreur : Échec de création de snapshot pour <vmname>, erreur -3960 (impossible de mettre au repos la machine virtuelle).
    Ce problème est résolu dans cette version.

CIM et API

  • vCenter Server signale de manière incorrecte l'identification du châssis de lame
    Sur les serveurs lames qui fonctionnent avec les hôtes ESX 4.1, vCenter Server signale de manière incorrecte l'identification du châssis de lame à la place de l'identification du serveur lame. Lorsqu'un serveur lame est géré par vCenter Server, le numéro d'identification est répertorié dans la section Système de vCenter Server > ongletConfiguration sous processeurs. Ce problème a été signalé sur les serveurs lames de Dell et d'IBM et survient en raison de la valeur incorrecte de la propriété SerialNumber de l'instance fixe CIM OMC_Chassis. Le problème est résolu dans cette version.

Système d'exploitation client

  • Le système d'exploitation client de Windows peut échouer et signaler l'erreur vmx_fb.dll
    Les systèmes d'exploitation client de Windows installés avec le pilote VMware Windows XP Display Driver Model (XPDM) peuvent échouer en signalant une erreur
    vmx_fb.dll et afficher un écran bleu. Le problème est résolu dans cette version.
  • Les informations CPUID renvoyées par le matériel virtuel diffèrent des informations CPUID du matériel physique
    Le logiciel client peut utiliser les informations CPUID pour déterminer les caractéristiques du matériel CPU sous-jacent (virtuel ou physique). Dans certains cas, les informations CPUID renvoyées par le matériel virtuel diffèrent du matériel physique. Sur la base de ces différences, certains composants de logiciels client peuvent rencontrer un dysfonctionnement. Dans cette version, la correction permet à certaines réponses CPUID de mieux correspondre à ce que le matériel physique renverrait.
  • L'installation de VMware Tools Operating System Specific paquets (OSP) sur SUSE Linux 9 provoque une erreur de résolution écran
    Lorsque vous installez VMware Tools OSP sur SUSE Linux 9, le système d'exploitation configure le fichier /etc/X11/XF86Config du système X Window et remplace le pilote vidéo vesa par celui de VMware. Si vous utilisez un autre pilote vidéo que vesa, VMware Tools OSP ne le remplace pas. Les tentatives pour changer la résolution d'écran en utilisant la commande GUI ou Linux xrandr échouent. Le problème est résolu dans cette version.
  • La fonction d'ajout à chaud risque d'échouer si les hôtes ESX ont moins de mémoire physique disponible
    L'augmentation de la mémoire pour les machines virtuelles utilisant la fonction d'ajout à chaud échoue si la mémoire physique disponible des hôtes ESX est inférieure à deux fois la capacité de mémoire supplémentaire de la machine virtuelle.
    Pour afficher la mémoire physique disponible dans vSphere Client, cliquez sur Hôtes ESX > Allocation des ressources -> Mémoire > Capacité disponible.
    Pour afficher la capacité de mémoire supplémentaire de la machine virtuelle, cliquez sur Machines virtuelles > Allocation des ressources > Mémoire > Capacité de mémoire supplémentaire.
    Le problème est résolu dans cette version.
  • Le programme d'installation RPM du VMware Tools pour RHEL3, RHEL4 et SLES9 ne peut pas vérifier la signature de paquet
    Lorsque vous utilisez le programme d'installation RPM pour installer les VMware Tools pour RHEL3, RHEL4 et SLES9, la vérification de signature échoue avec la
    signature V3 RSA/MD5 : message d'avertissement NOKEY, ID de clé 66fd4949. Cette situation se produit, car les anciennes versions de RPM ne peuvent pas vérifier les signatures RSA créées par les nouvelles versions de RPM. Pour effectuer la vérification des signatures, téléchargez le fichier de clé VMWARE-PACKAGING-GPG-DSA-KEY.pub sur http://www.vmware.com/download/paquets.html. Une fois le fichier de clé importé, le message d'avertissement ne s'affiche pas.
  • Mise à jour du pilote WDDM
    Dans cette version, le pilote WDDM (Windows Display Driver Model) est mis à jour pour corriger certains problèmes où une machine virtuelle Windows échoue et affiche un écran bleu.


  • Tailles de mémoire dans les paramètres par défaut des machines virtuelles des systèmes d'exploitation client RHEL 32 bits et 64 bits mises à jour
    Les tailles de mémoire minimales, par défaut, et maximales recommandées dans les paramètres par défaut des machines virtuelles des systèmes d'exploitation client RHEL à 32 bits et à 64 bits sont mises à jour selon les spécifications du dernier système d'exploitation RHEL 6 sur http://www.redhat.com/.


  • Après la mise à niveau vers le logiciel client ESX 4.1, le logiciel client DOS peut ne pas démarrer une machine virtuelle
    Lorsqu'un logiciel client DOS (par exemple, Altiris Deployment Solution) utilise PXE pour démarrer une image DOS, la séquence de démarrage de PXE peut ne pas effectuer l'amorçage de l'image à partir du serveur et le chargeur de démarrage peut afficher le statut : erreur0xc0000001. Ce problème est résolu dans cette version.

Divers

  • Avertissement affiché dans /var/log/vmkwarning lorsque ESX démarre
    Les messages d'avertissement comme suit peuvent apparaître dans
    /var/log/vmkwarning lorsqu'un hôte ESX démarre :
    AVERTISSEMENT : AcpiShared : 194 SSDTd+ : Longueur table 11108 > 4096
    Cet avertissement est généré lorsqu'un hôte ESX lit une table ACPI à partir du BIOS où la taille de la table est supérieure à 4 096 octets. Cet avertissement est sans danger et vous pouvez l'ignorer. Ce correctif met l'avertissement à un niveau inférieur sur un journal.
  • la commande lokkit peut entraîner l'échec des hôtes ESX
    Ne pas exécuter la
    commande lokkit. Si vous l'exécutez, le fait de cliquer sur Annuler garantit qu'elle ne nuise pas à la console de service. Si vous exécutez la commande lokkit à partir de la console de service d'un hôte ESX, une fenêtre de configuration de pare-feu comportant le niveau de sécurité ou les options de réseau s'affiche avec les trois boutons suivants : OK, Personnaliser et Annuler. Si vous cliquez sur OK sans changer les options de réseau ou le niveau de sécurité, un message setenforce : SELinux est désactivé peut apparaître sur la console de service. Échec de l'hôte ESX et il ne redémarre pas. Ce problème se produit en raison de la présence de la commande lokkit dans un paquet obsolète system-config-securitylevel-tui. Ce paquet a été installé sur tous les hôtes ESX avant ESX 4.1 Update 1. Le problème est résolu dans cette version.
  • Mise à jour de la console de service
    La version de la console de service est mise à jour vers la version 2,6.18-194.11.1. Cette nouvelle version noyau de la console de service résout le problème lié au dépassement de capacité négatif de la pile en mode compatibilité 64 bits identifié également par CVE-2010-3081. Ce problème a été corrigé dans un correctif d'ESX 4.1 avant la publication d'ESX 4.1 Update 1.
    Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a réaffecté les noms CVE-2010-1084, CVE-2010-2066, CVE-2010-2070, CVE-2010-2226, CVE-2010-2248, CVE-2010-2521, CVE-2010-2524, CVE-2010-0008, CVE-2010-0415, CVE-2010-0437, CVE-2009-4308, CVE-2010-0003, CVE-2010-0007, CVE-2010-0307, CVE-2010-1086, CVE-2010-0410, CVE-2010-0730, CVE-2010-1085, CVE-2010-0291, CVE-2010-0622, CVE-2010-1087, CVE-2010-1173, CVE-2010-1437, CVE-2010-1088, CVE-2010-1187, CVE-2010-1436, CVE-2010-1641, et CVE-2010-3081 à ces problèmes.
  • Les données graphiques des performances pour la mise en réseau affichent des informations incorrectes
    Les données graphiques des performances empilées par machine virtuelle pour la mise en réseau affichaient des informations incorrectes. Vous pouvez accéder au diagramme à partir d' Options de diagramme dans les Paramètres avancésdans l' ongletPerformances. Les statistiques de réception et de transmission du réseau d'une machine virtuelle connectée au Commutateur virtuel distribué (DVS) ont été inversées et affichées de manière incorrecte dans les versions antérieures. La correction garantit que les statistiques correctes sont recueillies et transmises à l'interface utilisateur des diagrammes des performances.
  • Mise à jour vers la version Tomcat
    Tomcat est mis à jour vers la version 6.0.28, qui résout de multiples problèmes de sécurité existant dans les versions antérieures de Tomcat. Le projet CVE (Common Vulnerabilities and Exposures) (cve.mitre.org) a affecté les noms suivants aux problèmes de sécurité corrigés dans Tomcat 6.0.24 : CVE-2009-2693, CVE-2009-2901, CVE-2009-2902, CVE-2009-3548. Le projet CVE (cve.mitre.org) a affecté les noms suivants aux problèmes de sécurité corrigés dans Tomcat 6.0.28 : CVE-2010-2227, CVE-2010-1157.
  • Mise à jour vers cURL RPM pour la console de service
    La console de service RPM cURL d'ESX est mise à jour vers curl-7.15.5-9.4652.vmw, ce qui corrige un problème de sécurité. Le projet CVE (cve.mitre.org) a affecté le nom CVE-2010-0734 à ce problème.
  • Pilotes Async ajoutés aux correctifs d'ESX 4.1 Update 1
    Les pilotes Async inclus dans les correctifs d'ESX 4.1 Update 1 sont intégrés dans ISO et dans les correctifs.


    Mises à jour des modules de la console de service
    Dans cette version, les paquets noyau de la console de service sont mis à jour pour résoudre un problème de sécurité. Le projet CVE (cve.mitre.org) a affecté le nom CVE-2010-3081 à ce problème.

  • Mises à jour vers la console de service et glibc RPMs
    Dans cette version, les consoles de service glibc, glibc-common et nscd RPMs sont mises à jour vers glibc-2.5-34.4909.vmw, glibc-common-2.5-34.4909.vmw et nscd-2.5-34.4909. vmw respectivement pour résoudre les multiples problèmes de sécurité. Le projet CVE (cve.mitre.org) a affecté les noms CVE-2010-3847 et CVE-2010-3856 à ces problèmes.

Mise en réseau

  • Erreur affichée dans la console de service due à la contrainte de 6 ports pour les périphériques bnx2
    Un message d'erreur comme suit est affiché sur la console de service de l'hôte ESX
    CPU10:4118 - vecteurs d'interruption : 290 : vecteurs d'interruption épuisés . Avant d'appliquer ce correctif, les périphériques bnx2 en mode MSI-X et la configuration de trames jumbo ne contenaient que 6 ports. Dans cette version, le pilote bnx2 alloue seulement 1 file d'attente RX en mode MSI-X, prend en charge 16 ports et économise les ressources en mémoire. Le problème est résolu dans cette version.
  • ESX peut échouer sur les systèmes HP avec une erreur de chargement de 32.networking-drivers
    ESX peut échouer sur certains systèmes HP tels que DL 980 G7 contenant des adaptateurs de serveurs gigaoctet à deux ports 10 GbE HP NC522SFP et affiche un message comme suit
    chargement de 32.networking-drivers . Ce problème survient lorsqu'ESX démarre le pilote NetXen, le plus souvent lors du démarrage des hôtes ESX ou de l'installation des pilotes réseau. Ceci dépend de certaines configurations du système HP. Une fois ce correctif appliqué, vous pouvez utiliser NetXen NIC pour la connectivité Gigabit Ethernet avec les hôtes ESX.
  • Pilote e1000e v1.1.2 ajouté
    Dans les versions précédentes, le pilote Intel e1000e v1.1.2 n'a pas été intégré à ESX mais fourni séparément en téléchargement. Dans cette version, le pilote e1000e v1.1.2 est intégré à ESX.
     
  • Nouvelle version du pilote QLogic qla2xxx ajoutée
    Avec cette version, une version plus récente, 832.k1.27.1-1vmw, du pilote QLogic qla2xxx est certifiée et publiée.
  • Nouvelle version du pilote Neterion vxge (async) ajoutée
    Dans cette version, la version 2.0.28.21239 du pilote Neterion vxge (async) est incluse.
  • Les hôtes ESX peuvent échouer avec bnx2x
    Si vous utilisez VMware ESX 4.1 avec Broadcom bnx2x (version pilote 1.54.1.v41.1-1vmw intégrée), vous pouvez constater les symptômes suivants :
    • L'hôte ESX peut souvent se déconnecter du réseau.
    • L'hôte ESX peut cesser de répondre avec un écran violet de diagnostic qui affiche des messages comme ceux-ci :
      [0x41802834f9c0]bnx2x_rx_int@esx:nover: 0x184f stack: 0x580067b28, 0x417f80067b97, 0x
      [0x418028361880]bnx2x_poll@esx:nover: 0x1cf stack: 0x417f80067c64, 0x4100bc410628, 0x
      [0x41802825013a]napi_poll@esx:nover: 0x10d stack: 0x417fe8686478, 0x41000eac2b90, 0x4
       
    • L'hôte ESX peut cesser de répondre avec un écran violet de diagnostic qui affiche des messages comme ceux-ci :
      0:18:56:51,183 cu10:4106)0x417f80057838:[0x4180016e7793]PktContainerGetPkt@vmkernel:nover+0xde stack: 0x1
      0:18:56:51,184 pu10:4106)0x417f80057868:[0x4180016e78d2]Pkt_SlabAlloc@vmkernel:nover+0x81 stack: 0x417f800578d8
      0:18:56:51,184 cpu10:4106)0x417f80057888:[0x4180016e7acc]Pkt_AllocWithUseSizeNFlags@vmkernel:nover+0x17 stack: 0x417f800578b8
      0:18:56:51,185 cpu10:4106)0x417f800578b8:[0x41800175aa9d]vmk_PktAllocWithFlags@vmkernel:nover+0x6c stack: 0x1
      0:18:56:51,185 cpu10:4106)0x417f800578f8:[0x418001a63e45]vmklnx_dev_alloc_skb@esx:nover+0x9c stack: 0x4100aea1e988
      0:18:56:51,185 cpu10:4106)0x417f80057918:[0x418001a423da]__netdev_alloc_skb@esx:nover+0x1d stack: 0x417f800579a8
      0:18:56:51,186 cpu10:4106)0x417f80057b08:[0x418001b6c0cf]bnx2x_rx_int@esx:nover+0xf5e stack: 0x0
      0:18:56:51,186 cpu10:4106)0x417f80057b48:[0x418001b7e880]bnx2x_poll@esx:nover+0x1cf stack: 0x417f80057c64
      0:18:56:51,187 cpu10:4106)0x417f80057bc8:[0x418001a6513a]napi_poll@esx:nover+0x10d stack: 0x417fc1f0d078
       
    • Le pilote ou microprogramme bnx2x envoie des messages de panique et rédige un suivi arrière avec des messages comme ceux-ci dans le fichier journal /var/log/vmkernel :
      vmkernel : 0:00:34:23,762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3379(vmnic0)]MC assert!
      vmkernel: 0:00:34:23,762 cpu8:4401)<3>[bnx2x_attn_int_deasserted3:3384(vmnic0)]driver assert
      vmkernel: 0:00:34:23 762 cpu8:4401)<3>[bnx2x_panic_dump:634(vmnic0)]begin crash dump
       

  • Le problème est résolu dans cette version.
  • Les hôtes ESX peuvent ne pas démarrer ou empêcher l'accès à certains périphériques lors de l'utilisation des périphériques NetXen 1 G NX3031 ou plusieurs périphériques 10 G NX2031
    Lorsque vous utilisez un périphérique NetXen 1 G NX3031 ou plusieurs périphériques 10 G NX2031, il se peut que vous voyiez un message d'erreur comme suit sur la console de service des hôtes ESX 4.1 après la mise à niveau à partir d'ESX 4.0 :
    Vecteurs d'interruption épuisés. Sur les hôtes ESX, si les périphériques NetXen 1 G et NX2031 10 G ne prennent pas en charge NetQueue, l'hôte ESX risque de manquer de vecteurs d'interruption MSI-X. Ce problème peut faire que les hôtes ESX soient impossibles à démarrer ou rendre inaccessibles d'autres périphériques (tels que les périphériques de stockage). Le problème est résolu dans cette version.  

Stockage

  • La création de fichiers volumineux .vmdk sur NFS peut échouer
    Lorsque vous créez un disque virtuel (fichier .vmdk) de grande taille, par exemple, supérieure à 1 To, sur le stockage NFS, le processus de création peut échouer et signaler une erreur :
    Une erreur système générale s’est produite : Échec de la création du disque : Erreur lors de la création du disque . Ce problème survient lorsque le client NFS n'attend pas assez longtemps pour que la baie de stockage NFS initialise le disque virtuel une fois que le paramètre RPC du client NFS a expiré. Par défaut, la valeur du délai d'attente est de 10 secondes.
    Ce correctif fournit l'option de configuration pour régler le paramètre RPC du délai d'attente au moyen de la commande
    esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout .
  • Messages d'avertissement SCSI non pris en charge enregistrés dans VMkernel
    Des messages d'avertissement SCSI non pris en charge comme suit s'inscrivent dans
    /var/log/vmkernel .
    Apr 29 04:10:55 localhost vmkernel: 0:00:01:08,161 cpu0:4096)AVERTISSEMENT : ScsiHost: 797: Échec commande SCSI sur handle 1072 : Non pris en charge . Les messages peuvent être ignorés. Ces messages inoffensifs apparaissent parce que certaines commandes SCSI ne sont pas prises en charge dans la baie de stockage. Dans cette version, les messages d'avertissement sont supprimés dans /var/log/vmkwarning afin de réduire les appels d'assistance.
  • Messages enregistrés dans les fichiers journaux de VMkernel lorsque les baies de stockage sont réanalysées à partir de vSphere Client
    Les hôtes ESX peuvent générer des messages comme suit dans les fichiers journaux de VMkernel pour les unités logiques non mappées à des hôtes ESX : 0:22:30:03.046 cpu8:4315)ScsiScan: 106: Path 'vmhba0:C0:T0:L0': Qualificateur périphérique 0x1 non pris en charge . Ces messages sont enregistrés au moment où les hôtes ESX démarrent ou lorsque vous lancez une opération de réanalyse des baies de stockage à partir de vSphere Client ou toutes les 5 minutes après le démarrage des hôtes ESX. Dans cette version, les messages ne sont plus enregistrés.
  • Messages d'erreur enregistrés lors de l'analyse des unités logiques à partir de la baie de stockage iSCSI
    Les hôtes ESX peuvent échouer avec un message NOT_REACHED bora/modules/vmkernel/tcpip2/freebsd/sys/support/vmk_iscsi.c:648" sur un écran violet lorsque vous analysez des unités logiques à partir de la baie de stockage iSCSI en utilisant la commande esxcfg-swiscsi de la console de service ou via client vSphere ( Inventaire > Configuration > Adaptateurs de stockage > Adaptateur logiciel iSCSI) . Ce problème peut survenir si le paramètre
    tcp.window.size dans /etc/vmware/vmkiscsid/iscsid.conf est modifié manuellement. Ce correctif résout le problème et enregistre également les messages d'avertissement dans /var/log/vmkiscsid.log pour ESX, si le paramètre tcp.window.size est modifié par une valeur inférieure à sa valeur par défaut.
  • Les hôtes ESX peuvent échouer lorsque vous utilisez LSI SAS HBA connectés à des disques SATA
    La perte de données peut survenir sur les hôtes ESX avec LSI SAS HBA connectés à des disques SATA. Ce problème survient lorsque la taille maximum d'E/S est supérieure à 64 ko dans le pilote mptsas et LSI HBA SAS sont connectés à des disques SATA. Le problème est résolu dans cette version.
     
  • La règle VMW_PSP_RR est définie comme règle de sélection de chemin d'accès par défaut pour les baies de stockage NetApp qui prennent en charge SATP_ALUA
    La règle VMW_PSP_RR est définie comme la règle de sélection de chemin d'accès par défaut (PSP) pour les baies de stockage NetApp qui prennent en charge SATP_ALUA. Vous pouvez définir cette règle en utilisant vCenter Server ou via l'interface de ligne de commande (CLI).
    Pour définir cette règle via vCenter Server :
    1. Cliquez sur l'onglet Configuration.
    2. Dans le panneau de gauche sous Adaptateurs de matériel, sélectionnez Adaptateurs de stockage.
    3. Sur le panneau de droite, sélectionnez le vmhba qui se connecte aux unités logiques NetApp.
    4. Sélectionnez la règle du chemin d'accès de l'unité logique que vous souhaitez modifier, faites un clic droit et sélectionnez Gérer chemins d'accès.
    5. Dans la boîte de dialogue qui s'affiche, sous Règle, définissez Sélection de chemin d'accès sur Round Robin.

      Pour définir cette règle via CLI, exécutez les commandes suivantes sur la console de service :

      # esxcli nmp satp addrule --satp="VMW_SATP_ALUA" --psp="VMW_PSP_RR" --claim-option="tpgs_on" --vendor="NETAPP" --description="NetApp arrays with ALUA support"
      # esxcli corestorage claimrule load
      # esxcli corestorage claimrule run


      Le problème est résolu dans cette version.
  • Définition de VMW_PSP_RR comme règle de sélection de chemin d'accès par défaut (PSP) pour les baies de stockage IBM 2810XIV
    La règle VMW_PSP_RR est définie comme règle de sélection de chemin d'accès par défaut (PSP) pour les baies de stockage IBM 2810XIV. Vous pouvez définir cette règle en utilisant vCenter Server ou via l'interface de ligne de commande (CLI).
    Pour définir cette règle via vCenter Server :
    1. Cliquez sur l'onglet Configuration.
    2. Dans le panneau de gauche sous Adaptateurs de matériel, sélectionnez Adaptateurs de stockage.
    3. Sur le panneau de droite, sélectionnez le vmhba qui se connecte aux LUN IBM.
    4. Sélectionnez la règle du chemin d'accès de l'unité logique que vous souhaitez modifier, faites un clic droit et sélectionnez Gérer chemins d'accès.
    5. Dans la boîte de dialogue qui s'affiche, sous Règle, définissez Sélection de chemin d'accès sur Round Robin.
      Pour définir cette règle via CLI, exécutez les commandes suivantes sur la console de service :
      # esxcli nmp satp addrule --satp="VMW_SATP_ALUA" --psp="VMW_PSP_RR" --claim-option="tpgs_on" --vendor="IBM" --model="2810XIV" --description="IBM 2810XIV arrays with ALUA support"
      # esxcli nmp satp addrule --satp="VMW_SATP_DEFAULT_AA" --psp="VMW_PSP_RR" --claim-option="tpgs_off" --vendor="IBM" --model="2810XIV" --description="IBM 2810XIV arrays without ALUA support" # esxcli corestorage claimrule load
      # esxcli corestorage claimrule run


      Le problème est résolu dans cette version.
  • Il manque des informations cibles de certaines unités logiques dans l'interface utilisateur de vCenter Server
    Des informations cibles des unités logiques dans l'interface utilisateur de vCenter Server ne s'affichent pas parfois dans l'interface utilisateur de vCenter Server.
    Pour afficher ces informations dans l'onglet Configuration, procédez comme suit :

    1. Cliquez sur Adaptateurs de stockage sous Matériel.
    2. Cliquez sur Adaptateur de bus hôte iSCSI dans le volet Adaptateurs de stockage.
    3. Cliquez sur Chemins d'accès dans le volet Afficher.
       Dans les versions antérieures à ESX 4.1 Update 1, certaines unités logiques iSCSI ne montraient pas les informations cibles. Le problème est résolu dans cette version.


  • le fichier txtsetup.oem sur la disquette désigne un emplacement incorrect du pilote PVSCSI
    Installation des systèmes d'exploitation client de Microsoft Windows Server 2003 sur les hôtes ESX 4.1 avec le pilote VMware SCSI paravirtuel (PVSCSI) alors que le lecteur de démarrage échoue et signale l'erreur suivante :
    Insérez le disque nommé :
    Disque de contrôleur VMware PVSCS
    dans le lecteur
    A :
    Le fichier
    txtsetup.o em sur une disquette désigne un emplacement incorrect du pilote PVSCSI. Dans cette version, l'emplacement est corrigé.
      • La fonction de réanalyse du stockage est modifiée pour gérer les périphériques de stockage décommissionés
        La fonction de réanalyse du stockage par défaut a changé pour gérer les périphériques de stockage décommissionnés, ce qui entraîne un état d'APD (Tous chemins vers bas). Pour plus d'informations, voir KB 1015084 sur http://kb.vmware.com/kb/1015084. La solution fournie dans le KB à ce problème consiste à régler manuellement l'option de configuration avancée /VMFS3/FailVolumeOpenIfAPD sur 1 avant d'effectuer la réanalyse, puis de la réinitialiser sur 0, une fois l'opération de réanalyse terminée. Le problème est résolu dans cette version. Vous ne devez pas appliquer la solution de définition ou de suppression de la définition de cette option de configuration avancée lors du démarrage de l'opération de réanalyse. Les machines virtuelles sur des volumes non-APD n'échoueront plus lors de l'opération de réanalyse, même si certaines unités logiques se trouvent dans l'état de tous chemins vers bas.
      • Nouvelle version du pilote 3ware SCSI (async) ajoutée
        Dans cette version, la version 2.26.08.036vm40-1OEM du pilote 3ware SCSI (async) est incluse.

      Matériel pris en charge

      • Le graphique de consommation d'énergie n'affiche pas d'informations sur plusieurs hôtes ESX
        Le graphique de consommation d'énergie accessible à partir de vSphere Client pour les hôtes de l'hôte ESX 4.1 n'apparaît pas sur plusieurs hôtes ESX de certains fournisseurs. Le diagramme affiche 0 watt. Vous pouvez accéder au graphique de consommation d'énergie à partir de vSphere Client, cliquez sur Hôte, cliquez sur l'onglet Performance et sélectionnez Alimentation sur le menu déroulant. Dans cette version, le graphique de consommation d'énergie est mis à jour pour prendre en charge les hôtes supplémentaires de Bull, Dell, HP, Mitsubishi, NEC et Toshiba.


      • Prise en charge supplémentaire des périphériques Dell iDRAC
        Dans cette version, id du périphérique DELL iDRAC : 413C:a102 est pris en charge.

      Mise à niveau et installation

      • La résolution de dépendance esxupdate n'est pas cohérente avec la règle du bulletin
        Dans l'utilitaire
        esxupdate , la résolution de dépendance ne correspond pas à la règle de construction du bulletin. Lors de l'installation des hôtes ESX, vous ne verrez aucune erreur ou message d'avertissement. Après l'installation, les utilisateurs peuvent vérifier les informations VIB installées en exécutant la commande esxupdate --vib-view query dans la console de service. Il faut utiliser la règle de livraison du bulletin pour utiliser la version la plus ancienne de VIB nécessaire, de sorte que vous puissiez contrôler les correctifs que vous avez installés et éviter les mises à jour inconnues ou inattendues vers des hôtes ESX.

      Gestion des machines virtuelles

      • Les machines virtuelles ne se mettent pas sous tension dans certains cas, même lorsqu'il existe un espace d'échange sur les hôtes ESX 4.1
        La mise sous tension de la machine virtuelle fonctionnant sur les hôtes ESX 4.1échoue avec l'erreur
        Échange COS insuffisant pour mettre sous tension dans /var/log/vmware/hostd.log même si la console de service possède 800 Mo d'espace libre et d'échange activé. De plus, l'exécution de la commande free -m sur la console de service montre qu'il y a plus de 20 Mo d'espace libre. Ce correctif permet de mettre sous tension les machines virtuelles lorsqu'il existe un espace d'échange sur les hôtes ESX 4.1.
      • Après la migration d'une machine virtuelle, les périphériques USB sur l'hôte de destination peuvent apparaître assignés à tort à la machine virtuelle
        Après la migration d'une machine virtuelle vers un hôte de destination qui comprend des périphériques USB et l'ajout de périphériques supplémentaires USB à la machine virtuelle migrée sur l'hôte de destination, les périphériques USB sur l'hôte de destination peuvent apparaître assignés à tort à la machine virtuelle.


        La reprise d'une machine virtuelle Windows de 64 bits en état interrompu peut provoquer l'échec de la machine virtuelle
        Si une machine virtuelle Windows de 64 bits qui utilise des techniques logicielles pour la virtualisation du jeu d'instructions ou la traduction binaire (BT) est reprise de son état interrompu ou migrée vers un hôte ESX 4.1, la machine virtuelle peut cesser de répondre, et les journaux d'événements de Microsoft Windows peuvent afficher des messages d'erreur comme suit :
        Exécution .NET
        Version d'exécution .NET * Erreur fatale exécution moteur *
        Erreur d'application :
        Nom de l'application défaillante : oobe.exe *
        Nom du module défaillant : mscorwks.dll *
        Code d'exception : 0xc00000005

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

      vMotion et Storage vMotion

      • Impossible de restaurer des snapshots créés sur les hôtes ESX 3.5
        Les hôtes ESX ne peuvent pas restaurer un ancien snapshot après mise à niveau d'ESX 3.5 Update 4 vers ESX 4.1 Update 1. Le message suivant peut être affiché dans vCenter Server :
        Les fonctions prises en charge par le(s) processeur(s) dans cette machine sont différentes de celles prises en charge par le(s) processeur(s) dans la machine sur laquelle le point de contrôle a été enregistré. Veuillez reprendre le snapshot sur une machine où les processeurs ont les mêmes fonctions . Ce problème peut survenir lorsque vous créez des machines virtuelles sur les hôtes ESX 3.0. Exécutez vMotion et suspendez les machines virtuelles sur les hôtes ESX 3.5. Puis, reprenez-les sur les hôtes ESX 4.x. Dans cette version, le message d'erreur n'apparaît pas. Vous pouvez restaurer des snapshots créés sur les hôtes ESX 3.5, et reprendre les machines virtuelles sur les hôtes ESX 4.x.
      • Le fichier d'échange d'une machine virtuelle augmente en taille à la fin de Storage VMotion
        Lorsqu'une machine virtuelle fonctionnant avec une réservation de mémoire est déplacée vers une banque de données différente à l'aide de Storage VMotion, après l'achèvement de Storage VMotion, la machine virtuelle a un fichier d'échange de taille égale à la mémoire configurée. Des messages comme suit peuvent être enregistrés dans les fichiers
        vmware.log de la machine virtuelle
        May 25 16:42:38 756: vmx| FSR: Diminution de réservation CPU de 750 MHz, en raison du transfert de réservation atomique CPU de cette quantité. Nouvelle réservation est de 0 MHz.FSR : Diminution de la réservation de mémoire de 20 480 Mo en raison du transfert de réservation atomique de mémoire atomique CPU de cette quantité. Nouvelle réservation est de 0 page. CreateVM : Échange : génération du nom de fichier d'échange normal.
        Lorsque les hôtes ESX exécutent Storage VMotion, la taille du fichier d'échange des machines virtuelles augmente à memsize. Avec ce correctif, la taille du fichier d'échange reste la même après Storage VMotion.
      • Les hôtes ESX peuvent échouer lorsque la tâche Storage VMotion est annulée durant le déplacement d'une machine virtuelle mise sous tension
        L'annulation de la tâche Storage vMotion durant le déplacement d'une machine virtuelle mise sous tension contenant plusieurs disques sur une banque de données vers une banque de données différente sur le même hôte peut entraîner l'échec des hôtes ESX 4.1 avec l'erreur suivante :
        Exception : NOT_IMPLEMENTED bora/lib/pollDefault/pollDefault.c:2059 . Le problème est résolu dans cette version.

      VMware Tools

      • Erreur affichée lorsque VMware Tools est installé et le service de spouleur d'impression est arrêté
        Si vous installez VMware Tools sur une machine virtuelle sur laquelle le service de spouleur d'impression a été arrêté ( Outils administratifs > Services> Spouleur d'impression), et cliquez sur Installer VMware Tools> Standard ou Personnaliséavec la fonction Thin Print sélectionnée ( Installation personnalisée > Pilotes des périphériques VMware > Thin Print), la désinstallation de VMware Tools entraîne une
        - erreur d'exécution ! Programme : C:\Program Files\VMware\VMware Tools\TPVCGateway.exe. Cette application a demandé à l'exécution d'y mettre fin de façon inhabituelle. Erreur : veuillez contacter l'équipe d'assistance de l'application pour plus d'informations . Cliquez sur OK pour supprimer le message d'erreur et désinstallez VMware Tools. Dans cette version, le message d'erreur n'apparaît pas.
      • Bouton de l'interface d'utilisateur du panneau de configuration VMware dans le panneau de configuration Windows pour effectuer une mise à niveau de VMware Tools
        Le bouton de l' interface d'utilisateur du panneau de configuration dans le panneau de configuration Windows pour effectuer une mise à niveau de VMware Tools à partir d'un système Windows d'exploitation client est désactivé pour les utilisateurs non-administrateurs. De plus, les options Réduire et Scriptsdans le panneau de configuration de VMware Tools sont désactivées pour les utilisateurs non-administrateurs. Ce correctif ne concerne que l'interface utilisateur et ne bloque pas les mises à niveau d'applications personnalisées. Pour bloquer les mises à niveau de VMware Tools à tous les utilisateurs, définissez le paramètre
        isolation.tools.autoinstall.disable="TRUE " dans le fichier VMX.
      • L'installation de vmware-open-vm-tools-xorg-utilities peut échouer
        Lors de l'installation de vmware-open-vm-tools-xorg-services sur les systèmes d'exploitation client, et si
        /usr et / les répertoires sont montés sur des périphériques différents, une erreur sera affichée comme suit :
        Échec : Dans : création de lien physique
        `/usr/lib/vmware-tools/libconf/etc/fonts/fonts.conf' =>
        `/etc/fonts/fonts.conf': Erreur de lien périphérique croisé invalide
        .
        Par exemple, si vous exécutez zypper (gestionnaire de paquets SLES) pour installer vmware-open-vm-tools-services, vous pouvez voir l'erreur ci-dessus sur l'écran. Lorsque vmware-open-vm-tools-xorg-utilities essaie de créer un lien physique sur
        /etc/fonts/fonts.conf , un problème de lien périphérique croisé peut survenir si les répertoires /usr et / sont montés sur des périphériques différents. Une fois ce correctif appliqué, vous pouvez installer vmware-open-vm-tools-xorg-utilities.
      • La création de snapshots mis au repos peut ne pas fonctionner sur les versions non anglaises des systèmes d'exploitation client de Microsoft Windows
        Le problème survient lorsqu'un chemin d'accès à un dossier Windows connu contient des caractères non-ASCII, par exemple, le dossier des données d'application dans les systèmes d'exploitation client de Windows en tchèque. Ce problème entraîne l'échec de l'opération de snapshot. Le problème est résolu dans cette version.
         

      • Les snapshots mis au repos peut ne pas fonctionner sur des versions non anglaises des systèmes d'exploitation client de Microsoft Windows
        Les snapshots mis au repos peut ne pas fonctionner sur des versions non anglaises des systèmes d'exploitation client de Windows comme les versions françaises de Windows 2008 R2 et les systèmes d'exploitation client de Windows 7. Ce problème survient parce que le service VMware Snapshot Provider n'est pas enregistré en tant que service de Windows ou comme une application COM+ à proprement parler sur certaines versions non anglaises des systèmes d'exploitation client de Windows Microsoft. Ce problème entraîne l'échec de l'ensemble de l'opération de snapshot et aucun snapshot ne peut être créé. Ce problème est résolu dans cette version.

      Début de la page

      Problèmes identifiés

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

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

      Sauvegarde

      • Les commandes de la console de service VCB peuvent générer des messages d'erreur dans la console de service ESX
        Lorsque vous exécutez les commandes de la console de service VCB sur la console de service des hôtes ESX, un message d'erreur comme suit 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.

        Aucune solution n'est actuellement disponible pour ce problème.

      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é. En raison de ce problème, vous ne pouvez pas appeler la méthode SetBIOSAttribute. 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éagir après l'ajout à chaud d'une mémoire supérieure à 3 Go *
        Le système d'exploitation client Redhat5.4-64 peut cesser de répondre s'il est démarré avec un périphérique IDE attaché, et la mémoire est ajoutée à chaud de moins de 3 Go à plus de 3 Go.

        Solution : N'utilisez pas l'ajout à chaud pour changer la taille de la mémoire de la machine virtuelle à une taille inférieure ou égale à 3 072 Mo à plus de 3 072 Mo. Éteignez 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 de Windows NT avec le matériel des machines virtuelles version 7 *
        Lorsque vous installez Windows NT 3.51 dans une machine virtuelle qui a la version 7 du matériel, le processus d'installation cesse de répondre. 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 noyau Windows NT 3.51. Les machines virtuelles avec la version 7 du matériel 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 4 puis mis à niveau vers la version 7, utilisez VMware vCenter Converter pour rétrograder la machine virtuelle au matériel version 4.
      • L'installation des paquets VMware Tools OSP sur les systèmes d'exploitation client SLES 11 produit un message "paquets non pris en charge" *
        Lorsque vous installez des paquets VMware Tools OSP sur le système d'exploitation client de SUSE Linux Enterprise Server 11, un message d'erreur comme suit 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 pris en charge par le fournisseur. Cependant, ces packages sont pris en charge.
      • 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 du noyau uniquement pour le noyau en cours d'exécution.

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

      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 avec le temps en fonction de ce qui se passe sur l'hôte ESX suivi. 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 resxtop seulement si vous avez besoin des données. Si vous avez à recueillir des statistiques resxtopou esxtopsur une longue période, arrêtez et redémarrez resxtopou esxtoppériodiquement au lieu d'exécuter une instance resxtopou esxtoppendant des semaines ou des mois.
      • Longueur de l'ID de groupe dans vSphere Client plus courte que la longueur de l'ID de groupe dans vCLI *
        Si vous spécifiez un ID de groupe en utilisant vSphere Client, vous ne pouvez utiliser que neuf caractères. Cela étant, vous pouvez spécifier jusqu'à dix caractères si vous spécifiez l'ID de groupe en utilisant le vCLI
        vicfg-user .

        Solution : Aucune


      • Un message d'avertissement s'affiche lorsque vous exécutez la commande esxcfg-pciid
        Lorsque vous essayez d'exécuter la commande esxcfg-pciid dans 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

      • 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 du port iSCSI.
      • Perte de connectivité réseau et panne du système lors d'opérations de contrôle sur des NIC physiques *
        Dans certains cas, lorsque plusieurs NIC X-Frame II s2io partagent le même bus pci-x, les opérations de contrôle comme le changement de MTU sur la NIC physique provoquent une perte de connectivité réseau et un crash du système.

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

        Solution : Dans les machines virtuelles acheminant le trafic qui exécutent des systèmes d'exploitation client Linux, incluez le paramètre de délai de chargement disable_lro=1 de module du pilote Linux VMXNET2 ou VMWNET3.
      • Problèmes de mémoire lorsqu'un hôte utilise plus de 1 016 dvPorts sur un vDS *
        Le nombre maximal de dvPorts par hôte sur vDS est de 4 096, mais des problèmes de mémoire peuvent survenir lorsque le nombre de dvPorts d'un hôte est proche de 1 600. 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.
      • Échec de l'exécution de vicfg-snmp-r ou vicfg-snmp -D visant les systèmes d'ESX *
        Sur un système ESX, lorsque vous essayez de réinitialiser les paramètres actuels SNMP en exécutant la commande
        vicfg-snmp -r ou que vous essayez 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'attente 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.
      • La reconfiguration de VMXNET3 NIC peut réveiller la machine virtuelle *
        La reconfiguration de NIC VMXNET3 alors que Wake-on-LAN est activé et que la machine virtuelle est endormie permet à la machine virtuelle de reprendre.

        Solution : Remettez manuellement la machine virtuelle en mode veille après la reconfiguration (par exemple, après avoir effectué un ajout à chaud ou une suppression à chaud) d'un VMXNET3 vNIC.
      • Les adaptateurs réseau de la console de service et le 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 qui suit la création d'un nouveau VMkernel ou celle d'un adaptateur de console de service sur un vDS, le nouvel adaptateur peut disparaître.

        Solution : Si vous devez pratiquer un cycle d'alimentation sur un hôte ESX dans l'heure qui suit la création d'un VMkernel ou celle d'un adaptateur 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

      • 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, comme suit :

        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. Ils sont sans incidence et peuvent être tranquillement ignorés.

        Solution : Désactivez leur affichage si vous ne souhaitez plus les voir.
      • Les conflits permanents de réservations sur des unités logiques partagées peuvent allonger le temps de démarrage des hôtes ESX*
        Vous pouvez connaître un temps d'attente conséquent lors du démarrage des hôtes partageant les unités logiques sur un réseau SAN. Cette situation peut être provoquée par des conflits entre les réservations LUN SCSI.

        Solution : Pour résoudre ce problème et rendre le démarrage plus rapide, changez le délai de commandes synchronisées lors du démarrage à 10 secondes. Pour ce faire, réglez le paramètre Scsi.CRTimeoutDuringBootsur 10 000.

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

      Matériel pris en charge

      • 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 http://kb.vmware.com/kb/1021454pour plus d'informations sur la façon de configurer l'option de démarrage ci-dessus des hôtes ESX.

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

      Sauvegarde

      • Les commandes de la console de service VCB peuvent générer des messages d'erreur dans la console de service ESX
        Lorsque vous exécutez les commandes de la console de service VCB sur la console de service des hôtes ESX, un message d'erreur comme suit 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.

        Aucune solution n'est actuellement disponible pour ce problème.

      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é. En raison de ce problème, vous ne pouvez pas appeler la méthode SetBIOSAttribute. 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éagir après l'ajout à chaud d'une mémoire supérieure à 3 Go *
        Le système d'exploitation client Redhat5.4-64 peut cesser de répondre s'il est démarré avec un périphérique IDE attaché, et la mémoire est ajoutée à chaud de moins de 3 Go à plus de 3 Go.

        Solution : N'utilisez pas l'ajout à chaud pour changer la taille de la mémoire de la machine virtuelle à une taille inférieure ou égale à 3 072 Mo à plus de 3 072 Mo. Éteignez 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 de Windows NT avec le matériel des machines virtuelles version 7 *
        Lorsque vous installez Windows NT 3.51 dans une machine virtuelle qui a la version 7 du matériel, le processus d'installation cesse de répondre. 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 noyau Windows NT 3.51. Les machines virtuelles avec la version 7 du matériel 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 4 puis mis à niveau vers la version 7, utilisez VMware vCenter Converter pour rétrograder la machine virtuelle au matériel version 4.
      • L'installation des paquets VMware Tools OSP sur les systèmes d'exploitation client SLES 11 produit un message "paquets non pris en charge" *
        Lorsque vous installez des paquets VMware Tools OSP sur le système d'exploitation client de SUSE Linux Enterprise Server 11, un message d'erreur comme suit 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 pris en charge par le fournisseur. Cependant, ces packages sont pris en charge.
      • 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 du noyau uniquement pour le noyau en cours d'exécution.

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

      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 avec le temps en fonction de ce qui se passe sur l'hôte ESX suivi. 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 resxtop seulement si vous avez besoin des données. Si vous avez à recueillir des statistiques resxtopou esxtopsur une longue période, arrêtez et redémarrez resxtopou esxtoppériodiquement au lieu d'exécuter une instance resxtopou esxtoppendant des semaines ou des mois.
      • Longueur de l'ID de groupe dans vSphere Client plus courte que la longueur de l'ID de groupe dans vCLI *
        Si vous spécifiez un ID de groupe en utilisant vSphere Client, vous ne pouvez utiliser que neuf caractères. Cela étant, vous pouvez spécifier jusqu'à dix caractères si vous spécifiez l'ID de groupe en utilisant le vCLI
        vicfg-user .

        Solution : Aucune


      • Un message d'avertissement s'affiche lorsque vous exécutez la commande esxcfg-pciid
        Lorsque vous essayez d'exécuter la commande esxcfg-pciid dans 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

      • 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 du port iSCSI.
      • Perte de connectivité réseau et panne du système lors d'opérations de contrôle sur des NIC physiques *
        Dans certains cas, lorsque plusieurs NIC X-Frame II s2io partagent le même bus pci-x, les opérations de contrôle comme le changement de MTU sur la NIC physique provoquent une perte de connectivité réseau et un crash du système.

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

        Solution : Dans les machines virtuelles acheminant le trafic qui exécutent des systèmes d'exploitation client Linux, incluez le paramètre de délai de chargement disable_lro=1 de module du pilote Linux VMXNET2 ou VMWNET3.
      • Problèmes de mémoire lorsqu'un hôte utilise plus de 1 016 dvPorts sur un vDS *
        Le nombre maximal de dvPorts par hôte sur vDS est de 4 096, mais des problèmes de mémoire peuvent survenir lorsque le nombre de dvPorts d'un hôte est proche de 1 600. 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.
      • Échec de l'exécution de vicfg-snmp-r ou vicfg-snmp -D visant les systèmes d'ESX *
        Sur un système ESX, lorsque vous essayez de réinitialiser les paramètres actuels SNMP en exécutant la commande
        vicfg-snmp -r ou que vous essayez 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'attente 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.
      • La reconfiguration de VMXNET3 NIC peut réveiller la machine virtuelle *
        La reconfiguration de NIC VMXNET3 alors que Wake-on-LAN est activé et que la machine virtuelle est endormie permet à la machine virtuelle de reprendre.

        Solution : Remettez manuellement la machine virtuelle en mode veille après la reconfiguration (par exemple, après avoir effectué un ajout à chaud ou une suppression à chaud) d'un VMXNET3 vNIC.
      • Les adaptateurs réseau de la console de service et le 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 qui suit la création d'un nouveau VMkernel ou celle d'un adaptateur de console de service sur un vDS, le nouvel adaptateur peut disparaître.

        Solution : Si vous devez pratiquer un cycle d'alimentation sur un hôte ESX dans l'heure qui suit la création d'un VMkernel ou celle d'un adaptateur 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

      • 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, comme suit :

        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. Ils sont sans incidence et peuvent être tranquillement ignorés.

        Solution : Désactivez leur affichage si vous ne souhaitez plus les voir.
      • Les conflits permanents de réservations sur des unités logiques partagées peuvent allonger le temps de démarrage des hôtes ESX*
        Vous pouvez connaître un temps d'attente conséquent lors du démarrage des hôtes partageant les unités logiques sur un réseau SAN. Cette situation peut être provoquée par des conflits entre les réservations LUN SCSI.

        Solution : Pour résoudre ce problème et rendre le démarrage plus rapide, changez le délai de commandes synchronisées lors du démarrage à 10 secondes. Pour ce faire, réglez le paramètre Scsi.CRTimeoutDuringBootsur 10 000.

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

      Matériel pris en charge

      • 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 http://kb.vmware.com/kb/1021454pour plus d'informations sur la façon de configurer l'option de démarrage ci-dessus des hôtes ESX.
      • Erreurs de mappage du périphérique PCI sur le serveur 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 incorrectement décrits provoque une faute IOMMU et le périphérique recevra une erreur d'E/S. Selon le périphérique, cette erreur d'E/S peut provoquer un message d'alerte NMI ou d'une interruption Lint1 sur la console ou une panne du 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 traitement des NMI (non-maskable interrupts). Le pilote NMI garantit que les NMI sont bien détectés et connectés. Sans ce pilote, les NMI signalant des erreurs matérielles sont ignorés par les systèmes HP avec 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 virtuelles 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 une baie EqualLogic avec une ancienne version du microprogramme. Le microprogramme peut éventuellement supprimer l'E/S de la file d'attente du module et amener les machines virtuelles à fonctionner en lecture seule après que l'E/S soit marquée comme échoué.


        Solution : mettez à niveau le microprogramme de la baie 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 l'E/S du 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 l'E/S du disque. Le symptôme majeur est la performance E/S dégradée, causant l'enregistrement d'un grand nombre de messages d'erreur semblable comme suit sur
        /var/log/messages:
        Mar 25 17:39:25 vmkernel: 0:00:08:47 438 cpu1:4097)scsi_cmd_alloc retourné NULL
        Mar 25 17:39:25 vmkernel: 0:00:08:47 438 cpu1:4097)scsi_cmd_alloc retourné 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.
      • Sur certaines versions de vSphere Client, l'état de la batterie peut être mal répertorié comme une alerte *
        Dans vSphere Client à partir de l'onglet État du matériel, lorsque la batterie est dans son cycle d'apprentissage, l'état de la batterie fournit un message d'alerte indiquant que l'état d'intégrité de la batterie est faible. Toutefois, le niveau de la batterie est en fait très bon.

        Solution : Aucune.

      Mise à niveau et installation

      • L'installation de vCenter Server 4.1 utilisant une base de données existante IBM DB2 échoue parfois avec un message d'erreur DB2 *
        Lorsque vous installez vCenter Server 4.1 au moyen d'une base de données vCenter Server DB2 existante, vous devriez recevoir un message d'erreur comme suit :
        Erreur de base de données : "Erreur ODBC : (5UA01) - [IBM][CLI Driver][DB2/NT64] SQL20453N La tâche "RULE_TOPN1_DB2USER1" ne peut être supprimée car elle est en cours d'exécution. SQLSTATE=5UA01"est retourné lors de l'exécution de l'instruction SQL "CALL CREATE_TOPN_JOB1_PROC()" "
        Ce message apparaît lorsque DB2 rencontre un problème connu d'IBM. Elle indique qu'une tâche DB2 est en cours d'exécution et que le programme d'installation vCenter Server ne peut pas initialiser la base de données vCenter.

        Solution : Pour éliminer le conflit afin d'installer vCenter Server, procédez comme suit :

        1. Si vCenter Server fonctionne, éteignez-le soigneusement.
        2. Utilisez le panneau de configuration Services pour arrêter et redémarrer le service DB2.
        3. Redémarrez le processus d'installation et veillez à sélectionner l'option pour remplacer la base de données existante.

      • L'installation de vSphere Client peut échouer avec une erreur *
        Lorsque vous installez Client vSphere, le programme d'installation peut tenter de mettre à niveau une exécution obsolète de Microsoft Visual J #. La mise à niveau échoue et l'installation de vSphere client échoue avec Le programme d'installation de Microsoft Visual J # 2.0 deuxième édition a retourné le code d'erreur 4113.

        Solution : Désinstallez toutes les versions précédentes de Microsoft Visual J# et installez vSphere Client. L'installation inclut un pack mis à jour de Microsoft Visual J#.

        La correction de mise à niveau des hôtes exécutant ESX 4.0.x vers ESX 4.1 peut échouer *
        La correction de mise à niveau des hôtes peut échouer, en raison de l'impossibilité de regénérer initrd avant de redémarrer le système. Ce problème survient si vous avez importé les bundles de versions de mise à niveau des hôtes (upgrade-from-ESX4.0-to-4.1.0-0,0.260247-release.zip et upgrade-from-esx4.0-to-4.1-update01.zip) dans le référentiel d'Update Manager. Un problème connu dans la logique d'analyse de mise à niveau d'Update Manager est à l'origine de ce problème.

        Solution : Pour récupérer Update Manager, réinstallez Update Manager. Pour récupérer l'hôte ESX 4.0.x qui a rencontré ce problème, installez le bundle de mise à niveau manuellement en utilisant l'utilitaire de ligne de commande
        esxupdate .

      vMotion et Storage vMotion

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

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

      • Les connexions à chaud échouent après le déplacement du fichier d'échange *
        Les connexions à chaud échouent pour les machines virtuelles mises sous tension dans un cluster DRS, ou sur un hôte autonome et signalent une erreur Échec de la reprise de la destination ; VM introuvableune fois que l'emplacement du fichier d'échange est modifié

        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.

      Début de la page