Prenez le contrôle de votre environnement multicloud

Ce problème survient seulement si votre hôte ESXi comporte la configuration suivante :

• L'hôte ESXi comprend des pilotes périphériques basés sur des blocs comme HP DL380 G7 qui a le contrôleur Smart Array P410i et le pilote cciss
• L'hôte ESXi 4.1 a le correctif ESXi 4.1 d'installé pour démarrer la banque sur la partition 5 (et non sur la partition 6)
  Remarque : L'hôte ESXi a été mis à niveau d'ESXi 3.5 vers ESXi 4.1 (applicable seulement sur ESXi Installable)

Ce problème survient en raison d'une structure de données de l'enregistrement démarrage prolongé (EBR) décalée dans la partition étendue. Le contenu de la table de partition dans EBR ou la partition logique ne sont pas endommagés. L'installation des correctifs échoue en raison d'une vérification d'état présentée dans ESXi 4.1 VMkernel, ce qui déclenche une annulation prématurée de la procédure d'installation.

Si vous rencontrez ce problème, effectuez une nouvelle installation de la version RC d'ESXi 4.1 Update 1. Le build GA d'ESXi 4.1 Update 1 comprendra le correctif pour mettre à niveau ESXi 4.1 vers ESXi 4.1 Update 1.

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

Après une installation réussie d'ESXi Installable ou un démarrage réussi d' ESXi Embedded, vous devez procéder à plusieurs étapes de configuration. Notamment, une certaine configuration pour l'octroi de licences, la mise en réseau et la sécurité. Reportez-vous aux guides suivants de la documentation vSphere pour un accompagnement sur ces tâches de configuration.

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

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

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

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

Mise à niveau de VMware Tools

VMware ESXi 4.1 Update 1 nécessite une mise à niveau de VMware Tools. VMware Tools est une suite d'utilitaires qui améliore les performances du système d'exploitation client de la VM. Reportez-vous aux Problèmes résolus de VMware Tools pour une liste des problèmes résolus dans cette version ESXi relative à VMware Tools.

Pour déterminer une version installée de VMware Tools, voir Vérification d'une version de VMware Tools (KB 1003947).

Mise à niveau ou migration vers ESXi 4.1 Update 1

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

• VMware vCenter Update Manager. <Informations en attente>
• vihostupdate. Utilitaire de ligne de commande qui prend en charge les mises à niveau directes d'ESXi 4.0 vers ESXi 4.1 Update 1. Cet utilitaire nécessite vSphere CLI. Reportez-vous au Guide de mise à niveau vSphere. Pour appliquer le bundle VEM, utilisez l'utilitaire vihostupdate . Ceci permet d'ajouter l'hôte ESXi 4.1 Update 1 Embedded dans Cisco Nexus 1000 AV 2 vDS. .

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

Type de mise à niveau	Outils de mise à niveau pris en charge	ESXi 3.5 Update 5	ESX 4.0 comprend : Update 1 Update 2	ESX 4.1
upgrade-from-ESXi3.5-to-4.1_update01,345122.zip (hors ligne)	VUM	Oui	Non	Non
upgrade-from-esxi4.0-to-4.1-update01-345122.zip	Ligne de base de mise à niveau de l'hôte de VUM vihostupdate	Non	Oui	Non
update-from-esxi4.1-4.1_update01.zip (hors ligne)	VUM – Ligne de base de correctifs vihostupdate	Non	Non	Oui
ESXi410-Update01 (En ligne)	VUM – Ligne de base de correctifs	Non	Non	Oui

Remarques :

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

Correctifs contenus dans cette version

Cette version contient tous les bulletins d'ESXi qui ont été publiés avant la date de publication de ce produit. Voir la page VMware Télécharger correctifs pour plus d'informations sur les bulletins individuels.

En plus du format de fichier ZIP, la version ESXi 4.1 Update 01, embedded et installable, est distribuée sous forme de correctif qui peut être appliqué aux installations existantes du logiciel ESXi 4.1.

La trousse de correctifs logiciels ESX410-Update01 contient les bulletins individuels suivants :

ESXi410-201101201-SG Mises à jour microprogramme ESXi 4.1
ESXi410-201101202-SG Mises à jour Outils ESXi 4.1

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 :

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

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 VM Windows 2008 R2 qui exécute vCenter Server 4.1
  Lorsque vous créez un snapshot de la VM 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 VM 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 VM et signalent l'erreur : Échec de création de snapshot pour <vmname>, erreur -3960 (impossible de mettre au repos la VM).
  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 ESXi 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 > onglet Configuration 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.

• Le programme d'installation RPM de 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 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.
• 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 VM 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 VM.
  Pour afficher la mémoire physique disponible dans vSphere Client, cliquez sur Hôtes ESXi > Allocation des ressources -> Mémoire > Capacité disponible.
  Pour afficher la capacité de mémoire supplémentaire de la VM, cliquez sur VM > Allocation des ressources > Mémoire > Capacité de mémoire supplémentaire.
  Le problème est résolu dans cette version.
  
  
• 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 VM Windows échoue et affiche un écran bleu.
  
  
• Tailles de mémoire dans les paramètres par défaut des VM 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 VM 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 ESXi 4.1, le logiciel client DOS peut ne pas démarrer une VM
  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 lors du démarrage d'ESXi
  Les messages d'avertissement comme suit peuvent apparaître dans /var/log/messages lorsqu'un hôte ESXi démarre :
  AVERTISSEMENT : AcpiShared : 194 SSDTd+ : Longueur table 11108 > 4096
  Cet avertissement est généré lorsqu'un hôte ESXi 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.

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

• Mise à jour vers la version Tomcat
  Tomcat est mis à jour vers la version 6.0.28, ce 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.
  
  
• 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 VM 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 VM 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.
  
  
• 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.
  
  
• Les machines des hôtes ESXi ayant plus de 64 Go de mémoire ne démarrent pas lorsque le démarrage de confiance est activé
  Les machines des hôtes ESXi 4.1 ayant plus de 64 Go de mémoire ne peuvent pas démarrer si le TPM (Trusted Platform Module) et le TXT (Trusted Execution Technology) sont disponibles et activés à partir du BIOS. Ce problème est résolu dans cette version.

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

• ESXi peut échouer sur les systèmes HP avec une erreur de chargement de 32.networking-drivers
  ESXi peut échouer sur certains systèmes HP tels que DL 980 G7 contenant des adaptateurs de serveurs gigaoctet à deux ports 10GbE HP NC522SFP et affiche un message comme suit chargement de 32.networking-drivers . Ce problème survient lorsqu'ESXi démarre le pilote NetXen, le plus souvent lors du démarrage des hôtes ESXi 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 ESXi.

• 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é à ESXi mais fourni séparément en téléchargement. Dans cette version, le pilote e1000e v1.1.2 est intégré à ESXi.  

• 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 ESXi 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 ESXi peut souvent se déconnecter du réseau.
  • L'hôte ESXi 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 ESXi 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  
    
    

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

Configuration des serveurs

• L'horloge du système indique une heure inexacte
  Dans de rares cas, l'horloge du système sur les hôtes ESXi indique une heure incorrecte. Ce 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 du système générale est survenue : É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 ESXi 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 ESXi : 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 ESXi 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 ESXi. 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 ESXi 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 ESXi, si le paramètre tcp.window.size est modifié par une valeur inférieure à sa valeur par défaut.

• Les hôtes ESXi peuvent échouer lorsque vous utilisez LSI SAS HBA connectés à des disques SATA
  La perte de données peut survenir sur les hôtes ESXi 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 à ESXi 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 PVSCSI
  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 VM 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 ESXi
  Le graphique de consommation d'énergie accessible à partir de vSphere Client pour les hôtes 4.1 de l'hôte ESXi n'apparaît pas sur plusieurs hôtes ESXi 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.
  
  
• Améliorations du rapport et de la gestion des erreurs Tboot et SINIT
  Si Tboot n'arrive pas à démarrer un hôte ESXi en mode sécurisé, une erreur comme suit s'affiche :
  Échec du démarrage Intel TXT lors d'une tentative de démarrage précédente. TXT.ERRORCODE:<error code>. <description>
  Le problème est résolu dans cette version.

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 ESXi, 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 ESXi.
  
  
• Lorsque vous redémarrez un hôte ESXi après une mise à niveau réussie vers la version 4.1, un message d'erreur apparaît †
  Lorsque vous redémarrez un hôte ESXi après une mise à niveau réussie par l'utilitaire vihostupdate, le message d'erreur suivant peut apparaître : La nouvelle image de mise à niveau semble corrompue, risque d'échec. Cela se produit uniquement lorsque vous effectuez une mise à niveau à partir des versions ESXi 4.0 ou 4.0 Update 1 vers la version ESXi 4.1. Cela ne s'applique pas aux mises à niveau à partir d'ESXi 4.0 Update 2.
  
  
• Les paramètres du serveur DNS sont perdus après le second démarrage d'ESXi†
  Une fois ESXi installé à l'aide de la méthode d'installation de script, les paramètres du serveur DNS sont perdus lorsque ESXi démarre pour la deuxième fois. Les paramètres sont corrects après le premier démarrage suivant l'installation mais sont perdus après le deuxième redémarrage. Ce problème est résolu dans cette version.
  
  
• Impossible d'installer ESXi 4.1 en utilisant une installation scriptée à partir d'un périphérique USB
  Lorsque vous essayez d'installer ESXi 4.1 en utilisant le script enregistré sur un périphérique USB ou si le support d'installation est sur un périphérique USB, l'installation d'ESXi4.1 s'arrête et affiche le message suivant :
  Nombre total de secteurs pas un multiple des secteurs par suivi !
  Ajoutez le fichier mtools_skip_check=1 au fichier .mtoolsrc pour ignorer ce test.
  Le problème est résolu dans cette version.
  
  

Gestion des VM

• Les VM ne se mettent pas sous tension dans certains cas, même lorsqu'il existe un espace d'échange sur les hôtes ESXi 4.1
  La mise sous tension de la VM fonctionnant sur les hôtes ESXi 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 VM lorsqu'il existe un espace d'échange sur les hôtes ESXi 4.1.

• Après la migration d'une VM, 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 VM vers un hôte de destination qui comprend des périphériques USB et l'ajout de périphériques supplémentaires USB à la VM 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 VM Windows 64 bits en état interrompu peut provoquer l'échec de la VM
  Si une VM Windows 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 ESXi 4.1, la VM 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 ESXi 3.5
  Les hôtes ESXi ne peuvent pas restaurer un ancien snapshot après une mise à niveau d'ESXi 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 VM sur les hôtes ESXi 3.0. Exécutez vMotion et suspendez les VM sur les hôtes ESXi 3.5. Puis, reprenez-les sur les hôtes ESXi 4.x. Dans cette version, le message d'erreur n'apparaît pas. Vous pouvez restaurer des snapshots créés sur les hôtes ESXi 3.5 et reprendre les VM sur les hôtes ESXi 4.x.

• Le fichier d'échange d'une VM augmente en taille à la fin de Storage VMotion
  Lorsqu'une VM 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 VM 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 VM
  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 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 ESXi exécutent Storage VMotion, la taille du fichier d'échange des VM augmente à memsize. Avec ce correctif, la taille du fichier d'échange reste la même après Storage VMotion.
• Les hôtes ESXi peuvent échouer lorsque la tâche Storage VMotion est annulée durant le déplacement d'une VM mise sous tension
  L'annulation de la tâche Storage vMotion durant le déplacement d'une VM 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 ESXi 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 VM 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 désactivé 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.  

Début de la page

Problèmes connus

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

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

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

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 ESXi 4.1 ne définit pas le type de paramètre de la méthode dans le fichier XML du flux socket qui est généré.
  
  Voici quelques suggestions de solutions :
  • IBM met à jour la version CIMOM
  • IBM corrige la version CIMOM avec ce correctif
  • IBM utilise sa propre version de la bibliothèque SFCC

Système d'exploitation client

• 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 VM à 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 VM. 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 VM version 7 *
  Lorsque vous installez Windows NT 3.51 dans une VM 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 VM 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 VM avec la version 4 du matériel puis vous l'avez mise à niveau vers la version 7 du matériel, utilisez VMware vCenter Converter pour déclasser la VM vers la version 4 du matériel.

• 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 le suivi de l'hôte ESXi. 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-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 kernel pour id périphérique 1022:7409 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
  mappage pilote noyau pour id périphérique 1022:7411 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
  mappage pilote noyau pour id périphérique 1022:7441 dans /etc/vmware/pciid/pata_amd.xml en conflit avec la définition pour inconnu
  
  Ce problème survient lorsque les fichiers périphériques-descripteurs de plateforme et les fichiers du descripteur pilote spécifiques contiennent des descriptions pour le même périphérique.
  
  Solution : Vous pouvez ignorer ce message d'avertissement.

• Échec de l'ajout de l'hôte d'ESXi 4.1 Update 1 Embedded dans Cisco Nexus 1000V version 4.0 (4) SV1 (3a)
  Vous pourriez ne pas être en mesure d'ajouter l'hôte d'ESXi 4.1 Update 1 Embedded à une version 4.0(4) SV1(3a) de Cisco Nexus 1000V par vCenter Server.
  
  Solution
  Pour ajouter un hôte ESXi 4.1 Update 1 Embedded dans Cisco Nexus 1000V version 4.0(4) SV1(3a), utilisez l'utilitaire vihostupdatepour appliquer le bundle VEM sur les hôtes ESXi.
  Effectuez les étapes suivantes pour ajouter un hôte ESXi 4.1 Update 1 Embedded :
  1. Configurez Cisco Nexus 1000V version 4.0(4)SV1(3a).
  2. Configurez vCenter Server avec le plug-in VUM installé.
  3. Connectez Cisco Nexus 1000V version 4.0(4)SV1(3a) à vCenter Server.
  4. Créez un centre de données et ajoutez l'hôte ESXi 4.1 Update 1 embedded à vCenter Server.
  5. Ajoutez ESXi 4.1 Update 1 compatible AV.2 VEM bits à un hôte ESXi en exécutant la commande suivante à partir de vSphere CLI :
     vihostupdate.pl --server <Server IP> -i -b <VEM offline metadata path>
     Les messages suivants seront affichés sur la console de service :
     Entrez le nom d'utilisateur :
     Entrez le mot de passe :
     Veuillez patientez, installation des correctifs en cours...
  6. Après la mise à jour des correctifs, naviguez sur Afficher mise en réseau dans vCenter Server et ajoutez l'hôte à Cisco Nexus 1000V version 4.0(4)SV1(3a).
  7. Vérifiez que l'hôte ESXi 4.1 Update 1 a été ajouté à Cisco Nexus 1000V version 4.0(4)SV1(3a).

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 VM effectuent des E/S des réseaux.

• 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 du délai de chargement de module disable_lro=1 du pilote Linux VMXNET 2 ou VMWNET 3.

• 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 VM 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 VM *
  La reconfiguration de NIC VMXNET3 alors que Wake-on-LAN est activé et que la VM est endormie permet à la VM de reprendre.
  
  Solution : Remettez manuellement la VM en mode veille après la reconfiguration (par exemple, après avoir effectué un ajout à chaud ou une suppression à chaud) d'un VMXNET3 vNIC.

Stockage

• Grand nombre de messages relatifs au stockage dans le fichier journal VMkernel *
  Lorsque ESXi 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 ESXi*
  Vous pouvez connaître un temps d'attente conséquent lors du démarrage des hôtes partageant des 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

• ESXi peut ne pas démarrer lorsque l'option de démarrage allowInterleavedNUMANodes est FALSE
  Sur un hôte IBM eX5 avec une extension MAX 5, 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 ESXi.

• 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 ESXi 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 ESXi.
  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 VM 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 VM 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 VM à 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.

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

• 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 correct.
  
  Solution : Aucune.

• Ralentissement des performances au cours de la mise sous tension de la VM ou l'E/S du disque sur ESX sur la plate-forme 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 VM ou de la génération l'E/S du disque. Le symptôme majeur est la performances d'E/S dégradée, causant l'enregistrement d'un grand nombre de messages d'erreur 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.

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 vSphere Client, 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 la mise à niveau des hôtes exécutant ESXi 4.0.x vers ESXi 4.1 peut échouer *
  La correction de la mise à niveau des hôtes peut échouer en raison de l'impossibilité de régé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 ESXi 4.0.x qui a rencontré ce problème, installez le bundle de mise à niveau manuellement en utilisant l'utilitaire de ligne de commande.
  
  
• L'accès simultané à deux installations ESXi sur des lecteurs flash USB entraîne l'affichage par le système de messages de panique
  Si vous démarrez un système qui a accès à plusieurs installations ESXi avec le même numéro de version sur deux lecteurs flash USB, le système affiche des messages de panique.
  
  Solution : Détachez un des lecteurs flash USB et redémarrez le système.

vMotion et Storage vMotion

• VMotion est désactivé après un redémarrage de l'hôte ESXi 4.1
  Si vous activez vMotion sur un hôte ESXi et redémarrez l'hôte ESXi, vMotion n'est plus activéune fois le processus de redémarrage terminé.
  
  Solution : Pour résoudre ce problème, réinstallez la dernière version de l'image ESXi fournie par votre fournisseur de systèmes.
  
  
• Les connexions à chaud échouent après le déplacement du fichier d'échange *
  Les connexions à chaud échouent pour les VM mises sous tension dans un cluster DRS, ou sur un hôte autonome, et signalent une erreur Échec de 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 VM 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