ESXi 5.0 Update 2 | 20 décembre 2012 | Build 914586

Dernière mise à jour : 11 janvier 2013

Contenu des notes de mise à jour

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

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

  • Prise en charge des systèmes d'exploitation clients supplémentaires. Cette version ajoute la prise en charge des systèmes d'exploitation clients Solaris 11, Solaris 11.1 et Mac OS X Server Lion 10.7.5.
    Pour obtenir la liste complète des systèmes d'exploitation clients pris en charge avec cette version, reportez-vous au Guide de compatibilité VMware.

  • Problèmes résolus. Cette version offre un certain nombre de correctifs de bogues qui ont été documentés dans la section Problèmes résolus.

Versions antérieures d'ESXi 5.0

Les fonctions et problèmes connus d'ESXi 5.0 sont décrits dans les notes de mise à jour de chaque version. Pour consulter les notes de mise à jour antérieures d'ESXi 5,0, cliquez sur l'un des liens suivants :

Internationalisation

VMware vSphere 5.0 Update 2 est disponible dans les langues suivantes :

  • Anglais
  • Français
  • Allemand
  • Japonais
  • Coréen
  • Chinois simplifié

Mode localisation forcée de vSphere Client

Avec vSphere 5.0 Update 2, vous pouvez configurer VMware vSphere Client pour fournir l'interface textuelle en anglais, même si la machine sur laquelle il est exécuté n'est pas en anglais. Vous pouvez régler cette configuration pour la durée d'une seule session en utilisant un commutateur à ligne de commande. Cette configuration s'applique au texte de l'interface et n'affecte pas les autres paramètres de langue comme les formats horaires ou numériques.

Par exemple, la commande vSphere Client suivante affichera la session individuelle en anglais :

vpxClient -locale en_US

Compatibilité et installation

Compatibilité de version ESXi, vCenter Server et vSphere Client

La Matrice d'interopérabilité des produits VMware fournit des détails sur la compatibilité des versions en cours et précédentes des composants VMware vSphere, dont ESXi, VMware vCenter Server, vSphere Client et les produits VMware facultatifs. Consultez également le présent site pour des informations sur les agents de gestion et de sauvegarde pris en charge avant d'installer ESXi ou vCenter Server.

vSphere Web Client et vSphere Client sont intégrés au fichier ZIP qui comprend vCenter Server et les modules. Vous pouvez installer un client ou les deux à partir de l'assistant d'installation de VMware vCenter™.

Compatibilité ESXi, vCenter Server et VDDK

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


Compatibilité matérielle pour ESXi

Pour savoir quels processeurs, périphériques de stockage, baies SAN et périphériques E/S sont compatibles avec vSphere 5.0 Update 2, consultez les informations ESXi 5.0 Update 2 du Guide de compatibilité de VMware.

Mises à niveau et installations des CPU pris en charge. vSphere 5.0 Update 2 prend en charge uniquement les CPU disposant des jeux d'instructions LAHF et SAHF. Au cours d'une installation ou d'une mise à niveau, le programme d'installation vérifie la compatibilité du CPU hôte avec vSphere 5.0 Update 2. Pour la prise en charge de CPU, voir le Guide de compatibilité de VMware.

Compatibilité des systèmes d'exploitation clients pour ESXi

Pour déterminer quels systèmes d'exploitation clients sont compatibles avec vSphere 5.0 Update 2, consultez les informations sur ESXi 5.0 Update 2 dans le Guide de compatibilité de VMware.

Compatibilité des machines virtuelles pour ESXi

Les machines virtuelles avec des versions de matériel virtuel 4.0 et ultérieures sont prises en charge avec ESXi 5.0 Update 2. La version matérielle 3 n'est plus prise en charge. Pour utiliser des machines virtuelles équipées de la version matérielle 3 sur ESXi 5.0 Update 2, mettez le matériel virtuel à niveau. Reportez-vous à la documentation de Mise à niveau vSphere.

Notice d'installation pour cette version

Lisez la documentation Installation et configuration de vSphere qui explique dans le détail l'installation et la configuration d'ESXi et de vCenter Server.

Après une installation réussie, vous devez procéder à la configuration de l'octroi de licences, la mise en réseau et la sécurité. Pour des informations sur ces tâches de configuration, reportez-vous aux guides suivants de la documentation vSphere.

 

Migration de solutions tierces

Les hôtes ESX/ESXi peuvent contenir des logiciels tiers, comme les modules VEM Cisco Nexus 1000V ou EMC PowerPath. L'architecture d'ESXi 5.0 change de celle d'ESX/ESXi 4.x afin qu'il soit impossible de migrer des logiciels tiers personnalisés (VIB) quand vous effectuez une mise à niveau de la version ESX/ESXi 4.x à la version ESXi 5.0.
Lorsque vous mettez un hôte 4.x à niveau avec des VIB personnalisés qui ne figurent pas dans l'ISO de la mise à niveau, vous pouvez poursuivre la mise à niveau, mais vous recevrez un message d'erreur répertoriant les VIB qui manquent. Pour réussir la mise à niveau ou la migration de tels hôtes, vous devez utiliser Image Builder et créer une image ESXi ISO sur mesure qui inclut les VIB manquants. Pour effectuer une mise à niveau sans inclure le logiciel tiers, utilisez l'option ForceMigrateou sélectionnez l'option pour supprimer les modules logiciels tiers pendant le processus de correction dans vSphere Update Manager. Pour plus d'informations sur l'utilisation d'Image Builder pour créer une image ISO sur mesure, consultez la documentation Installation et configuration de vSphere. Pour plus d'informations sur la mise à niveau avec des personnalisations tierces, consultez la documentation Mise à niveau vSphere et Installation et administration de VMware vSphere Update Manager. Pour plus d'informations sur la mise à niveau avec vSphere Update Manager, consultez la documentation Mise à niveau vSphere et Installation et administration de VMware vSphere Update Manager.

Accès au stockage NFS routé par commutateur L3

vSphere 5.0 Update 2 prend en charge l'accès au stockage NFS routé par commutateur L3, si votre environnement répond aux conditions suivantes :
  • Utiliser le protocole Hot Standby Router (HSRP) de Cisco dans le routeur IP. Si vous utilisez un routeur non-Cisco, assurez-vous d'utiliser à la place le protocole Virtual Router Redundancy Protocol (VRRP).
  • Utiliser la qualité de service (QoS) pour accorder la priorité au trafic NFS L3 sur les réseaux avec des bandes passantes limitées, ou sur les réseaux encombrés. Consultez la documentation de votre routeur pour de plus amples détails.
  • Respectez les meilleures pratiques pour l'accès à NFS routé par commutateur L3 recommandées par votre fournisseur de stockage. Contactez votre fournisseur de stockage pour plus d'informations.
  • Désactiver Network I/O Resource Management (NetIORM)
  • Si vous prévoyez d'utiliser des systèmes avec des commutateurs en haut de baie ou un partitionnement de périphérique d'E/S dépendant d'un commutateur, contactez le fournisseur du système pour la compatibilité et la prise en charge.
Dans un environnement L3, les restrictions supplémentaires suivantes s'appliquent :
  • L'environnement ne prend pas en charge VMware Site Recovery Manager.
  • L'environnement prend en charge uniquement le protocole NFS. N'utilisez pas d'autres protocoles de stockage comme FCoE sur le même réseau physique.
  • Le trafic NFS dans cet environnement ne prend pas en charge IPv6.
  • Le trafic NFS dans cet environnement peut être routé uniquement sur un réseau local. Les autres environnements comme les réseaux WAN ne sont pas pris en charge.
  • L'environnement ne prend pas en charge le commutateur virtuel distribué (DVS).

Mises à niveau pour cette version

Pour des explications sur comment mettre à niveau vCenter Server et les hôtes ESXi, consultez la documentation Mise à niveau vSphere.

Mise à niveau de VMware Tools

VMware ESXi 5,0 Update 2 contient la version la plus récente 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).

Mises à niveau ESX/ESXi

Il existe plusieurs manières de mettre à niveau les hôtes ESX/ESXi vers ESXi 5.0 Update 2.

  • vSphere Update Manager. Si votre site utilise vCenter Server, effectuez une mise à niveau orchestrée des hôtes ou des machines virtuelles au moyen de vSphere Update Manager depuis ESX/ESXi 4.0, 4.1 et ESXi 5.0. Consultez les explications dans la documentation Mise à niveau vSphere, ou pour des explications exhaustives à propos de vSphere Update Manager, consultez la documentation Installation et administration de VMware vSphere Update Manager.

  • Mise à niveau interactive au moyen d'une image ISO du programme d'installation d'ESXi sur un CD-ROM ou un DVD. Vous pouvez exécuter le programme d'installation d'ESXi 5.0 Update 2 depuis un lecteur de CD-ROM ou DVD et procéder ainsi à une mise à niveau interactive. Cette méthode convient si la mise à niveau concerne un petit nombre d'hôtes.

  • Exécution d'une mise à niveau scriptée. Vous pouvez mettre à niveau ou migrer les hôtes depuis ESXi/ESX 4.x vers ESXi 5.0 Update 2 en exécutant un script de mise à jour ; ainsi la mise à niveau s'effectue efficacement, sans assistance. Les mises à niveau scriptées constituent un moyen efficace pour déployer plusieurs hôtes. Vous pouvez utiliser un script pour mettre à niveau ESXi à partir d'un CD-ROM ou d'un DVD, ou en effectuant un démarrage PXE du programme d'installation.

  • ESXCLI : Vous pouvez mettre à jour et appliquer des correctifs aux hôtes ESXi 5.x en utilisant l'utilitaire de ligne de commande esxcli. Vous ne pouvez pas utiliser esxcli pour mettre à niveau les hôtes ESX/ESXi 4.x vers ESXi 5.0 Update 2.
Chemins d'accès de mise à niveau pris en charge pour la mise à niveau vers ESXi 5.0 Update 2 :

Produits livrables de mise à niveau

Outils de mise à niveau pris en charge

Chemins d'accès de mise à niveau pris en charge vers ESXi 5,0 Update 2

ESX 4.0 :
Inclut
ESX 4.0 Update 1
ESX4.0 Update 2

ESX4.0 Update 3
ESX 4.0 Update 4

ESXi 4.0:
Inclut
ESXi 4.0 Update 1
ESXi 4.0 Update 2

ESXi 4.0 Update 3
ESXi 4.0 Update 4

ESX 4.1 :
Inclut
ESX 4.1 Update 1
ESX 4.1 Update 2

ESX 4.1 Update 3

 

ESXi 4.1 :
Inclut
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0 :
Inclut
ESXi 5.0 Update 1

VMware-VMvisor-Installer-5.0.0.update02-914586.x86_64.iso

 

  • VMware vCenter Update Manager
  • Mise à niveau depuis un CD
  • Mise à niveau à base de script

Oui

Oui

Oui

Oui

Yes*

update-from-esxi5.0-5.0_update02.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • Interface de ligne de commande VMware vSphere

Non

Non

Non

Non

Oui

Utilisation de définitions de correctif téléchargées depuis le portail VMware (en ligne) VMware vCenter Update Manager avec ligne de base de correctifs

Non

Non

Non

Non

Oui

* Remarque : La mise à niveau d'ESXi 5.0 à l'aide de VMware-VMvisor-Installer-5.0.0.update02-914586.x86_64.isoavec VMware vCenter Update Manager n'est pas prise en charge. Vous devez effectuer la mise à jour à l'aide de update-from-esxi5.0-5.0_update02.zipavec VMware vCenter Update Manager.

Les SDK VMware vSphere

VMware vSphere propose un jeu de SDK pour vSphere Server et les environnements des systèmes d'exploitation clients.

  • vSphere Management SDK. Suite de kits de développement logiciel pour l'environnement de programmation vSphere Management. Le vSphere Management SDK contient les vSphere SDK suivants :

    • vSphere Web Services SDK. Inclut la prise en charge de nouvelles fonctionnalités disponibles dans les systèmes ESXi 5.0 et versions ultérieures et vCenter Server 5.0 et versions ultérieures. Vous pouvez également utiliser ce SDK avec les anciennes versions d'ESX/ESXi et vCenter Server. Pour plus d'informations, consultez la documentation VMware vSphere Web Services SDK.

    • vSphere vCenter Storage Monitoring Service (SMS) SDK. SMS 2.0 est pris en charge sur vCenter Server 5.0. Pour plus d'informations, consultez la documentation vCenter SMS SDK.

    • vSphere ESX Agent Manager (EAM) SDK. EAM 1.0 est pris en charge sur ESXi 5.0 Update 2. Pour plus d'informations, voir vSphere ESX Agent Manager.

  • vSphere Guest SDK. VMware vSphere Guest SDK 4.0 est pris en charge sur ESXi 5.0 Update 2. Pour plus d'informations, voir la Documentation sur VMware vSphere Guest SDK.

  • VMware vSphere SDK for Perl. Le SDK pour Perl 5.0 est pris en charge sur vSphere 5.0 Update 2. Pour plus d'informations, voir la Documentation sur vSphere SDK for Perl.

Composants en libre accès pour VMware vSphere

Les déclarations de copyright et les licences applicables aux composants de logiciels en libre accès distribués dans vSphere 5.0 Update 2 sont accessibles sur http://www.vmware.com/download/vsphere/open_source.html, sous l'onglet Open Source. Vous pouvez également télécharger les fichiers source pour une licence GPL, LGPL ou d'autres licences semblables pour lesquelles le code source ou les modifications du code source doivent être disponibles pour la dernière version généralement disponible de vSphere.

Correctifs contenus dans cette version

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

La version de correctifs ESXi500-Update02 contient les bulletins individuels suivants :

ESXi500-201212201-UG : Met à jour le fichier vib esx-base d'ESXi 5.0
ESXi500-201212202-UG : Met à jour le fichier net-igb vib d'ESXi 5.0
ESXi500-201212203-UG : Met à jour le fichier vib tools-light d'ESXi 5.0
ESXi500-201212204-UG : Met à jour le fichier net-ixgbe vib d'ESXi 5.0
ESXi500-201212205-UG : Met à jour le fichier esx-tboot vib d'ESXi 5.0
ESXi500-201212206-UG : Met à jour le fichier scsi-lpfc820 vibs d'ESXi 5.0
ESXi500-201212207-UG : Met à jour le fichier net-bnx2x vib d'ESXi 5.0
ESXi500-201212208-UG : Met à jour le fichier vib net-e1000e d'ESXi 5.0
ESXi500-201212209-UG : Met à jour le fichier vib misc-drivers d'ESXi 5.0
ESXi500-201212210-UG : Met à jour le fichier net-tg3 vib d'ESXi 5.0
ESXi500-201212211-UG : Met à jour le fichier ipmi-ipmi-si-drv vib d'ESXi 5.0


La version de correctifs ESXi500-Update02 Security-only contient les bulletins individuels suivants :

ESXi500-201212101-SG : Met à jour le fichier vib esx-base d'ESXi 5.0
ESXi500-201212102-SG : Met à jour le fichier tools-light vib d'ESXi 5.0

La version de correctifs ESXi500-Update02 contient les profils d'image suivants :

ESXi-5.0.0-20121202001-standard
ESXi-5.0.0-20121202001-no-tools

La version de correctifs ESXi500-Update02 Security-only contient les profils d'image suivants :

ESXi-5.0.0-20121201001s-standard
ESXi-5.0.0-20121201001s-no-tools


Pour des informations sur la classification des correctifs et des mises à jour, voir KB 2014447

Problèmes résolus

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

Pour connaître la liste des problèmes résolus pouvant se produire lors de la mise à niveau de vSphere 5.0 Update 2 vers vSphere 5.1, consultez l'article KB 2040662.

CIM et API

  • vSphere Client peut détecter un capteur d'alimentation non existant
    Avec certains systèmes ESXi, il est possible que le client vSphere affiche des informations relatives à une source d'alimentation qui n'existe pas.

    Cette version améliore la gestion des données de capteur du référentiel des données de capteur(SDR) IPMI pour résoudre ce problème.
  • Le journal d'événements système (SEL) est vide sur certains serveurs
    Il est possible que le journal d'événements système soit vide si ESXi 5.0.x est exécuté sur certains serveurs physiques.
    Les journaux IPMI de l'hôte ( /var/log/ipmi/0/sel) peuvent également être vides.
    Un message d'erreur similaire au suivant peut être consigné dans /var/log/messages:

    Dec 810:36:09 esx-200 sfcb-vmware_raw[3965]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff


    Ce problème est résolu dans cette version.
  • L'UUID SMBIOS signalé par les hôtes ESXi 5.0 peuvent être différents de l'UUID SMBIOS réel
    Si la version SMBIOS du système ESXi 5.0 est la version 6 ou une version ultérieure, il est possible que l'UUID SMBIOS signalé par l'hôte ESXi 5.0 soit différent de l'UUID SMBIOS réel. L'ordre des octets des 3 premiers champs de l'UUID n'est pas correct.

    Ce problème est résolu dans cette version.
  • Impossible de vérifier le nombre de descripteurs de fichiers ouverts des processus sfcb
    Cette version ajoute des entrées au journal pour vérifier le nombre maximum de descripteurs de fichiers ouverts des processus sfcb.
    Vous pouvez vérifier les limites des descripteurs de fichiers ouverts dans les journaux cim en suivant la procédure suivante :
    1. Définissez le niveau de journal CIM sur 6 en utilisant la commande # esxcfg-advcfg -s 6 /UserVars/CIMLogLevel
    2. Redémarrez le service sfcbd en utilisant la commande # /etc/init.d/sfcbd-watchdog restart.
    3. Vérifiez que le fichier journal dans le dossier /var/log/messagescontient des entrées similaires aux suivantes pour les limites maximales du descripteur de fichiers ouverts :
      sfcb-HTTP-Daemon[30847]: --- Limite du maximum de descripteurs de fichiers ouverts : limite conditionnelle - 512 limite inconditionnelle - 1024

Divers

  • L'utilitaire vm-support ne peut pas collecter la liste des tables de partition des volumes VMFS 5 à l'aide de fdisk -lu
    L'utilitaire vm-supporta été amélioré pour collecter les sorties pour partedUtil getptblet partedUtil getUsableSectors. Cela permet d'obtenir des informations relatives à la partition des volumes VMFS 5.

  • Le script vm-support ne collecte pas les informations de mappage de périphérique brut des fichiers VMDK
    Lorsque vous employez l'utilitaire vm-support, les informations de mappage de périphérique brut des fichiers VMDK de la machine virtuelle ne sont pas collectées.

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

  • Les visuels d'applications tierces sont corrompus lors de l'utilisation du pilote VMware SVGA 3D avec le mode 3D activé
    Lors de l'utilisation du pilote VMware SVGA 3D, si vous activez l'option 3D, les libellés de texte dans les zones de groupe sont écrasés par un cadre rectangulaire dans les applications WPF. Ce problème a été constaté dans Atlas Client s'exécutant dans les machines virtuelles hébergées sur ESXi.

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

  • Le lecteur de bandes IBM ULTRIUM-HH5 ne prend pas en charge les commandes SCSI avec un attribut ordonné défini
    Le lecteur de bandes IBM ULTRIUM-HH5 ne prend pas en charge les commandes SCSI avec un attribut ordonné défini et peut échouer avec un état de périphérique SCSI Check Condition and sense key 0x05/0x49/0x00 INVALID MESSAGE ERROR
    lorsque des commandes SCSI avec un attribut ordonné défini sont envoyées au lecteur.

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

  • Les appels API VDDK sous Windows ne parviennent pas à accéder aux disques virtuels volumineux à l'aide des noms de chemin UNC
    Lorsque vous tentez de lire un disque virtuel dont la taille est supérieure à 2 Go à l'aide des API VDDK sous Windows, les appels API peuvent échouer. Les journaux VDDK peuvent contenir des messages d'erreur similaires aux suivants :
    DISKLIB-LINK : "<UNC pathname>.vmdk" : failed to open (The file is too large).

    Ce problème est résolu dans cette version.
  • L'exécution des commandes esxcfg-info, esxcfg-resgrp -l ou vm-support provoque des messages d'erreur dans les fichiers journaux
    Lorsque vous exécutez les commandes esxcfg-info, esxcfg-resgrp -l, ou vm-supportsur un hôte ESXi en utilisant ESXi Shell ou SSH, des messages d'erreur similaires aux suivant peuvent être consignés dans le fichier syslog.log :

    2012-08-01T09:40:12Z esxcfg-info: ResourceGroup: Skipping CPU times for : Vcpu Id 11777 Times due to error. max # of processors: 4 < 11777

    2012-07-03T00:57:28Z esxcfg-resgrp: ResourceGroup: Skipping CPU times for : Vcpu Id 55340 Times due to error. max # of processors: 1 < 55340

    Ce problème n'a aucun impact sur le fonctionnement des machines virtuelles en cours d'exécution.

    Ce problème est résolu dans cette version.
  • L'option délai d'attente ne fonctionne pas lorsque vous réactivez ESXi Shell et SSH
    Si vous avez défini une valeur différente de zéro pour SSH et ESXi Shell, ces derniers sont désactivés lorsque la valeur du délai d'attente a été atteinte. Cependant, si vous réactivez SSH ou ESXi Shell sans modifier le paramètre du délai d'attente, SSH et ESXi Shell n'appliquent pas le délai d'attente.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi échoue avec un écran de diagnostic violet lorsque vous tentez de brancher ou débrancher un clavier ou une souris via un port USB
    Lorsque vous tentez de brancher ou débrancher un clavier ou une souris via le port USB, l'hôte ESXi échoue avec le message d'erreur suivant :
    PCPU## locked up. Failed to ack TLB invalidate.

    Pour plus d'informations, voir KB 2000091.

    Ce problème est résolu dans cette version.
  • La synchronisation NTP peut échouer sur le système d'exploitation client Solaris 10
    Cette version ajoute la prise en charge du Calibrage du temporisateur client pour les systèmes d'exploitation clients Solaris 10, ce qui permet au système d'exploitation client de mesurer correctement le TSC dans la tolérance de NTP.

    Cette mise à jour résout le problème de synchronisation NTP.
  • L'hôte ESXi 5.0 échoue en raison d'une fuite de mémoire du connecteur universel
    Lorsque l'hôte ESXi tente de créer un tas de groupes universel sans libérer la mémoire associée au connecteur universel, le processus échoue en raison d'une fuite de mémoire du connecteur universel.

    Ce problème est résolu en libérant la mémoire associée au connecteur universel.

  • L'hôte ESXi échoue lors de la réplication suspendue
    Lorsqu'une machine virtuelle est configurée pour la réplication et qu'elle passe par une transition d'état, le gestionnaire HBR (Host Based Replication, réplication basée sur l'hôte) s'attend à ce que tous les disques des machines virtuelles aient le même état de suspension. Cependant, si la machine virtuelle possède plus d'un disque, et si certains disques ont fini la réplication alors que d'autres sont encore en cours de réplication, ce ne sera peut-être pas vrai. Dans ce cas, HBR établit cette condition de façon incorrecte et provoque un échec de l'hôte ESX.

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

  • Messages d'erreur erronés dans le journal Hostd lorsque vous attribuez une licence vRAM VMware vSphere Hypervisor à un hôte ESXi avec une pRAM supérieure à 32 Go
    Lorsque vous tentez d'attribuer une clé de licence vRAM VMware vSphere Hypervisor Edition à un hôte ESXi ayant une taille de RAM physique supérieure à 32 Go, l'hôte ESXi peut consigner des messages d'erreur erronés similaires au suivant pour /var/log/vmware/hostd :
    2012-08-08T16:39:18.593Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MaxRam value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MaxRamPerCpu value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse MinRamPerCpu value:
    2012-08-08T16:39:18.594Z [2AA78B90 error 'Default' opID=HB-host-84@121-9c61c8e-a8] Unable to parse vram value:


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

  • La fonction CreateTemporaryFile InGuest() peut entraîner une exception GuestPermissionDeniedFault
    Lorsque vous reconfigurez une machine virtuelle sous tension pour ajouter un contrôleur SCSI et que vous tentez de créer un fichier temporaire dans le système d'exploitation client, l'opération peut échouer avec une exception GuestPermissionDeniedFault.

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

  • Le vidage de mémoire réseau de vSphere ne collecte pas les données complètes
    Le vidage de mémoire réseau de vSphere ne collecte pas les données complètes si le vidage de disque ne parvient pas à collecter certaines données en raison d'une taille de slot de vidage insuffisante.

    Ce problème est résolu dans cette version. Plus aucune défaillance due à la taille du slot de vidage de disque n'affectera le vidage de mémoire réseau.

  • Les machines virtuelles exécutant le système d'exploitation client Windows sur un hôte ESXi avec vShield Endpoint peuvent échouer avec un écran bleu
    Un appel API erroné dans vShield Endpoint driver vsepflt.syspeut faire échouer les machines virtuelles exécutant le système d'exploitation client Windows avec un écran de diagnostic bleu.
      
    Ce problème est résolu dans cette version.

Mise en réseau

  • L'hôte ESXi avec 1 024 dvPorts environ ne répond plus
    Lorsqu'un hôte ESXi utilise plus de 1 024 dvPorts environ, il ne répond plus.
    Les messages d'avertissement suivants apparaissent dans le fichier journal vmkwarning :
    WARNING: Heap: 2639: Heap dvsLargeHeap (65582032/67108864): Maximum allowed growth (1527808) too small for size (3719168)
    WARNING: Heap: 2900: Heap_Align(dvsLargeHeap, 3715488/3715488 bytes, 8 align) failed. caller: 0x418025d29338


    Ce problème est résolu dans cette version en augmentant la taille maximale par défaut du dvsLargeHeapet en ajoutant une option de configuration avancée (DVSLargeHeapMaxSize) pour permettre aux administrateurs d'augmenter encore davantage la taille maximale du dvsLargeHeap.

  • L'hôte ESXi peut ne plus répondre avec un écran violet si le MTU est changé à plusieurs reprises
    Le fait de changer le MTU plusieurs fois peut entraîner l'épuisement de netGPHeap et une fuite de mémoire, provoquant l'échec de l'hôte ESXi avec un écran violet suite à un problème avec le pilote async ixgbeIntel.

    Le fichier vmkernel.logpeut contenir des messages d'épuisement de la mémoire similaires au suivant :
    WARNING: Heap: 2525: Heap netGPHeap already at its maximum size. Cannot expand
    WARNING: Heap: 2900: Heap_Align(netGPHeap, 8192/8192 bytes, 64 align) failed. caller: 0x41802c10a03f
    WARNING: NetPort: 1244: failed to enable port 0x2000002: Out of memory
    NetPort: 1426: disabled port 0x2000002
    Uplink: 5240: vmnic2: Failed to enable the uplink port 0x2000002: Out of memory
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 1
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 2
    <3>ixgbe: vmnic2: ixgbe_alloc_tx_queue: allocated tx queue 3 <6>ixgbe 0000:03:00.0: vmnic2: changing MTU from 9000 to 1500


    Ce problème est résolu dans cette version.
  • Après que les sessions DVMirror ont été reconfigurées, le mode promiscuité peut ne pas fonctionner comme il le devrait.
    Sur un Dvportgroup, un port de promiscuité peut ne pas fonctionner en mode de promiscuité si les sessions DVMirror sont reconfigurées.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi peut échouer avec un écran de diagnostic violet à Kseg_ReleaseVA() ou Kseg_ReleasePtr() avec un « va » ou un pointeur NULL
    Un hôte ESXi peut échouer avec un écran de diagnostic violet à Kseg_ReleaseVA() ou Kseg_ReleasePtr() avec un « va » ou un pointeur NULL en raison d'un chemin de code de gestion d'exception incorrect dans la pile réseau d'ESXi.

    Ce problème est résolu dans cette version.
  • La virtualisation IP des services Bureau à distance peut ne pas fonctionner sous Windows Server 2008 R2 exécuté sur vSphere 4.0 Update 1
    La virtualisation IP, qui vous permet d'allouer des adresses IP uniques aux sessions RDP, peut ne pas fonctionner sur une machine virtuelle Windows Server 2008 R2 64 bits s'exécutant sur vSphere 4.0 Update 1. Cependant, la virtualisation IP fonctionne lorsque vous configurez les services Bureau à distance sur une machine physique sous Windows Server 2008 R2, ou si vous exécutez une machine virtuelle sous Windows Server 2008 R2 sur XenServer 5.5 Update 2 Dell OEM Edition.
    Ce problème peut survenir si vous installez VMware Tools après avoir installé les services Bureau à distance.

    Ce problème est résolu dans cette version.
  • Un grand nombre de paquets UDP est rejeté lorsque vous utilisez l'adaptateur VMXNET3
    Un grand nombre de paquets UDP est rejeté lorsque vous utilisez l'adaptateur VMXNET3 avec un système d'exploitation Linux client installé sur un hôte ESXi 5.0.

    Ce problème est résolu dans cette version.
  • La machine virtuelle RHEL 6 configurée avec des périphériques RDM par l'intermédiaire d'un adaptateur PVSCSI peut rencontrer un échec des E/S
    La machine virtuelle RHEL 6 configurée avec des périphériques RDM (mappage de périphérique brut) via un adaptateur SCSI paravirtualisé (PVSCSI) peut rencontrer un échec des E/S après une réinitialisation du bus sur des périphériques RDM. Au cours de la réinitialisation, l'adaptateur PVSCSI retourne DID_RESET et la couche SCSI Linux essaie à nouveau la commande.

    Ce problème est résolu dans cette version.
  • La bande passante réseau n'est pas équitablement partagée entre les machines virtuelles d'un pool de ressources réseau
    La bande passante réseau n'est pas attribuée équitablement à l'ensemble des machines virtuelles d'un pool de ressources réseau en raison de limitations dans la mise en œuvre actuelle.

    Ce problème est résolu dans cette version. L'algorithme amélioré alloue de manière optimale la bande passante à toutes les machines virtuelles partageant le même pool de ressources réseau.
  • Netdump échoue lors de la collecte de vidages de mémoire après l'apparition d'un écran de diagnostic violet
    Netdump échoue lors de la collecte de vidages de mémoire après l'apparition d'un écran violet si l'option de sécurité de vSwitch Modifications d'adresses MAC est définie sur Rejeter.

    Ce problème est résolu dans cette version.
  • Lorsque vous désactivez la suspension sur ESXi, l'hôte échoue avec un écran violet
    Dans ESXi, lorsque VMXNET3 est utilisé en tant que vNIC dans certaines machines virtuelles et que vous désactivez la suspension de paquets, l'hôte ESXi peut échouer avec un écran violet lorsque la machine virtuelle démarre.

    Ce problème a été résolu dans cette version en corrigeant la vérification de la suspension et la logique d'assertion.
  • La connectivité réseau à une machine virtuelle configurée pour utiliser IPv6 peut échouer après l'installation de VMware Tools
    La connectivité réseau à certains systèmes d'exploitation clients avec la version 2.6.34 du noyau ou une version ultérieure, et configurée pour utiliser IPv6, peut ne pas fonctionner après avoir installé VMware Tools.

    Ce problème est résolu dans cette version.
  • Il est possible que vSphere Client n'affiche pas les adresses IPv6 sous certains systèmes d'exploitation clients Linux
    Sous les systèmes d'exploitation Linux clients qui ne sont pas configurés avec des adresses IPv4, il est possible que les adresses IPv6 ne s'affichent pas dans vSphere Client. C'est aussi le cas lorsque vous utilisez la commande vmware-vim-cmd.

    Ce problème est résolu dans cette version.
  • Le serveur IBM échoue avec un écran de diagnostic violet lors d'une tentative d'injection de paquets à chemin lent
    Si les métadonnées associées au paquet à chemin lent sont copiées sans vérifier qu'une quantité suffisante de données est mappée, les métadonnées se déplacent dans une zone non mappée, provoquant un défaut de page.

    Ce problème est résolu dans cette version.
  • Le délai de connexion de l'initiateur iSCSI n'est pas hérité dans ESXi 5.0 Update 1
    La valeur du délai de la connexion de l'initiateur iSCSI doit être héritée pour la phase de découverte. Ceci ne se produit pas dans ESXi 5.0 Update 1.

    Ce problème est résolu dans cette version.
  • Les opérations vMotion de longue durée peuvent provoquer une saturation monodiffusion
    Lors de l'utilisation de la fonction multiple-NIC vMotion avec vSphere 5, si les opérations vMotion se poursuivent pendant une longue durée, on observe une saturation monodiffusion sur toutes les interfaces du commutateur physique. Si l'opération vMotion dure au-delà du temps de la table d'adresses MAC, l'hôte source et l'hôte de destination commencent à recevoir un trafic réseau volumineux.

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

  • Si VMXNET 3 est utilisé en tant que carte réseau virtuelle, la traduction d'adresses réseau (NAT) sur Windows Server 2008 R2 peut ne pas fonctionner
    Si vous tentez d'accéder à Internet via le serveur NAT sur un système d'exploitation Windows Server 2008 R2 avec deux cartes réseau VMXNET 3 virtuelles, le serveur NAT peut ne pas fonctionner.

    Ce problème est résolu dans cette version.
  • Les NIC physiques réglés sur Négociation automatique ne peuvent pas être modifiés en Fixe en utilisant les profils d'hôte si les mêmes paramètres de vitesse et de duplex sont présents
    Les profils d'hôte vérifient la conformité de la vitesse et du duplex d'un NIC physique. Si la vitesse et le duplex d'un NIC physique d'un hôte ESXi correspondent à ceux du profil d'hôte, l'hôte ESXi apparaît conforme, même si le NIC physique est défini sur Négociation automatique et le profil d'hôte sur Fixe. En outre, les NIC physiques définis sur Négociation automatique ne peuvent pas être modifiés en Fixe en utilisant les profils d'hôte si les paramètres de vitesse et de duplex de l'hôte ESXi et du profil d'hôte sont identiques.

    Ce problème est résolu dans cette version.
  • Met à jour le pilote tg3 vers la version 3.123b.v50.1
    La version du pilote intégré tg3 livrée avec ESXi 5.0 Update 2 est la version 3.123b.v50.1.

Sécurité

  • Mise à jour de la bibliothèque libPNG
    La bibliothèque libPNG a été mise à jour vers libpng-1.2.49. La version Libpng-1.2.49 contient un correctif de sécurité. Aucun produit VMware n'est concerné par ce problème.
    Le projet Common Vulnerabilities and Exposures ( cve.mitre.org) a attribué le nom CVE-2011-3048 à ce problème.

Configuration des serveurs

  • L'application d'un profil d'hôte peut provoquer l'affichage d'un message d'avertissement inutile
    Après avoir appliqué un profil d'hôte dont le pare-feu ESXi est activé et la règle de tolérance aux pannes bloquée, un message d'erreur similaire à celui qui suit peut inutilement s'afficher :
    L'ensemble de règle de la tolérance aux pannes ne correspond pas aux spécifications

    Ce problème est résolu dans cette version.
  • La création d'un profil d'hôte échoue avec l'erreur : Chemin configuré du PSP fixe non reconnu
    La création du profil d'hôte échoue et l'hôte ESXi consigne des messages similaires au suivant dans /var/log/vmware/hostd:
    Error: 'nmp.nmpProfile.FixedPspPolicy: Unrecognized Fixed PSP configured path iqn.2000-04.com.qlogic:qle4062c.yk10ny9cl5yk.1-00c0dd1c341f,iqn.1992-04.com.emc:cx.ckm00094800328.a2,t,1-naa.6006016090d0260071c460297bc1df11'
    Ce problème se produit si vous avez configuré un chemin préféré pour les LUN iSCSI avec une stratégie de chemin fixe.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi 5.0 affiche un écran de diagnostic violet avec des erreurs sur certains serveurs HP avec prise en charge PCC
    Certains serveurs HP se trouvent confrontés à une situation dans laquelle la communication PCC (contrôle de la fréquence d'horloge du processeur ou contrôle de la puissance collaboratif) entre le noyau VMware ESXi (VMkernel) et le BIOS du serveur ne fonctionne pas correctement. Par conséquent, un ou plusieurs PCPU peuvent rester en SMM (Mode de gestion du système) pendant plusieurs secondes. Lorsque le VMkernel remarque qu'un PCPU est indisponible pendant une longue durée, un écran de diagnostic violet apparaît et affiche des messages similaires aux suivants :

    PCPU 39 locked up. Failed to ack TLB invalidate (total of 1 locked up, PCPU(s): 39).
    0x41228efc7b88:[0x41800646cd62]Panic@vmkernel#nover+0xa9 stack: 0x41228efe5000
    0x41228efc7cb8:[0x4180064989af]TLBDoInvalidate@vmkernel#nover+0x45a stack: 0x41228efc7ce8


    @BlueScreen: PCPU 0: aucun signal de pulsation, IPI reçus (0/1).
    ...
    0x4122c27c7a68:[0x41800966cd62]Panic@vmkernel#nover+0xa9 pile : 0x4122c27c7a98
    0x4122c27c7ad8:[0x4180098d80ec]Heartbeat_DetectCPULockups@vmkernel#nover+0x2d3 pile : 0x0
    ...
    NMI: 1943: NMI IPI reçu. Was eip(base):ebp:cs [0x7eb2e(0x418009600000):0x4122c2307688:0x4010](Src 0x1, CPU140)
    Signal de pulsation : 618: PCPU 140 n'a pas eu de signal de pulsation pendant 8 secondes. *may* be locked up


    Cette version désactive PCC afin de résoudre ce problème.
  • La machine virtuelle SMP échoue avec un message d'alerte du moniteur lors de l'exécution de kexec
    Lorsqu'un noyau Linux se bloque, la fonction kexecde Linux peut être utilisée pour permettre de démarrer dans un noyau kdumpspécial et de rassembler les fichiers de l'image mémoire du blocage. Un client Linux SMP configuré avec kexec peut provoquer un blocage de la machine virtuelle avec un message d'alerte du moniteur pendant ce redémarrage. Des messages d'erreur similaires aux suivants peuvent être consignés :
    vcpu-0| CPU reset: soft (mode 2)
    vcpu-0| MONITOR PANIC: vcpu-0:VMM fault 14: src=MONITOR rip=0xfffffffffc28c30d regs=0xfffffffffc008b50


    Ce problème est résolu dans cette version.
  • L'hôte ESXi consigne un état C1E incorrect
    Le fichier vmkernel.loget la commande dmesgpeuvent afficher un message similaire à C1E enabled by the BIOS. Le message peut apparaître même si C1E a été désactivé par le BIOS ; il peut également ne pas apparaître alors que C1E a été activé par le BIOS.

    Ce problème est résolu dans cette version.
  • Le profil d'hôte peut ne pas parvenir à appliquer la valeur MTU aux vSwitch de l'hôte de destination
    Lorsque vous appliquez un profil d'hôte qui modifie uniquement la valeur MTU pour un vSwitch standard, la nouvelle configuration MTU n'est pas appliquée aux vSwitch sur le nouvel hôte de destination.

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

Stockage

  • Le message d'erreur lié à ScsiDeviceIO peut être consigné pendant la détection du périphérique
    Pendant la détection du périphérique, si une commande SCSI en option échoue avec une certaine condition, l'hôte ESXi 5.0 peut consigner des commandes SCSI en option échouées dans le journal vmkernel.

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

  • L'adaptateur FCoE (Fibre Channel over Ethernet) du logiciel VMware peut cesser de fonctionner lorsqu'ESXi accepte l'ID VLAN 4095 qui est retourné par un commutateur FCoE
    Le commutateur FCoE peut retourner l'ID VLAN 4095 en réponse à la demande de découverte FIP VLAN en provenance d'un ESXi Server. Cependant, l'ID VLAN 4095 est un ID réservé. Lorsque ESXi accepte l'ID VLAN 4095 d'un commutateur FCoE, ESXi interrompt la découverte FIP VLAN et utilise cet ID VLAN, provoquant l'échec de la découverte FCoE.

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

  • Une défaillance de stockage peut rendre inactives les banques de données résidant sur les LUN des contrôleurs de stockage et rendre inaccessible la machine virtuelle dans vSphere Client
    Les banques de données résidant sur les LUN des contrôleurs de stockage peuvent être inactives et une machine virtuelle peut être inaccessible dans vSphere Client en cas de défaillance de stockage. Les banques de données restent inactives jusqu'à ce qu'une nouvelle analyse manuelle soit réalisée. Ceci se produit lorsque l'agent de gestion hostd ne parvient pas à traiter correctement le message esx.clear.storage.redundancy.restored vob.

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

  • Lorsque l'opération de snapshotsuspendu échoue, les fichiers journaux ne sont pas consolidés
    Lorsque vous tentez d'effectuer un snapshotsuspendu d'une machine virtuelle, si l'opération de snapshot échoue vers la fin, les fichiers journaux créés dans le cadre du snapshot ne sont pas consolidés. Les fichiers journaux peuvent consommer beaucoup d'espace de la banque de données.

    Ce problème est résolu dans cette version. Si l'opération de snapshotsuspendu échoue, les fichiers journaux sont consolidés.

  • La commande esxcfg-scsidev -a indique un état de lien physique avec les cartes réseaux convergentes Fibre Channel over Ethernet Emulex
    Lorsque vous exécutez la commande esxcfg-scsidev -al'état de lien physique avec les cartes réseaux convergentes (CNA - Converged Network Adapters) Fibre Channel over Ethernet (FCoE) Emulex s'affiche.

    Ce problème est résolu dans cette version. La commande esxcfg-scsidev -aaffiche désormais l'état de lien virtuel.

  • L'hôte ESXi ne parvient pas à supprimer des périphérique de la baie de stockage DS8300
    Un hôte ESXi n'est pas informé des LUN non mappés de la baie de stockage DS8300, ne parvient pas à marquer les chemins comme morts et ne supprime pas ces LUN non mappés. Les commandes pour les LUN non mappés sur DS8300 échouent avec le message sense key 0x0bet l'hôte ESXi ne parvient pas à enregistrer une condition PDL (perte permanente de périphérique). La PDL est désormais détectée en fonction des données de détection ASC et non en fonction de la clé de détection.

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

  • La suppression d'une machine virtuelle provoque la suppression de disques virtuels non associés qui font partie du snapshot d'une machine virtuelle
    Lorsqu'une machine virtuelle comportant des snapshots est supprimée, des disques virtuels indépendants ou non qui ont été détachés de la machine virtuelle mais qui font partie d'un snapshot existant pourraient également être supprimés.

    Ce problème est résolu dans cette version.
  • Il est possible que certaines banques de données NFS ne soient pas conservées après une mise à niveau d'ESX 4.x vers ESX 5.x
    Si le nom de la banque de données NFS comporte des espaces, il est possible qu'elle ne soit pas conservée après une mise à niveau d'ESX 4.x vers ESX 5.x. Après une mise à niveau vers ESX 5.x, toutes les banques de données NFS qui comportent des espaces sont supprimées. Les autres banques de données NFS ne sont pas affectées.

    Ce problème est résolu dans cette version.
  • Les messages d'avertissement sont consignés pendant une opération de récupération de pulsation
    VMFS peut produire des E/S vers un volume lorsqu'une opération de récupération de pulsation est en cours ou qu'une opération de réinitialisation virtuelle est effectuée sur un périphérique sous-jacent. Par conséquent, des messages d'alerte et d'avertissement similaires aux messages suivants sont consignés :

    ALERT: ScsiDeviceIO: SCSIAsyncDeviceCommand:3082: Failed command 0x2a to quiesced partition naa.xxxxxxxxxxx


    WARNING: ScsiDeviceIO: 2360: Failing WRITE command (requiredDataLen=512 bytes) to write-quiesced partition naa.xxxxxxxxxxx

    naa.xxxxxxxxxxdésignant le NaaID du volume

    Dans cette version, les messages d'alerte sont supprimés et les avertissements deviennent des messages de journal.
  • L'hôte ESXi ne répond plus lorsque le module VMW_SATP_LSI ne dispose plus de suffisamment de mémoire du segment
    Ce problème se produit sur les serveurs qui ont accès aux LUN réclamés par le module VMW_SATP_LSI. Une fuite de mémoire dans un module VMW_SATP_LSI force le module à manquer de mémoire. Des messages d'erreur similaires aux messages suivants sont consignés dans le fichier vmkernel.log :

    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2218: Heap VMW_SATP_LSI already at its maximumSize. Cannot expand.
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: Heap: 2481: Heap_Align(VMW_SATP_LSI, 316/316 bytes, 8 align) failed. caller: 0x41800a9e91e5
    Feb 22 14:18:22 [host name] vmkernel: 2:03:59:01.391 cpu5:4192)WARNING: VMW_SATP_LSI: satp_lsi_IsInDualActiveMode: Out of memory.


    La fuite de mémoire du module VMW_SATP_LSI a été résolue dans cette version.
  • Les tentatives de création d'une partition de diagnostic sur un disque vierge ou sur un disque partitionné au format GPT peuvent échouer
    Les tentatives de création d'une partition de diagnostic à l'aide de vSphere Client peuvent échouer avec le message d'erreur suivant :
    Format de partition inconnu non pris en charge.
    Ce problème se produit si vous tentez de créer une partition de diagnostic sur un disque vierge (un disque sans table de partition) ou sur un disque partitionné au format GPT avec de l'espace disponible à la fin.

    Ce problème est résolu dans cette version.
  • Toute tentative d'activation du contrôle de flux sur le contrôleur Ethernet Gigabit Intel 82599EB échoue
    Lorsque vous tentez d'activer le contrôle de flux sur le contrôleur Gigabit Ethernet Intel 82599EB, le pilote ixgbe définit de façon incorrecte le contrôle de flux sur un contrôle de flux basé sur la priorité dans lequel le contrôle de flux est toujours désactivé. De ce fait, le message d'erreur Impossible de définir les paramètres de pause du périphérique : Argument non valideapparaît lorsque vous essayez d'activer le contrôle de flux.

    Ce problème est résolu dans cette version.
  • Les hôtes ESXi peuvent échouer avec un écran violet dans le pilote libata
  • Une condition de concurrence dans le pilote libata peut provoquer un échec de la fonction ata_hsm_moveavec un écran de diagnostic violet comportant un suivi de la pile similaire au suivant.
    BUG: failure at vmkdrivers/src_9/drivers/ata/libata-core.c:5833/ata_hsm_move()! (dans vmklinux) Panic_vPanic@vmkernel#nover+0x13 stack: 0x3000000010, 0x412209a87e00 vmk_PanicWithModuleID@vmkernel#nover+0x9d stack: 0x412209a87e20,0x4 ata_hsm_move@com.vmware.libata#9.2.0.0+0xa0 stack: 0x0, 0x410017c03e ata_pio_task@com.vmware.libata#9.2.0.0+0xa5 stack: 0x0, 0x0, 0x53fec vmklnx_workqueue_callout@com.vmware.driverAPI#9.2+0x11a stack: 0x0, helpFunc@vmkernel#nover+0x568 stack: 0x0, 0x0, 0x0, 0x0, 0x0

    Ce problème est résolu dans cette version.
  • La relecture du journal VMFS peut échouer pour les volumes VMFS-3 sur un hôte ESXi 5.0
    La relecture du journal VMFS peut échouer avec le message suivant sur un hôte ESXi 5.0 :

    J3: 3167: Échec de la relecture de la transaction étendue sur 4a1aa282-32d04c23-03a2-001517ab207b peut-être en attente d'une mise à niveau en ligne
    AVERTISSEMENT : HBX: 4336: Le relecture du journal sur le vol. 'san1_vmfs3' a échoué : Mauvais paramètre

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

Solution : Procédez comme suit pour résoudre le problème.

  1. Redémarrez l'hôte ESXi pour remettre son état au propre.
  2. Recommencez l'installation en direct.
     
  • Pendant les mises à jour scriptées depuis ESX/ESXi 4.x vers ESXi 5.0, les noms de périphériques de disques MPX et VML changent, avec pour conséquence éventuel l'échec de la mise à jour
    Les noms de périphériques de disques MPX et VML risquent de ne pas persister après un redémarrage des hôtes. Si les noms changent après le redémarrage dans une mise à niveau scriptée, celle-ci risque de s'interrompre.

    Solution : Lorsque cela est possible, utilisez les identifiants NAA (Network Address Authority Identifier) pour les périphériques de disques. Pour les machines sans disque avec identifiant NAA, comme les machines Hewlett Packard équipées des contrôleurs CCISS, procédez à la mise à niveau à partir d'un CD ou d'un DVD contenant l'image ISO du programme d'installation ESXi. Vous pouvez aussi, lors d'une mise à niveau scriptée, préciser l'instance ESX ou ESXi et utiliser la commande upgradeavec le paramètre --firstdisk=. Les commandes des scripts d'installation et de mise à niveau sont expliquées dans la documentation Installation et configuration de vSphere et Mise à niveau vSphere.

  • Impossibilité pour la console ESX et le rapport esxi_install.logd'acquérir une adresse DHCP pendant la mise à niveau quand le système ESX utilise des adresses IP manuellement attribuées sur un sous-réseau sans service DHCP
    Cette situation se présente quand un système ESX pourvu d'adresses IP manuellement attribuées est exécuté sur un sous-réseau dépourvu d'un serveur DHCP ou quand le serveur DHCP est hors capacité. Quel que soit le cas, au moment de la mise à niveau, le système ESX s'interrompra pour une durée d'une minute ou moins afin de tenter de récupérer une adresse IPv4 sur un serveur DHCP.

    Solution :Aucune. Après l'interruption d'une minute, le système continuera jusqu'au terme de la mise à niveau. Le système peut faire apparaître une invite indiquant d'appuyer sur Entrée pour continuer. Vous pouvez soit appuyer sur Entrée soit ignorer l'invite. Quel que soit votre choix, le système poursuivra la mise à niveau après l'interruption.

  • Attribution de licence
    • Échec possible de l'attribution automatique d'une clé de licence vSphere à certains hôtes ESX/ESXi dans un conteneur, avec les hôtes qui demeurent en mode d'évaluation
      vCenter Server 5.0 prend en charge l'attribution automatique des clés de licence aux hôtes ESX/ESXi. Vous pouvez associer une clé de licence avec un conteneur d'hôtes dans vCenter Server, comme un centre de données ou un cluster. vCenter Server attribue la clé de licence à tous les hôtes non titulaires d'une licence que vous ajoutez à ce conteneur. Vous pouvez associer une seule et unique clé de licence à un conteneur d'hôtes. Si la licence avec laquelle vous associez un conteneur d'hôtes s'applique à une version différente de celle des hôtes que vous ajoutez au conteneur, la licence n'est pas attribuée aux hôtes. Par exemple, si vous associez une licence vSphere 5.x à un cluster, et que vous ajoutez ESX/ESXi 4.x au cluster, la licence n'est pas attribuée aux hôtes ESX/ESXi 4.x, qui demeurent par conséquent en mode d'évaluation.

      Solution : Assurez-vous que tous les hôtes que vous ajoutez à un conteneur d'hôtes sont de la même version que la licence que vous associez à ce conteneur. Si un hôte du même conteneur nécessite une licence d'une autre version, associez la licence directement avec l'hôte. Par exemple, vous associez une licence vSphere 5.x avec un cluster. Vous ajoutez au cluster des hôtes ESXi 5.x auxquels est affectée la licence vSphere 5.x. Vous ajoutez des hôtes ESX/ESXi 4.x au même cluster, et vous associez une licence vSphere 4.x avec les hôtes. Vous reconnectez à vCenter Server les hôtes ESX/ESXi 4.x auxquels est affectée la licence vSphere 4.x.

    Sécurité
    • Les sessions d'interface Web de banque de données ne sont pas immédiatement terminées lorsque vous fermez la fenêtre du navigateur
      Lorsque vous fermez un navigateur Web après avoir accédé à l'interface Web de la banque de données, la session n'est pas terminée immédiatement du côté serveur. VMware souhaite remercier Jason Jones d'Inner Security pour avoir signalé ce problème.

      Solution :Vous devez cliquer sur Déconnexion dans l'interface Web de la banque de données pour mettre fin à la session avant de fermer la fenêtre du navigateur.

    vSphere

    • L'adaptateur réseau be2net Emulex avec id périphérique 0710 ne peut pas être sondé dans ESXi 5.0 (KB 2041665 )*

    • Un profil d'hôte avec une configuration vDS créée depuis vCenter Server 4.x peut ne pas appliquer les paramètres de passerelle pour les hôtes ESX 5.0 démarrés sans état
      Lors de l'utilisation de vSphere Auto Deploy avec un profil d'hôte 4.x, les paramètres de passerelle peuvent ne pas être appliqués pour les hôtes ESX 5.0 démarrés sans état. En conséquence, ces hôtes perdent la connectivité réseau et ne seront pas ajoutés automatiquement à vCenter Server 5.0.

      Solution : Pour utiliser un profil d'hôte 4.x avec une configuration vDS pour démarrer des hôtes ESX 5.0 sans état, suivez la procédure ci-dessous :

      1. Démarrez un hôte sans état ESX 5.0 configuré à l'aide d'Auto Deploy sans spécifier de profil d'hôte 4.x.
      2. Appliquez le profil d'hôte 4.x une fois que l'hôte sans état a été ajouté à vCenter Server 5.0.
      3. Créez un profil d'hôte depuis l'hôte ESX 5.0 démarré sans état. Utilisez le profil d'hôte créé avec vSphere Auto Deploy pour démarrer les hôtes ESX 5.0 sans état.

      Pour démarrer des hôtes ESX 5.0 sans état sans configuration vDS, utilisez un profil d'hôte 4.x qui ne contient pas de paramètres vDS. Vous pouvez aussi désactiver ou supprimer les paramètres vDS depuis un profil d'hôte 4.x de la manière suivante :

      Désactivez vDS et ses groupes de ports associés depuis le profil d'hôte en utilisant l'option Activer/désactiver une configuration de profil dans Profil d'hôte > Configuration de la mise en réseau. Supprimez vDS et ses groupes de ports associés depuis le profil d'hôte en utilisant l'option Éditer un profil dans Profil d'hôte > Configuration de la mise en réseau.

    • Les informations de la console du service n'apparaissent pas dans l'assistant Ajouter un hôte à vSphere distribué, ni dans l'assistant Gérer les hôtes.
      Lors de l'ajout d'un hôte ESX 4.x à un commutateur distribué, les informations des adaptateurs réseau de la console du service n'apparaissent pas dans l'assistant Ajouter un hôte de la page de connectivité réseau dans la section des informations de l'adaptateur virtuel. Généralement, l'adresse MAC, l'adresse IP et le masque de sous-réseau y apparaissent.

      Solution : Pour consulter les informations d'un adaptateur réseau de la console du service, quittez l'assistant Ajouter un hôte ou l'assistant Gérer les hôtes, puis accédez à Hôte > Configuration > Mise en réseau dans vSphere Client.

      Si l'adaptateur réseau de la console du service est déployé sur un commutateur standard :

      1. Localisez le commutateur.
      2. Cliquez sur le bouton « Propriétés... ».
      3. Sélectionnez l'adaptateur réseau de la console du service.
        Notez le nom de l'adaptateur qui apparaît dans le diagramme VSS.

      Si l'adaptateur réseau de la console du service est déployé sur un commutateur distribué :

      1. Accédez à l'onglet Commutateur distribué vSphere.
      2. Localisez le commutateur distribué et sélectionnez « Gérer l'adaptateur virtuel... ».
      3. Localisez et sélectionnez l'adaptateur réseau de la console du service.

    • Le serveur ESXi Dump Collector s'arrête silencieusement.
      Lorsque le port du serveur ESXi Dump Collector est configuré à l'aide d'une valeur non valide, il s'arrête silencieusement sans aucun message d'erreur. Ce port étant le port par lequel le serveur ESXi Dump Collector reçoit les vidages de mémoire des hôtes ESXi, ces arrêts silencieux empêchent les vidages de mémoire des hôtes ESXi d'être collectés. Étant donné qu'ESXi Dump Collector n'envoie pas les messages d'erreur à vCenter Server, l'administrateur vSphere n'est pas informé du problème. Si le problème n'est pas résolu, cela affecte les capacités de prise en charge lorsque des échecs surviennent sur un hôte ESXi.

      Solution : Afin d'éviter cet échec, sélectionnez un port figurant dans la liste des ports recommandés pour la configuration du serveur ESXi Dump Collector. Il est recommandé d'utiliser le port par défaut.

    • L'utilisation d'un NIC 10G QLogic version QLE3142 avec un pilote nx_nic provoque l'arrêt des serveurs pendant le démarrage de gPXE.
      Si un NIC 10G QLogic version QLE3142 avec un pilote nx_nic est utilisé pour démarrer gPXE dans la configuration de démarrage sans état ESXi, le serveur ESXi arrête de fonctionner et le démarrage échoue.

      Solution : Utilisez d'autres NIC pour le démarrage de gPXE.

    • Échec de vSphere vMotion suite à l'activation de plus de 16 cartes réseau VMkernel
      vSphere 5.0 est limité à 16 cartes réseau VMkernel activées pour vMotion par hôte. Si vous activez plus de 16 cartes réseau VMkernel pour vMotion sur un hôte donné, vMotion en direction ou depuis cet hôte risque de faire l'objet d'une défaillance. Le message d'erreur indique refus de la demande d'initialiser 17 entrées d'IP flux en cours, où le nombre indique combien de cartes réseau VMkernel vous avez activées pour vMotion.

      Solution : Désactivez les cartes réseau vMotion VMkernel jusqu'à ce vous n'en ayez plus que 16 maximum activées pour vMotion.

    • Remplacement par le contrôle E/S réseau des balises 802.1p dans les paquets sortants dans ESXi 5.0
      Dans ESXi 5.0, le contrôle E/S réseau relie par un pont l'écart entre la qualité de service (QoS) de la mise en réseau virtuelle et la QoS de la mise en réseau physique, afin que vous puissiez préciser une balise 802.1p par pool de ressources.
      Cette fonctionnalité a pour effet secondaire que chaque pool de ressources est marqué d'une balise 802.1p par défaut (0), même si la balise n'a pas été explicitement définie. Le balisage binaire de la classe de service (CoS) à l'intérieur d'une machine virtuelle est remplacé au moment de quitter l'hôte ESXi si le contrôle E/S réseau est activé.

      Solution :Aucune. Vous pouvez choisir de ne pas utiliser le contrôle E/S réseau.

    • Configuration des cartes réseau VMkernel dans des environnements IPv6 uniquement non prise en charge dans le profil des hôtes
      Quand vous utilisez vSphere Client pour définir des configurations IP pour le profil d'un hôte, vous avez le droit de définir des paramètres IPv4 uniquement, IPv6 uniquement ou IPv4 et IPv6 mélangés pour les cartes réseau VMkernel. Les paramètres IPv6 uniquement ne sont toutefois pas pris en charge dans les profils d'hôtes. Si vous configurez des cartes réseau VMkernel avec des paramètres IPv6 uniquement, vous êtes invité à fournir les configurations IPv4 dans le fichier de réponses du profil d'hôte.

      Solution : Exécutez l'une des tâches suivantes :

      • Utilisez uniquement les paramètres IPv6 pour configurer vos cartes réseau VMkernel dans vSphere Client ; n'utilisez pas de profil d'hôte.
      • Incluez les deux configurations IPv6 et IPv4 pour les cartes réseau VMkernel au moment de créer et d'appliquer le profil d'hôte, puis désactivez les configurations IPv4 pour les cartes réseau VMkernel après avoir appliqué le profil.

    • Récupération par certains commutateurs Cisco de paquets dont le bit Priorité est défini
      Le contrôle E/S réseau VMware vSphere permet de marquer le trafic sortant avec des balises 802.1p. Cependant, certains commutateurs Cisco (4948 et 6509) récupèrent les paquets si les paquets balisés sont envoyés sur le VLAN natif (VLAN 0).

      Solution :Aucune.

    • Temps d'attente considérable dans le processus de démarrage ESXi pendant la configuration du VLAN et le chargement des pilotes
      Les hôtes ESXi avec les interfaces BE2 ou BE3 accusent un important temps d'attente pendant le chargement des pilotes et la configuration du VLAN. La durée du temps d'attente augmente avec le nombre d'interfaces BE2 et BE3 sur l'hôte, et elle peut être de plusieurs minutes.

      Solution :Aucune.

    • Échec de l'ajout d'un pool de ressources réseau à un vSphere Distributed Switch, accompagné de l'erreur Impossible de terminer une opération de vSphere Distributed Switch pour un ou plusieurs membres d'hôte
      Ce message d'erreur indique qu'un ou plusieurs hôtes sur le commutateur distribué est déjà associé avec le nombre maximum de pools de ressources réseau. Le nombre maximum de pools de ressources réseau autorisé sur un hôte est 56.

      Solution :Aucune.

    • Échec de l'ajout d'un pool de ressources réseau à un vSphere Distributed Switch, accompagné de l'erreur vim.fault.LimitExceeded
      Ce message d'erreur indique que le commutateur distribué a déjà le nombre maximum de pools de ressources réseau. Le nombre maximum de pools de ressources réseau sur un vSphere Distributed Switch est 56.

      Solution :Aucune.

    • LLDP n'affiche pas les noms des systèmes pour les commutateurs extrêmes
      Par défaut, les noms des systèmes sur les commutateurs extrêmes ne sont pas publiés. Sauf si le nom d'un système est explicitement défini pour apparaître sur le commutateur extrême, LLDP ne peut afficher cette information.

      Solution : Exécutez la commande configure lldp ports <port ID> advertise system-name pour faire apparaître le nom du système sur le commutateur extrême.

    • Échec d'ESXi suite à la troncature des paquets en miroir
      Quand un paquet en miroir dépasse la longueur du paquet en miroir définie pour la session d'écriture-miroir des ports, ESXi échoue. D'autres opérations qui tronquent les paquets peuvent aussi entraîner l'échec d'ESXi.

      Solution : Ne définissez pas de longueur de paquet en miroir pour une session d'écriture-miroir des ports.

    • Fault Tolerance incompatible avec vSphere DirectPath I/O with vSphere vMotion
      Quand l'option Fault Tolerance est activée sur une machine virtuelle, DirectPath I/O with vMotion est inactif pour tous les adaptateurs virtuels sur la machine virtuelle.

      Solution : Désactivez Fault Tolerance et redémarrez la machine virtuelle avant d'activer DirectPath I/O avec vMotion.

    • IPv6 non pris en charge par vCenter Server Virtual Appliance
      Malgré la présence d'une option pour configurer IPv6 sur la console vCenter Server Virtual Appliance Web, vCenter Server Virtual Appliance ne prend pas en charge la configuration IPv6.

      Solution : Ne définissez pas ou ne modifiez pas la configuration IPv6 sur la console vCenter Server Virtual Appliance Web.

    • Activation de vSphere DirectPath I/O With vSphere vMotion par les applications VMCI
      Quand vous utilisez une application VMCI sur un système Cisco UCS, DirectPath devient inactif sur toutes les cartes réseau de la machine virtuelle.

      Solution : Arrêtez les applications VMCI, et redémarrez la machine virtuelle pour rétablir vSphere DirectPath I/O.

    Stockage
    • Le seuil de latence E/S semble être à 15 ms après la désactivation des mesures E/S pour un cluster de banques de données
      Après que vous désactivez les mesures E/S pour un cluster de banques de données, la page Résumé dudit cluster de banques de données continue d'afficher un seuil de latence E/S d'une valeur de 15 ms (la valeur par défaut).

      Solution :Aucune. Pour voir la valeur adéquate, sélectionnez Cluster de banques de données > Stockage.

    • Le lien Entrer en mode de maintenance SDRS apparaît sur la page Résumé de la banque de données autonome
      Seules les banques de données faisant partie intégrante d'un cluster de banques de données peuvent passer sans encombre en mode de maintenance DRS de stockage. Pourtant, un lien Entrer en mode de maintenance DRS de stockage apparaît sur la page Résumé d'une banque de données qui ne figure dans aucun cluster. Quand vous cliquez sur Entrer en mode de maintenance SDRS pour une banque de données autonome, celle-ci tente de passer en mode de maintenance, et la tâche semble rester indéfiniment en attente.

      Solution : Annulez la tâche Entrer en mode de maintenance SDRS dans le panneau Tâches récentes de vSphere Client.

    • Un état APD (Tous les chemins d'accès en panne) dans un Storage vMotion peut donner lieu à une interruption de communication entre vCenter Server et l'hôte ESXi
      Dans le cas d'un état APD quand vous migrez des machines virtuelles au moyen de Storage vMotion, vCenter Server déconnecte l'hôte impliqué dans Storage vMotion de l'inventaire vCenter Server. Cet état persiste jusqu'au terme de l'opération Storage vMotion qui s'exécute en arrière-plan. Cette action peut durer quelques minutes ou quelques heures suivant le temps d'exécution de Storage vMotion. En attendant, il n'est possible d'effectuer aucune autre opération eu égard à cet hôte en particulier depuis vCenter Server.

      Solution :Aucune. Au terme de l'opération Storage vMotion, vCenter Server reconnecte l'hôte à l'inventaire. Cette défaillance ne touche aucune des machines virtuelles en cours de fonctionnement sur des banques de données non-APD.

    • L'ajout de liens symboliques à une banque de données risque d'entraîner un affichage erroné du contenu de la banque de données dans le Navigateur de banque de données
      Quand vous ajoutez des liens symboliques au niveau supérieur d'une banque de données, soit en externe sur un serveur NFS soit en vous connectant à l'hôte, il y a un risque que les informations de la banque de données, comme ses fichiers et ses dossiers, n'apparaissent pas correctement quand vous parcourez la banque de données. Des liens symboliques qui renvoient à des fichiers et des dossiers incorrects pourraient être à l'origine du problème.

      Solution : Supprimez les liens symboliques. N'utilisez pas de liens symboliques dans les banques de données.

    • Tentatives d'ajouter une extension à une banque de données VMFS compatible ATS échouées
      Vous pouvez parcourir une banque de données compatible ATS uniquement sur un périphérique compatible ATS. Si vous sélectionnez le périphérique qui ne prend pas en charge ATS pour étendre la banque de données compatible ATS, l'opération échoue. vSphere Client affiche le message suivant : une erreur s'est produite lors de la configuration d'hôte. Dans le fichier journal, vous pouvez aussi trouver le message d'erreur suivant : l'opération a échoué, il n'est pas possible d'ajouter l'extension au filesystem.

      Solution : Avant d'ajouter une extension à une banque de données ATS, vérifiez si le périphérique d'extension prend en charge ATS en exécutant la commande suivante :
      esxcli storage core device vaai status get -d=device_ID
      La sortie doit afficher l'information suivante :
      ATS Status: supported

    • DRS de stockage peut ne pas se comporter comme prévu au moment de l'équilibrage de la charge E/S
      Quand vous utilisez le logiciel IOMeter pour générer une charge E/S et tester DRS de stockage, IOMeter remplit implicitement les fichiers de zéros uniquement. Ces données ne contiennent pas les schémas aléatoires de uns et de zéros, pourtant présents dans les données réelles et exigés par DRS de stockage pour déterminer les caractéristiques E/S et les performances de la banque de données.

      Solution : Lorsque vous testez l'équilibrage de charge du DRS de stockage, utilisez des données réelles pour remplir au moins 20 pour cent de l'espace de stockage dans la banque de données. Si vous utilisez IOMeter pour générer une charge E/S, choisissez une version qui permet d'écrire des schémas aléatoires de uns et de zéros dans vos fichiers.

    • Les noms des disques des nouvelles machines virtuelles n'apparaissent pas dans les recommandations de placement initial DRS de stockage
      Quand vous créez, clonez ou déployez depuis un modèle une machine virtuelle dans un cluster de banques de données DRS de stockage, la boîte de dialogue des recommandations de placement ou des défaillances ne répertorie pas les noms des disques durs des nouvelles machines virtuelles. La boîte de dialogue affiche : placer le nouveau disque dur de la machine virtuelle sur <datastore name>.

      Solution :Aucune. Quand vous créez des machines virtuelles, les noms des disques durs ne sont pas attribués tant que les disques ne sont pas placés. Si les disques durs des machines virtuelles sont de tailles variées et placés dans des banques de données différentes, vous pouvez utiliser l'option Utilisation de l'espace avant et après les statistiques pour estimer quel disque est placé dans quelle banque de données.

    • DRS de stockage donne l'impression d'être désactivé quand vous utilisez l'assistant Tâche planifiée pour créer ou cloner une machine virtuelle
      Quand vous créez une tâche planifiée pour cloner ou créer une machine virtuelle, et que vous sélectionnez un cluster de banques de données comme stockage cible pour les fichiers de la machine virtuelle, la case Désactiver DRS de stockage demeure cochée en permanence. Vous ne pouvez pas désélectionner la case Désactiver DRS de stockage au regard de la machine virtuelle dans l'assistant Tâche planifiée.

      Solution :Aucune. La case Désactiver DRS de stockage demeure cochée en permanence dans l'assistant Tâche planifiée. Après l'exécution de l'assistant Tâche planifiée et sitôt la machine virtuelle créée, le niveau d'automatisation de la machine virtuelle est cependant le même que le niveau d'automatisation par défaut du cluster de banques de données.

    • vSphere Client affiche une erreur quand vous tentez de démonter une banque de données NFS alors que l'option Contrôle E/S de stockage est activée
      Si vous activez l'option Contrôle E/S de stockage pour une banque de données NFS, vous ne pouvez pas démonter cette banque de données. Le message d'erreur suivant s'affiche : la ressource est en cours d'utilisation.

      Solution : Avant de tenter de démonter la banque de données, désactivez l'option Contrôle d'E/S de stockage.

    • ESXi ne peut pas distinguer entre les disques virtuels avec provisionnement statique mis à zéro en différé et avec provisionnement statique immédiatement mis à zéro dans les banques de données NFS assurant la prise en charge de l'Accélération matérielle
      Quand vous utilisez des banques de données NFS qui prennent en charge l'Accélération matérielle, vSphere Client permet de créer des disques virtuels au format Provisionnement statique mis à zéro en différé (zeroedthick) ou Provisionnement statique immédiatement mis à zéro (eagerzeroedthick). Quand vous cochez le type de disque dans la boîte de dialogue Propriétés de machine virtuelle, la section Provisionnement de disque affiche néanmoins toujours Provisionnement statique immédiatement mis à zéro comme format de disque, et ce quel que soit le format que vous avez sélectionné pendant la création du disque. ESXi ne fait pas la distinction entre des disques virtuels mis à zéro en différé et immédiatement mis à zéro dans les banques de données NFS.

      Solution :Aucune.

    • Après la migration, le mode d'un disque IDE RDM dans la compatibilité physique ne change pas en Indépendant persistent
      Le mode d'un disque IDE RDM dans la compatibilité physique ne change pas en Indépendant persistent après que vous avez migré la machine virtuelle équipé du disque de l'hôte ESX/ESXi 4.x vers ESXi 5.0.

      Solution : Après la migration, utilisez vSphere Client pour remplacer le mode du disque par le mode Indépendant persistant.

    • Les tentatives d'ajouter un RDM en compatibilité virtuelle avec un disque enfant à une machine virtuelle existante se soldent par un échec
      Si vous tentez d'ajouter un RDM en compatibilité virtuelle doté d'un disque enfant à une machine virtuelle existante, l'opération échoue. vSphere Client affiche le message d'erreur suivant : Échec de la reconfiguration : vim.fault.DeviceUnsupportedForVmPlatform.

      Solution : Retirez le disque enfant pour pouvoir ajouter un RDM en compatibilité virtuelle.

    • Alors que FCoE est activé, les tentatives d'afficher les mappages de stockage se soldent par un échec, avec un message d'erreur
      Le problème touche uniquement les hôtes ESXi qui ont été ajoutés à vCenter Server sans aucune configuration précédente de FCoE. Après l'activation des adaptateurs FCoE sur ces hôtes, les tentatives d'afficher les mappages de stockage dans vSphere Client échouent. Le message d'erreur suivant s'affiche : Une erreur interne s'est produite : impossible de sérialiser la réponse.

      Solution : Configurez tout d'abord le FCoE de logiciel sur l'hôte ESXi, puis ajoutez l'hôte à vCenter Server.

    • Une banque de données NFS ayant l'espace adéquat affiche des erreurs d'insuffisance d'espace
      Le problème survient uniquement quand vous utilisez le partage de client RPC (Remote Procedure Call) et que vous montez plusieurs volumes NFS issus de la même adresse IP du serveur NFS. Dans cette configuration, quand un des volumes NFS manque d'espace, les autres volumes NFS qui partagent le même client RPC risquent eux aussi de signaler des erreurs d'absence d'espace.

      Solution : Désactivez le partage de client RPC sur votre hôte en procédant comme suit :

      1. Dans le panneau d'inventaire de vSphere Client, sélectionnez l'hôte.
      2. Cliquez sur l'onglet Configuration, puis sur Paramètres avancés sous Logiciel.
      3. Cliquez sur NFS dans le panneau de gauche, et faites défiler jusqu'à NFS.MaxConnPerIP sur la droite.
      4. Modifiez la valeur par défaut pour 128.

    • Les tentatives de désenregistrement de plusieurs fournisseurs de stockage simultanément se soldent par un échec, avec une erreur
      Si vous tentez de désenregistrer plusieurs fournisseurs en même temps de vCenter Server, vous risquez de vous heurter à un échec. Le message d'erreur suivant apparaît, même en présence des fournisseurs défaillants dans vCenter Server : ManagedObjectNotFound. Le fichier sms.log peut éventuellement afficher l'exception suivante : ProviderUnregistrationFault.

      Solution : Annulez manuellement, un à un, l'enregistrement des fournisseurs.

    • Après redémarrage, l'hôte sans état ne parvient pas à détecter les banques de données iSCSI.
      Si un hôte sans état est ajouté aux commutateurs de la série Cisco Nexus 1000V et configuré avec une MTU de 9000, alors l'hôte est incapable de détecter les banques de données iSCSI après le redémarrage, même s'il peut découvrir les périphériques correspondants.

      Solution : Pour afficher les banques de données, cliquez sur Actualiser sur l'écran Configuration > Stockage de vSphere Client.

    Configuration des serveurs
    • Un changement à la règle SATP-PSP au regard des profils d'hôte appliqués à l'hôte ESXi ne se reflète pas dans l'hôte après le redémarrage
      Après l'application d'un changement à la règle SAN Array Type Plugin Path Selection Policy (SATP PSP) et le redémarrage d'un hôte alloué avec Auto Deploy, le nouveau changement n'est pas reflété dans le SATP PSP pour chacun des périphériques. Concernant les hôtes ESXi non alloués avec Auto Deploy, le changement de SATP PSP n'est pas correctement actualisé dans l'hôte. Une vérification de conformité de l'hôte ESXi se solde toutefois par un échec avec le profil d'hôte.

      Solution : Après l'application du profil d'hôte à l'hôte ESXi, supprimez le profil d'hôte et extrayez-en un nouveau de l'hôte ESXi, puis attachez-le à l'hôte avant de redémarrer. Pour cela, utilisez la fonction Mettre à jour le profil depuis l'hôte de référence dans l'IU des profils d'hôte. Ce faisant, vous supprimez le profil d'hôte et en extrayez un nouveau de l'hôte tout en maintenant l'ensemble des attachements en cours.

      Utilisez la commande esxcli pour modifier le SATP PSP dans l'hôte lui-même avant d'extraire le profil d'hôte. N'utilisez pas l'éditeur de profil d'hôte pour modifier le SATP PSP.

    • L'application d'un profil d'hôte avec une stratégie de démarrage des services désactivée ne désactive pas le service
      Un profil d'hôte est créé avec comme hôte de référence un hôte ESXi configuré avec certains services désactivés, et il est appliqué à un hôte dont lesdits services sont activés. Le processus d'application du profil d'hôte ne désactive pas les services dans l'hôte ESXi cible. Cette situation arrive souvent quand les utilisateurs ont activé les services ESXShell ou SSH dans les hôtes ESXi cibles via l'option Profil de sécurité dans vSphere Client ou la fonction Options de dépannage dans DCUI.

      Solution : Le processus de redémarrage désactive les services. Vous pouvez aussi arrêter manuellement les services dans vSphere Client en configurant l'hôte. Effectuez la procédure pour chaque service.

      1. Sélectionnez l'hôte dans l'inventaire.
      2. Cliquez sur l'onglet Configuration.
      3. Cliquez sur Profil de sécurité dans la section Logiciel.
      4. Cliquez sur Propriétés, et sélectionnez le service.
      5. Cliquez sur Options.
      6. Cliquez sur Arrêter, puis sur OK.
    • L'état du fichier de réponses du profil d'hôte n'est pas actualisé au moment de basculer le profil attaché de l'hôte
      Au moment d'attacher un profil d'hôte à un hôte précédemment attaché à un autre profil d'hôte, l'état du fichier de réponses n'est pas actualisé. Si l'état du fichier de réponses est Terminé, après que vous avez attaché un autre profil d'hôte à l'hôte, l'état du fichier de réponses dans la vue du profil d'hôte demeure encore Terminé. L'état réel pourrait en fait changer et afficher Incomplet.

      Solution : Actualisez l'état du fichier de réponses manuellement après avoir attaché un profil d'hôte.

      1. Dans vSphere Client, sélectionnez le profil nouvellement attaché dans la vue d'inventaire Profils d'hôte.
      2. Cliquez sur l'onglet Hôtes et clusters.
      3. Cliquez avec le bouton droit sur l'hôte dans la liste Nom d'entité, et sélectionnez Vérifier le fichier de réponses.

      L'état du fichier de réponses du profil d'hôte est actualisé.

    • Délai d'attente possible de l'application manuelle d'un profil d'hôte contenant une configuration importante
      L'application d'un profil d'hôte contenant une configuration volumineuse, par exemple un très grand nombre de vSwitches et groupes de ports, peut faire l'objet d'un délai d'attente si l'hôte cible n'est pas configuré ou configuré seulement en partie. En pareils cas, le message d'erreur Impossible d'appliquer la configuration de l'hôteapparaît dans vSphere Client, même si le processus sous-jacent dans ESXi en charge d'appliquer la configuration continue de fonctionner.

      Le fichier syslog.log ou d'autres fichiers journaux peuvent par ailleurs comporter des messages d'erreur comme le suivant :
      Error interacting with configuration file /etc/vmware/esx.conf: Timeout while waiting for lock, /etc/vmware/esx.conf.LOCK, to be released. Another process has kept this file locked for more than 20 seconds. The process currently holding the lock is hostd-worker(5055). This is likely a temporary condition. Please try your operation again.

      Cette erreur émane d'un conflit dans le système suite à plusieurs opérations qui tentent de collecter les informations relatives à la configuration du système pendant que l'opération d'application des profils d'hôte définit la configuration. En raison de ces erreurs et d'autres erreurs associées au délai d'attente, même au terme de l'opération d'application des profils d'hôte sur le système, la configuration capturée dans le profil d'hôte risque de ne pas être appliquée dans son intégralité. Une vérification de la conformité de l'hôte montre quelles parties de la configuration n'ont pas été appliquées, et déclenche une opération d'application pour corriger les problèmes de non-conformité restants.

      Solution : Effectuez l'une des actions suivantes :

      • Hôtes ESXi non provisionnés avec Auto Deploy

        1. Augmentez la valeur du délai d'attente eu égard à l'opération d'application en ajoutant la saisie suivante dans le fichier /etc/vmware/hostd/cmdMo.xml :

          <managedObject id="2">
          <type> vim.profile.host.profileEngine.HostProfileManager </type>
          <moId> ha-hostprofileengine-hostprofilemanager </moId>
          --> <timeOutInSeconds> xxxx </timeOutInSeconds> <--****
          <version> vim.version.dev </version>
          <cmd> /usr/bin/sh </cmd>
          <arg id="1"> -l </arg>
          <arg id="2"> -c </arg>
          <arg id="3"> /usr/lib/vmware/hostd/hmo/hostProfileEngine.py --cgi </arg>
          </managedObject>


          xxxx est la valeur d'expiration en secondes. Par défaut, l'opération d'application expire après 10 minutes. Cette entrée vous permet de définir un délai d'expiration plus long. Par exemple, une valeur de 3 600 porte le délai d'expiration à 1 heure. La valeur que vous entrez pourrait varier en fonction de la configuration spécifique du profil d'hôte. Après avoir défini une valeur suffisamment élevée, l'erreur d'expiration de l'opération d'application n'apparaît plus et la tâche est visible dans vSphere Client jusqu'à ce qu'elle soit terminée.
        2. Redémarrez hostd.
      • Hôtes provisionnés avec Auto Deploy

        1. Redémarrez l'hôte ESXi alloué avec Auto Deploy.
        2. Pour les hôtes ESXi provisionnés avec Auto Deploy, vérifiez que le fichier de réponse est complet en effectuant l'opération Mettre à jour le fichier de réponse sur l'hôte ESXi puis en redémarrant.

          La configuration dans le profil d'hôte et dans le fichier de réponses s'applique au système pendant l'initialisation. Le démarrage des configurations volumineuses risque de durer plus longtemps, mais c'est toujours beaucoup plus rapide que d'appliquer manuellement le profil d'hôte dans l'ensemble de vSphere client.
    • Échec de la vérification de la conformité des profils d'hôte pour les hôtes de référence dont le profil vient d'être créé
      Une vérification de conformité d'un profil d'hôte récemment configuré, par exemple configuré avec iSCSI, peut se solder par un échec si le fichier de réponses n'est pas actualisé auparavant.

      Solution :Mettez à jour le fichier de réponses du profil avant d'effectuer une vérification de conformité.

    • Échec de l'application d'un profil d'hôte si syslog logdir est défini sur la banque de données sans chemin
      Si la commande esxcli ou vSphere Client est utilisé(e) pour définir le répertoire du syslog sur une banque de données sans chemin supplémentaire, un profil d'hôte extrait de ce système ne peut pas s'appliquer à d'autres hôtes.

      Par exemple, la commande suivante configure le système d'une manière qui déclenche cette condition :
      esxcli system syslog config set --logdir /vmfs/volumes/datastore1

    De même, le fait de définir Syslog.global.logDir sur datastore1 dans la boîte de dialogue Paramètres avancés de l'onglet Configuration de l'hôte déclenche également cette condition.

    Solution : Effectuez l'une des actions suivantes :

    • Avant d'extraire le profil d'hôte, modifiez Syslog.global.logDir dans la boîte de dialogue Paramètres avancés de sorte à lui attribuer la valeur « DATASTORE_NAME / » au lieu de « DATASTORE_NAME ».
    • Modifiez le profil d'hôte de sorte que la valeur de l'option de configuration avancée pour Syslog.global.logDir soit « DATASTORE_NAME / » et non « DATASTORE_NAME ».

  • L'application d'un profil d'hôte peut créer de nouveau des vSwitches et des portgroups.
    Les vSwitches et portgroups d'un hôte peuvent être créés de nouveau lorsqu'un profil d'hôte est appliqué. Cela peut survenir même si l'hôte est conforme au profil d'hôte.

    Cela se produit lorsque les options de règle portgroupprofile sont définies sur les valeurs par défaut. Cette configuration engendre un problème au cours duquel la comparaison entre les configurations du profil et de l'hôte peut échouer à tort lorsque le profil est appliqué. Dans ce cas, la vérification de conformité est transmise. L'échec de la comparaison engendre une nouvelle création de vSwitches et de portgroups lors de l'application du profil. Cela affecte tous les sous-profils de portgroupprofile.

    Solution : Modifiez les paramètres du profil pour les faire correspondre aux paramètres souhaités au lieu d'utiliser les paramètres par défaut.

  • L'agent SNMP intégré à VMware signale une date incorrecte pour l'installation du logiciel à travers hrSWInstalledTabledepuis HOST-RESOURCES-MIB.
    Lorsque vous interrogez le logiciel installé (hrSWInstalledTable RFC 2790) à l'aide de l'agent SNMP intégré à VMware, la date d'installation affichée pour l'installation du logiciel par l'utilisateur est incorrecte, car hrSWInstalledTablede HOST-RESOURCES-MIBne signale pas hrSWInstalledDatecorrectement.

    Solution : Pour retrouver la date correcte d'installation, utilisez la commande esxcli esxcli software vib list.

  • vCenter Server et vSphere Client

    • État de périphérique inconnu dans l'onglet État du matériel de vCenter Server*
      Dans la vue Capteurs de l'onglet État du matériel de vCenter Server, l'état de certains périphériques PCI s'affiche en tant que Unknown Unknown #<number>. Les derniers identifiants de PCI pour certains périphériques ne sont pas répertoriés dans le fichier /usr/share/hwdata/pci.idssur l'hôte ESXi. vCenter Server répertorie les périphériques sans identifiants comme périphériques inconnus.

      L'état inconnu n'est pas critique et la liste des identifiants de PCI est régulièrement mise à jour dans les principales versions de vSphere.

    • Erreur de base de données lors du réenregistrement d'AutoDeploy sur vCenter Virtual Appliance (VCVA) (KB 2014087).
    • La base de données intégrée fournie avec le vCenter Server Appliance prend en charge un inventaire comprenant au maximum 5 hôtes et 50 machines virtuelles
      La base de données intégrée n'est pas configurée pour gérer un inventaire qui comporte plus de 5 hôtes et 50 machines virtuelles. Si vous utilisez la base de données intégrée avec le vCenter Server Appliance, le dépassement de ces limites peut provoquer de nombreux problèmes, tels que le vCenter Server ne répondant plus.

    • L'encadré Alarmes de vSphere Web Client n'indique pas le nombre adéquat d'alarmes présentes dans le système
      Quand les alarmes présentes dans le système dépassent 100, l'encadré Alarmes de vSphere Web Client indique à tort 100 alarmes uniquement.

      Solution :Aucune.

    • Les graphiques de présentation des performances n'apparaissent pas pour les clusters de banques de données ou les banques de données dans les grands environnements
      Dans certains environnements très vastes, les graphiques de présentation des performances peuvent ne pas apparaître au regard des clusters de banques de données ou des banques de données en raison de l'insuffisance de mémoire dans Tomcat, le service vSphere Management WebServices.

      Solution :Augmentez la quantité de mémoire disponible pour Tomcat.

    • Lors de l'utilisation de vSphere Web Client, vous êtes invité à plusieurs reprises à augmenter le stockage local disponible pour Adobe Flash
      vSphere Web Client utilise le stockage local sur le système qui est utilisé pour accéder au client pour stocker les fichiers journaux. Les limites de stockage pour les fichiers journaux sont déterminées par les paramètres d'Adobe Flash Player. À mesure que les fichiers journaux grossissent, une boîte de dialogue apparaît, invitant à augmenter la limite. L'invite réapparaît régulièrement jusqu'à ce que la limite de stockage atteigne Illimité.

      Solution : Définissez les limites de stockage pour Adobe Flash Player :

      1. Ouvrez le panneau Paramètres de stockage globaux ; pour cela, tapez l'URL suivante dans votre navigateur Web : http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
      2. Réglez le curseur sur Illimité.
      3. Ouvrez le panneau Paramètres de stockage des sites Web ; pour cela, tapez l'URL suivante dans votre navigateur Web : http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html
      4. Sélectionnez l'URL de vSphere Web Client dans la liste des sites Web consultés.
      5. Réglez le curseur sur Illimité.

    • Impossible de sélectionner plusieurs colonnes à trier dans vSphere Web Client
      Dans vSphere Web Client, vous pouvez sélectionner la première colonne d'un tableau que vous voulez utiliser comme base pour le tri en cliquant sur son en-tête. Si vous cliquez sur l'en-tête de la deuxième colonne, cette colonne se transforme en première colonne de tri plutôt de faire l'objet d'une sélection en tant que deuxième colonne de tri.

      Solution : Pour effectuer un tri selon plusieurs colonnes d'un tableau dans vSphere Web Client, procédez comme suit :

      1. Sélectionnez la première colonne à trier en cliquant sur son en-tête.
      2. Sélectionnez la deuxième colonne et les autres qui suivent à trier en appuyant sur la touche Ctrl et en cliquant en même temps sur les en-têtes des colonnes.

    • Chargement des pages vSphere Web Client impossible dans Internet Explorer 7
      Si about:internetet https://localhostne figurent pas comme sites de confiance dans les paramètres de sécurité d'Internet Explorer 7, le navigateur Web ne pourra pas ouvrir les pages vSphere Web Client.

      Solution : Ajoutez about:internetet https://localhostaux sites de confiance :

      1. Dans Internet Explorer 7, sélectionnez Outils > Options Internet.
      2. Cliquez sur l'onglet Sécurité.
      3. Sélectionnez Sites de confiance.
      4. Cliquez sur Sites.
      5. Dans la zone de texte Ajouter ce site Web à la zone, tapez about:internet , puis cliquez sur Ajouter.
      6. Dans la zone de texte Ajouter ce site Web à la zone, tapez https://localhost , puis cliquez sur Ajouter.
      7. Cliquez sur OK.
      8. Fermez et redémarrez Internet Explorer.

    • L'ouverture de l'Application d'administration vSphere à partir d'un raccourci produit l'erreur : Windows cannot find 'https://localhost:9443/admin-app'
      Quand Firefox est le navigateur Web par défaut et qu'il ne fonctionne pas, le lancement de l'Application d'administration vSphere à partir d'un raccourci peut générer l'erreur suivante : Windows ne peut pas trouver 'https://localhost:9443/admin-app'. Assurez-vous de saisir le nom correctement et essayez à nouveau.

      Solution :Ce problème avec Firefox sur certains systèmes Windows est connu. Reportez-vous à http://kb.mozillazine.org/Windows_error_opening_Internet_shortcut_or_local_HTML_file_-_Firefox.

    • vSphere Web Client ne charge pas l'inventaire de vCenter Server si le nom d'hôte de vCenter Server n'est pas résolu
      En cas d'impossibilité pour vSphere Web Client de résoudre le nom d'hôte du système vCenter Server et si vCenter Server est enregistré avec vSphere Client par le biais d'une adresse IP, vSphere Web Client ne pourra pas charger l'arborescence de l'inventaire.

      Solution : Assurez-vous que le nom d'hôte de vCenter Server peut être résolu en procédant comme suit au choix :

      • Ajoutez le système vCenter Server à votre serveur de noms.
      • Ajoutez le système vCenter Server au fichier C:\Windows\System32\drivers\etc\hostssur le système où fonctionne vSphere Web Client.

    • Le commande snmpwalk renvoie un message d'erreur quand vous l'exécutez sans l'option -t
      Quand la commande snmpwalkest exécutée sans les options -tet -rpour l'interrogation des données SNMP, l'agent SNMP intégré à VMware ne montre pas les données dans leur intégralité, et affiche le message d'erreur : aucune réponse de l'hôte.

      Solution : Lorsque vous exécutez la commande snmpwalk, utilisez l'option -tpour spécifier le délai d'expiration et l'option -rpour définir le nombre de nouvelles tentatives. Par exemple : snmpwalk -m all -c public -v1 host-name -r 2 -t 10 variable-name.

    • Le plug-in Flash se bloque quand vous vous connectez ou déconnectez de vSphere Web Client sous Linux
      Quand vous vous connectez ou déconnectez de vSphere Web Client sous Linux, le plug-in Flash peut éventuellement se bloquer.

      Solution :Rechargez la page pour redémarrer le plug-in Flash.

    • Impossible d'accéder à l'outil d'administration de vSphere Web Client via une adresse IPv6 locale
      Si vous tentez d'accéder à l'outil d'administration de vSphere Web Client via une adresse IPv6 locale, le navigateur Web affiche le message d'erreur suivant : l'outil d'administration vSphere Web Client ne peut pas accéder à partir d'un hôte distant.

      Solution : Utilisez localhost au lieu de l'adresse IPv6 pour accéder à l'outil d'administration. Par exemple, utilisez https://localhost:9443/admin-appau lieu d'une adresse comme https://[fc00:10:20:123:355c:1744:1b82:6716]:9443/admin-app.

    • Internet Explorer 7 ne peut pas accéder aux pages vSphere Client Web quand le client est installé sur un système qui utilise IPv6 à l'état pur
      Si vSphere Web Client est installé sur un système d'exploitation qui utilise IPv6 à l'état pur, vous ne pouvez pas utiliser Internet Explorer 7 pour accéder à vSphere Web Client.

      Solution :Utilisez Firefox ou Internet Explorer 8 pour accéder à vSphere Web Client.

    • Internet Explorer peut ne pas réussir à télécharger le plug-in d'intégration de client
      Quand vous utilisez Internet Explorer pour télécharger le plug-in intégration de client, le message suivant peut éventuellement apparaître : Internet Explorer ne peut pas télécharger vmware-vmcr-win32-x86.exe depuis localhost.Le problème survient quand certains paramètres de sécurité d'Internet Explorer empêchent le téléchargement du plug-in intégration de client.

      Solution : Utilisez une autre méthode pour télécharger le plug-in intégration de client.

      • Utilisez Firefox pour vous connecter à vSphere Web Client, et téléchargez le plug-in intégration de client.

      • Utilisez Internet Explorer pour vous connecter au fichier du plug-in intégration de client directement via le port non sécurisé http:// ipaddress: portnumber/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe. Par exemple, http://localhost:9090/vsphere-client/vmrc/vmware-vmrc-win32-x86.exe.

    • vSphere Web Client ne charge pas ou ne rafraîchit pas les données
      vSphere Web Client est parfois incapable de charger ou de rafraîchir les données. La roue du chargement dans l'angle en haut à droite de l'application continue de tourner, et l'information demandée n'apparaît pas.

      Solution : Effectuez une ou plusieurs des procédures suivantes :

      • Cliquez sur le bouton Actualiser du navigateur.
      • Sélectionnez un autre objet dans l'arborescence de l'inventaire, et cliquez sur le bouton Actualiser du navigateur.
      • Vérifiez l'état de santé de vCenter Server et ses services. Redémarrez tous les services qui se sont interrompus.

    • Une erreur survient au moment de la sauvegarde des données des services d'inventaire dans vCenter Server Appliance
      L'exécution du script /usr/lib/vmware-vpx/inventoryservice/scripts/backup.shpour sauvegarder les données des services d'inventaire dans vCenter Server Appliance peut se solder par un échec, avec le message d'erreur suivant qui apparaît : Avertissement de VM du serveur 64 bits Java HotSpot(TM) : Échec de tentative d'allouer des pages de garde pile.Cette erreur survient quand vCenter Server Appliance n'a plus beaucoup de mémoire, et que JVM ne peut pas allouer suffisamment de mémoire pour lancer le processus.

      Solution : Augmentez la RAM système de vCenter Server Appliance.

    • Échec du redémarrage de vpxd dans vCenter Server Appliance avec une erreur de base de données
      Dans vCenter Server Appliance doté d'une base de données intégrée, le redémarrage de vpxdpeut échouer. Un message d'erreur semblable au suivant apparaît dans le fichier vpxd.log:
      Alert:false@ /build/mts/release/bora-336896/bora/vpx/vpxd/util/vpxdVdb.cpp:403

      Cette erreur survient si l'horloge du système dans vCenter Server Appliance est réinitialisée à une heure antérieure à celle à laquelle la base de données a été créée. Au final, les objets de la base de données créée par vCenter Server Appliance sont horodatés dans un temps dans le futur. En conséquence, les requêtes au regard des objets de la base de données n'aboutissent pas.

      Vous pouvez rencontrer cette erreur pendant la configuration d'Active Directory si l'horloge du contrôleur de domaine d'Active Directory est réglée à une heure antérieure à celle de l'horloge de vCenter Server Appliance ; en effet, pendant la configuration, l'horloge de vCenter Server Appliance est synchronisée avec l'horloge du contrôleur de domaine d'Active Directory.

      Solution : Après avoir configuré la base de données intégrée, ne réglez pas l'horloge système de vCenter Server Appliance à une heure antérieure. Quand vous configurez Active Directory, assurez-vous que l'horloge du contrôleur de domaine d'Active Directory n'est pas réglée à une heure antérieure à celle de l'horloge de vCenter Server Appliance.

    • La commande vCLI pour effacer la configuration de l'agent SNMP intégré réinitialise la source des indications et supprime les filtres d'interruption
      La commande vCLI vicfg-snmp -rpour effacer la configuration de l'agent SNMP intégré réinitialise la source des événements ou les interruptions par défaut, indications, et supprime tous les filtres d'interruption.

      Solution :Aucune.

    • Échec de l'activation de l'agent SNMP intégré avec une erreur d'adresse déjà utilisée
      Quand vous configurez un port autre que udp/161 pour l'agent SNMP intégré tandis que l'agent n'est pas activé, l'agent ne vérifie pas si le port est utilisé. Au final, vous risquez de vous heurter à un conflit de port quand vous activez l'agent, générant le message d'erreur suivant : Adresse déjà utilisée.

      Solution : Activez l'agent SNMP intégré avant de configurer le port.

    • La page de connexion de vSphere Web Client n'est pas accessible depuis la page d'accueil de vCenter Server
      Si vous utilisez une URL d'hôte local pour accéder à la page d'accueil de vCenter Server, un clic sur Connexion dans vSphere Web Client aboutit à une erreur.

      Solution : Utilisez l'adresse IP ou le nom d'hôte du système vCenter Server pour accéder à la page d'accueil.

    • La boîte de dialogue Sélectionner les utilisateurs et les groupes dans vSphere Client affiche des noms d'utilisateur et de groupe tronqués
      Quand vous ajoutez une permission à un objet d'inventaire dans vSphere Client, les noms d'utilisateur et de groupe risquent d'apparaître tronqués dans la boîte de dialogue Sélectionner les utilisateurs et les groupes. Par exemple, Administrateur risque d'apparaître sous la forme teur. Pour sélectionnez les utilisateurs et les groupes, vous devez tapez le nom complet correct.

      Ce problème survient quand le service de Workstation dans Windows est arrêté.

      Solution : Redémarrez le service Workstation sur la machine vCenter Server.

      1. Sélectionnez Démarrer > Programmes > Outils d'administration > Services.
      2. Cliquez avec le bouton droit sur Workstation, et sélectionnez Démarrer.

    • La liste des machines virtuelles exportée peut s'avérer incomplète
      Quand vous sélectionnez un centre de données, un cluster, un hôte ou un autre objet dans l'inventaire de vSphere Client et que vous exportez une liste de ses machines virtuelles, la liste peut ne pas inclure la totalité des machines virtuelles. Ce problème provient du fait que l'information dans la liste n'est pas toujours renseignée au regard des objets qui ne sont pas visibles.

      Solution :Avant de procéder à l'exportation, faites défiler la liste pour vérifier que toutes les machines virtuelles sont visibles.

    • Des messages d'erreur fallacieux apparaissent dans les fichiers journaux de vSphere Web Client
      Certains messages d'erreur fallacieux apparaissent dans les fichiers journaux de vSphere Web Client en raison des versions de Tomcat et de dm Server utilisées. Il s'agit entre autres d'un certain nombre de messages INFOet du message GRAVE : Aucun contexte global défini pour le serveur.Vous pouvez ignorer ces messages.

      Solution :Aucune.

    • L'aide en ligne de vSphere Web Client répertorie à tort Firefox 3.5 comme navigateur pris en charge
      L'aide en ligne de vSphere Web Client répertorie à tort Firefox 3.5 comme navigateur Web pris en charge au regard de vSphere Web Client et du plug-in intégration de client.

      Solution :Pour plus d'informations sur les navigateurs Web pris en charge, consultez la documentation Installation et configuration de vSphere.

    • vSphere Client affiche un message d'erreur lorsque vous tentez de visualiser les profils de stockage des machines virtuelles
      Lorsque vous connectez vSphere Client à vCenter Server et que vous tentez de visualiser le profil de stockage d'une machine virtuelle, le message d'erreur suivant peut apparaître,

      • VC ne parvient pas à se connecter au service de stockage piloté par profil à http:///sps/sdk.

        Un conflit entre ports survient quand le service des profils de stockage et un autre service sont configurés pour utiliser le port 31000. vSphere Web Client et vCenter Orchestrator peuvent être à l'origine de ce conflit.

        Solution :Redémarrez le service vSphere Web Client et le service de configuration vCenter Orchestrator. Les services choisiront le prochain port disponible à leur redémarrage. Si un seul des services est présent ou fonctionne sur la machine, vous devrez redémarrer uniquement ce service.

      • L'information dans l'onglet Machines virtuelles ne se réactualise pas systématiquement
        Parfois, l'information dans l'onglet Machines virtuelles de vSphere Client ne se réactualise pas systématiquement tout de suite. Par exemple, si vous clonez ou enregistrez un grand nombre de machines virtuelles, certaines d'entre elles peuvent ne pas apparaître dans l'onglet Machines virtuelles, alors qu'elles figurent dans l'arborescence de l'inventaire. Si vous mettez sous tension ou hors tension un grand nombre de machines virtuelles, le nouvel état d'alimentation peut ne pas se refléter dans l'onglet Machines virtuelles, tandis qu'il apparaît correctement dans l'arborescence de l'inventaire.

        Solution : Appuyez sur F5 pour actualiser les informations dans l'onglet.

      • La console Web de VMware vCenter Server Appliance dispose d'options pour configurer IPv6, même si IPv6 n'est pas pris en charge
        Bien que VMware vCenter Server Appliance ne prenne pas en charge IPv6, l'onglet Réseau de la console Web de VMware vCenter Server Appliance dispose d'une option de configuration pour IPv6, et attribuera par défaut une adresse IPv6 au dispositif si un serveur DHCPv6 se trouve sur le réseau.

        Solution : Entrez une adresse IPv6 statique non valide pour VMware vCenter Server Appliance afin d'empêcher le dispositif d'obtenir une adresse IPv6 via DHCP.

      • vSphere Web Client ne se charge pas dans Internet Explorer 9 sous Windows Server 2008
        Quand vous tentez de charger vSphere Web Client dans Internet Explorer 9 sous Windows Server 2008, un fond bleu apparaît dans la fenêtre du navigateur Web, sans aucune activité.

        Solution : Sous Windows Server 2008, utilisez Internet Explorer 7 ou 8, ou Mozilla Firefox 3.6 ou une version ultérieure pour accéder à vSphere Web Client.

      • L'état de vSphere Web Client ne demeure pas entre sessions
        L'état de vSphere Web Client demeure normalement entre les sessions, de sorte que quand vous vous reconnectez à vSphere Web Client, les mêmes objets et onglets que ceux sélectionnés quand vous vous êtes déconnecté de la session précédente le sont encore. Toutefois, si les préférences de votre navigateur Web sont définies de façon que le navigateur ne se rappelle pas l'historique, ou si les paramètres de site Web de Flash Player n'allouent pas de stockage pour les sites consultés, Flash Player ne stocke pas les données de vSphere Web Client, et l'état ne demeure pas d'une session à l'autre.

        Solution : Procédez comme suit :

        1. Rendez-vous sur http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html, et assurez-vous que le volume de stockage est réglé à une valeur autre que Aucune.
        2. Si vous utilisez le navigateur Firefox, réglez les paramètres d'historique du navigateur :
          1. Sélectionnez Outils > Options.
          2. Cliquez sur Confidentialité.
          3. Sélectionnez une option autre que Ne jamais mémoriser l'historique.

      • vSphere Web Client produit, par intermittence, l'erreur #2406 : Le fichier chargé ne comporte pas de signature valide.
        Lors de l'utilisation de Mozilla Firefox 3.6.x sur SUSE Linux Enterprise Server 11 ou Red Hat Enterprise Linux 5, le message d'erreur suivant peut survenir par intermittence : Erreur #2406 : Le fichier chargé ne comporte pas de signature valide.

        Redémarrez le navigateur Web et reconnectez-vous à vSphere Web Client.

      • vCenter Server plante lors de l'exportation des journaux système.
        Lorsque vous exportez des journaux système depuis vCenter Server, vCenter Server utilise le dossier spécifié par la variable d'environnement TEMPde Windows. Par défaut, la variable est définie sur C:\Windows\Temp.

        Si vCenter Server est configuré pour stocker une grande quantité de données de journaux, ou si vous sélectionnez un grand nombre d'hôtes à partir desquels télécharger les journaux, le lecteur spécifié dans la variable TEMPpeut manquer d'espace disponible. Si ce lecteur est le même lecteur que celui sur lequel vCenter Server est installé, le service VMware VirtualCenter Server est susceptible de planter.

        Solution : Assurez-vous que le lecteur spécifié par la variable d'environnement TEMPde Windows dispose d'assez d'espace pour les journaux exportés. Envisagez de spécifier un autre lecteur que C:dans la variable TEMPpour éviter l'interruption des services du système.

      • La recherche d'informations dans vSphere Client ou vSphere Web Client présente des résultats dépassés ou expire.
        Lorsque vous consultez l'inventaire vSphere Client ou vSphere Web Client, la recherche peut présenter des informations dépassées ou, dans le cas de vSphere Web Client, expirer.

        Le message d'erreur suivant, indiquant une erreur d'exécution inattendue, apparaît dans le fichier journal du service d'inventaire, ds.log :
        [2011-06-27 18:04:25,367 pool-14-thread-5 ERROR
        com.vmware.vim.query.server.provider.impl.ProviderManagerServiceImpl] Exception d'exécution inattendue :
        com.xhive.error.XhiveInterruptedException : INTERROMPU

        Solution : Redémarrez Inventory Service.

        Pour un système vCenter Server exécuté sur Windows, effectuez les étapes suivantes :

        1. Démarrez Windows Service Manager :
          1. Sélectionnez Démarrer > Exécuter.
          2. Saisissez services.msc .
        2. Cliquez avec le bouton droit de la souris sur vCenter Inventory Service et sélectionnez Redémarrer.

        Pour vCenter Server Appliance, effectuez les étapes suivantes :
        1. Connectez-vous à la console Web de VMware vCenter Server Appliance.
        2. Dans l'onglet vCenter Server, sélectionnez Statut.
        3. Cliquez sur Arrêter vCenter.
        4. Cliquez sur Démarrer vCenter.

      Gestion des machines virtuelles
      • Pilote indisponible pour le contrôleur xHCI au regard des périphériques USB 3.0
        La version 8 du matériel virtuel inclut la prise en charge pour le contrôleur xHCI et les périphériques USB 3.0. Il se peut toutefois qu'un pilote xHCI ne soit pas disponible pour plusieurs systèmes d'exploitation. Sans pilote installé sur le système d'exploitation client, vous ne pouvez pas utiliser de périphériques USB 3.0. À ce jour, aucun pilote n'est disponible pour le système d'exploitation Windows. Renseignez-vous sur la disponibilité d'un pilote auprès du fournisseur de votre système d'exploitation. Quand vous créez ou mettez à niveau des machines virtuelles équipées de systèmes d'exploitation clients Windows, vous pouvez continuer d'utiliser le contrôleur EHCI+UHCI existant qui prend en charge les périphériques USB 1.1 et 2.0 pour la configuration USB entre un hôte ESXi ou un ordinateur client et une machine virtuelle. Si votre machine virtuelle Windows dispose de contrôleurs USB xHCI et EHCI+UHCI, les périphériques USB 1.1 et USB 2.0 récemment ajoutés seront connectés à xHCI, et le client ne les détectera pas.

        Solution : Retirez le contrôleur xHCI de la configuration de la machine virtuelle pour connecter les périphériques USB à EHCI+UHCI.

      • Les noyaux Linux antérieurs à la version 2.6.27 ne signalent pas l'autoalimentation de 2 cœurs par socket
        À commencer avec ESXi 5.0, la prise en charge des CPU virtuels multi-cœurs permet l'autoalimentation de 2 cœurs par socket. Les noyaux Linux antérieurs à la version 2.6.27 signalent bien uniquement l'alimentation de 2 valeurs pour les cœurs par socket. Par exemple, il se peut que certains systèmes d'exploitation clients Linux ne signalent aucune information d'ID physique quand vous définissez numvcpus = 6et cpuid.coresPerSocket = 3dans le fichier .vmx. Les noyaux Linux 2.6.28 et plus signalent l'UC et la topologie des cœurs correctement.

        Solution : Aucune

      • Quand vous ajoutez de la mémoire à chaud sur les machines virtuelles équipées des systèmes d'exploitation clients Linux 64 bits, Windows 7 ou Windows 8 32 bits, vous ne pouvez pas augmenter la mémoire virtuelle existante à plus de 3 Go
        Les conditions suivantes s'appliquent à l'ajout de mémoire à chaud sur des machines virtuelles dotées des systèmes d'exploitation clients Linux 64 bits ou Windows 7 32 bits.

        • Si la machine virtuelle sous tension dispose d'une mémoire inférieure à 3 Go, vous ne pouvez ajouter à chaud plus de 3 Go de mémoire.
        • Si la machine virtuelle possède 1 Go de mémoire, vous pouvez ajouter 2 Go de mémoire.
        • Si la machine virtuelle possède 2 Go de mémoire, vous pouvez ajouter 1 Go de mémoire.
        • Si la machine virtuelle possède 3 444 Mo de mémoire, vous pouvez ajouter 128 Mo de mémoire.
        • Si la machine virtuelle sous tension dispose d'une mémoire de 3 Go exactement, vous ne pouvez ajouter aucune mémoire à chaud.

        Si la machine virtuelle sous tension dispose d'une mémoire supérieure à 3 Go, vous pouvez augmenter la mémoire de la machine virtuelle jusqu'à 16 fois la taille de celle sur la machine virtuelle initiale sous tension ou jusqu'à la limite de la version matérielle, à savoir la plus petite valeur des deux. La limite de la version matérielle est de 255 Go pour la version matérielle 7 et de 1 011 Go pour la version matérielle 8.

        Les systèmes d'exploitation clients Linux 64 bits et Windows 7 et Windows 8 32 bits se bloquent quand la mémoire croît d'une valeur inférieure ou égale à 3 Go à une valeur supérieure à 3 Go tandis que la machine virtuelle est sous tension. Cette restriction vSphere garantit que vous ne déclencherez pas ce bogue dans le système d'exploitation client.

        Solution :Aucune.

      • Erreur d'ajout à chaud d'un CPU sur les machines virtuelles dotées de la version matérielle 7
        L'ajout à chaud de CPU virtuels est pris en charge avec la fonction CPU virtuels multicœurs pour les machines virtuelles équipées de la version matérielle 8.
        Pour les machines virtuelles dotées de la version matérielle 7 avec plus d'une cœur par socket, quand vous activez la fonction Ajout à chaud de CPU dans la boîte de dialogue Propriétés de la machine virtuelle, et que vous tentez d'ajouter des CPU virtuels à chaud, l'opération échoue, et le message d'erreur suivant apparaît : CPU enfichable à chaud n'est pas pris en charge pour cette machine virtuelle.

        Solution : Pour utiliser la fonction Ajout à chaud de CPU avec des machines virtuelles correspondant à la version matérielle 7, réglez le nombre de cœurs par socket sur 1.
        Pour optimiser les résultats, utilisez des machines virtuelles correspondant à la version matérielle 8.

      • L'ajout à chaud de mémoire sur un système Windows 2003 32 bits qui utilise le pilote LSISAS du 20 novembre 2007 peut entraîner l'absence de réaction de la machine virtuelle
        Le pilote LSI-SAS du 20 novembre 2007 ne peut pas gérer correctement une mémoire supérieure à 3 Go si celle-ci n'est pas présente au démarrage du système. Quand vous ajoutez à chaud de la mémoire à un système qui en disposait moins de 3 Go initialement, et qui se retrouve avec plus de 3 Go de mémoire après l'ajout à chaud, l'état du système Windows est altéré, et Windows peut au final cesser de réagir.

        Solution : Utilisez le dernier pilote LSI SAS disponible sur le site Web de LSI. N'utilisez pas l'adaptateur virtuel LSISAS1068 sur les machines virtuelles Windows 2003.

      • Une adresse IPv6 incorrecte apparaît dans l'onglet Résumé sur les systèmes d'exploitation clients MacOS X Server 10.6.5 et plus
        Quand vous cliquez sur Afficher tout dans l'onglet Résumé dans vSphere Client, la liste des adresses IPv6 comporte une adresse locale de lien incorrecte. L'adresse incorrecte apparaît quand vous exécutez le fichier ifconfig, et que vous comparez la sortie de la commande avec la liste des adresses dans vSphere Client. Elle s'affiche aussi quand vous exécutez la commande vim-cmdpour obtenir les données GuestInfo.

        Solution : Aucune

      • La création d'un grand nombre de machines virtuelles en même temps entraîne l'échec de certaines opérations de fichiers
        Quand vous créez simultanément un grand nombre de machines virtuelles qui résident dans le même répertoire, le système de stockage est submergé, et certaines opérations de fichiers se soldent par un échec. Un message d'erreur vim.fault.CannotAccessFileapparaît, et l'opération Créer une machine virtuelle n'aboutit pas.

        Solution : Créez des machines virtuelles supplémentaires par petits lots, par exemple par lots de 64, ou essayez de créer des machines virtuelles dans des banques de données différentes ou au sein de répertoires divers dans la même banque de données.

      • Il se peut que les périphériques USB transmis d'un hôte ESXi vers une machine virtuelle se déconnectent pendant la migration avec vMotion
        Pendant la transmission d'un périphérique USB vers une machine virtuelle depuis un hôte ESXi tandis que le périphérique est configuré pour rester connecté pendant la migration avec vMotion, il se peut que le périphérique se déconnecte durant l'opération vMotion. Les périphériques peuvent aussi se déconnecter si DRS déclenche une migration. Quand les périphériques se déconnectent, ils retournent à l'hôte et ne sont plus connectés à la machine virtuelle. Ce problème survient plus souvent quand vous migrez des machines virtuelles dotées de plusieurs périphériques USB connectés, mais seulement occasionnellement quand un seul périphérique est connecté ou que leur nombre est plus petit.

        Solution :Remigrez la machine virtuelle vers l'hôte ESXI auquel les périphériques USB sont physiquement raccordés et reconnectez ceux-ci à la machine virtuelle.

      • Une machine virtuelle avec un périphérique de liaison SCSI inaccessible ne parvient pas à mettre sous tension
        Si un périphérique de liaison SCSI fixé à une machine virtuelle dispose d'un support qui s'avère inaccessible depuis l'hôte de la machine virtuelle, celle-ci ne parvient pas à mettre sous tension, et l'erreur suivante apparaît : une erreur inattendue a été reçue de l'hôte ESX lors de la mise sous tension de VM.

        Solution : Effectuez l'une des procédures suivantes :

        • Si l'hôte de la machine virtuelle dispose d'un périphérique SCSI physique, remplacez le support du périphérique de liaison par le périphérique SCSI physique de l'hôte, et mettez sous tension la machine virtuelle.
        • Si l'hôte ne possède pas de périphérique SCSI physique, retirez le périphérique de liaison SCSI de la machine virtuelle, et mettez sous tension celle-ci.

      • Il se peut que l'icône de VMware Tools sur la barre d'état système indique à tort Périmé
        Si une machine virtuelle utilise VMware Tools qui a été installé avec vSphere 4.x, l'icône sur la barre d'état du système d'exploitation client indique à tort Périmé. Dans vSphere 5.0 Client et dans vSphere Web Client, l'onglet Résumé au regard de la machine virtuelle indique l'état Out-of-date (OK. Cette version est prise en charge sur l'hôte existant, mais doit être mise à niveau si la nouvelle fonctionnalité ne fonctionne pas). VMware Tools installé avec vSphere 4.x n'est pas pris en charge, sans exiger forcément de mise à niveau vers vSphere 5.0.

        Solutions : Dans vSphere 5.0, utilisez l'onglet Résumé au regard de la machine virtuelle dans vSphere Client ou dans vSphere Web Client pour déterminer l'état de VMware Tools. Si l'état est en effet Périmé, mais que vous ne voulez pas faire de mise à niveau, vous pouvez utiliser les paramètres suivants pour désactiver les invites de mise à niveau et l'icône de mise en garde dans le système d'exploitation client :

        • Si la machine virtuelle est réglée de sorte à automatiquement mettre VMware Tools à niveau, mais que vous voulez que la machine virtuelle demeure à la version prise en charge la plus basse, définissez la propriété suivante comme paramètre de configuration avancée : définissez tools.supportedOld.autoupgradesur FALSE. Ce paramètre désactive aussi dans le client l'icône du point d'exclamation, qui prévient que VMware Tools n'est pas pris en charge.
        • Si VMware Tools est périmé, et que vous voulez désactivez l'icône du point d'exclamation qui apparaît au niveau de l'icône de VMware Tools dans la barre d'état système, définissez la propriété suivante comme paramètre de configuration avancée : définissez tools.supportedOld.warnsur FALSE.

        Aucun de ces paramètres n'a d'incidence sur le comportement de VMware Tools quand l'onglet Résumé indique l'état Non pris en charge ou Erreur. Dans ces situations, l'icône du point d'exclamation apparaît, et VMware Tools est automatiquement mis à niveau (si telle est la configuration), même quand les paramètres de configuration avancée sont définis sur FALSE. Vous pouvez définir les paramètres de configuration avancée soit en modifiant le fichier de configuration de la machine virtuelle, .vmx, soit en utilisant vSphere Client ou vSphere Web Client pour modifier les paramètres de la machine virtuelle. Dans l'onglet Options, sélectionnez Avancés > Général, et cliquez sur Paramètres de configuration.

      • La fonction de contrôle et de mise à niveau de Tools pendant le cycle d'alimentation ne fonctionne pas dans ESXi 5.0 et les versions ultérieures
        Dans ESX/ESXi 4.1, l'option de contrôle et de mise à niveau de Tools pendant le cycle d'alimentation était disponible pour mettre à niveau VMware Tools au moment de la mise à l'arrêt de la machine virtuelle. Cette fonction ne fonctionne pas dans ESXi 5.0 et les versions ultérieures. Ignorez toutes les procédures décrites dans la documentation concernant cette fonction.

        Solution : Installez VMware Tools manuellement.

      • Les systèmes d'exploitation client Mac OS X à forte utilisation de CPU et de mémoire peuvent se heurter à une alerte de noyau pendant les opérations d'interruption ou de reprise ou de migration de la machine virtuelle
        Suite à des opérations d'interruption ou de reprise d'une machine virtuelle ou à la migration avec vMotion sur un hôte dont la charge en CPU ou en mémoire est lourde, la demande d'invalidation TLB (Translation Lookaside Buffer) risque d'être interrompue. En pareils cas, le système d'exploitation client Mac OS X cesse de réagir, et une variante d'un des messages suivants s'inscrit dans le fichier vmware.log :
        The guest OS panicked. The first line of the panic report is: Panic(CPU 0): Unresponsive processor
        The guest OS panicked. The first line of the panic report is: panic(cpu 0 caller 0xffffff8000224a10): "pmap_flush_tlbs()timeout: " "cpu(s) failing to respond to interrupts,pmap=0xffffff800067d8a0 cpus_to_respond=0x4"@/SourceCache/xnu/xnu-1504.7.4/osfmk/x86_64/pmap.c:2710

        Solution : Diminuez la charge en CPU et en mémoire sur l'hôte ou réduisez le nombre de CPU virtuels à 1.

      • Les opérations de clonage ou de déplacement d'une machine virtuelle de ESXi 5.0 vers ESX/ESXi 4.1 échouent si la réplication est activée
        Si vous utilisez la commande hbr enablereplicationpour activer la réplication sur une machine virtuelle qui réside sur un hôte ESXi 5.0 et cloner la machine virtuelle vers un hôte ESX/ESXi 4.1 ou de version antérieure, la validation échoue, et le message d'erreur suivant apparaît : l'opération n'est pas prise en charge. Le clonage des machines virtuelles ESXi 5.0 sur des hôtes ESX/ESXi 4.1 n'est pas pris en charge.

        Solution :Sélectionnez l'une des solutions suivantes :

        • Clonez la machine virtuelle sur un hôte ESXi 5.0.
        • Clonez ou déplacez une nouvelle machine virtuelle sur un hôte ESX/ESXi 4.1.

    • L'incompatibilité entre vCenter Server 5.0 et les hôtes ESX/ESXi est à l'origine de l'échec des opérations de migration des machines virtuelles avec des disques delta
      Si vCenter Server 5.0 gère un hôte dont la version est antérieure à ESX/ESXi 4.0 Update 3, vous ne pouvez pas migrer des machines virtuelles avec des snapshots ou des disques delta vers l'hôte. Toute tentative d'une telle migration donne lieu au message d'erreur système suivant : Migration of VMs with snapshots or delta disks is not supported due to version incompatibility between vCenter Server and ESX. To continue this operation, please upgrade your ESX host(s) to ESX 4.0 Update 3 or later.
      La même restriction s'applique, et un message d'erreur semblable apparaît pour ESX/ESXi 4.1. ESX/ESXi 4.1 ne prend pas en charge la migration des machines virtuelles avec des disques delta si vCenter Server 5.0 gère l'hôte.

      Solution :Effectuez une mise à niveau de l'hôte ESX/ESXi vers ESX/ESXi 4.0 Update 3 ou une version ultérieure ou vers ESX 4.1 Update 1 ou une version ultérieure.

    • Impossible de définir les scripts VMware Tools sur mesure via l'IU de VMware-Toolbox dans le système d'exploitation client Linux quand le chemin d'accès aux scripts sur mesure contient des caractères non-ASCII
      Des caractères non-ASCII, comme des cases carrées avec un Xà l'intérieur, apparaissent dans la fenêtre Propriétés de VMware Tools dans les systèmes d'exploitation clients Linux quand l'option régionale du système est zh_CN.gb18030, ja_JP.eucjp,ou ko_KR.euckr. En pareils cas, vous ne pouvez pas définir des scripts VMware Tools sur mesure.

      Solution : Exécutez l'une des tâches suivantes :

      • Changez le nom du répertoire où figurent les scripts VMware Tools sur mesure de sorte qu'il contienne des caractères ASCII uniquement.
      • Définissez les scripts VMware Tools sur mesure en tapant la commande vmware-toolbox-cmd scriptà une invite du shell.

    • Les suffixes DNS non-ASCII ne sont pas correctement définis après la personnalisation de Windows XP et de Windows 2003
      Si vous entrez un suffixe DNS non-ASCII dans l'onglet DNS de Propriétés de réseau quand vous utilisez l'assistant de spécification de personnalisation pour personnaliser Windows XP ou Windows 2003, la personnalisation est signalée comme ayant réussi, mais le suffixe DNS non-ASCII n'est pas correctement défini.

      Solution :Définissez le suffixe DNS manuellement dans Windows XP et dans Windows 2003.

    • L'agent SNMP intégré à VMware signale un statut incorrect pour les processeurs dans l'objet hrDeviceStatusdu module HOST-RESOURCES-MIB.
      En présentant les informations du système, l'agent SNMP intégré à VMware affiche un statut incorrect pour les processeurs. L'agent SNMP présente un statut Unknownpour les processeurs de l'objet hrDeviceStatusdans HOST-RESOURCES-MIB. L'implémentation ESX/net-snmp de HOST-RESOURCES-MIB ne renvoie pas l'objet hrDeviceStatus, ce qui revient à signaler un statut unknown.

      Solution : Utilisez les données CIM APIs ou SMBIOS pour vérifier le statut des processeurs.

    • Le chemin du disque des snapshots dans le fichier de la base de données des snapshots .vmsd et le chemin parent dans le fichier descripteur de disque delta ne sont pas mis à jour après la migration.
      Lorsque snapshot.redoNotWithParentest défini sur TRUEet que vous modifiez la configuration de snapshotDirectory, par exemple, de Base de données A en Base de données B, le message Configuration snapshot non valide détectéepeut s'afficher. Ce problème survient lorsque les deux conditions suivantes sont présentes :

      • Vous rétablissez un ancien snapshot dans l'arborescence de snapshot et créez des snapshots depuis ce point de snapshot. Cela résulte en une hiérarchie d'arborescence de snapshot non linéaire.
      • Les liens de disque dans une chaîne de disques couvrent plusieurs banques de données et comprennent à la fois les banques de données source et de destination. Cette situation se produit si vous modifiez les paramètres snapshotDirectoryde sorte à ce qu'ils pointent vers différentes banques de données à plusieurs reprises et prennent des snapshots de la machine virtuelle entre les modifications de snapshotDirectory. Par exemple, vous prenez des snapshots d'une machine virtuelle avec snapshotDirectorydéfini sur Banque de données A, rétablissez un ancien snapshot, puis modifiez les paramètres snapshotDirectoryen Banque de données B et prenez des snapshots supplémentaires. Enfin, vous migrez le disque virtuel de Banque de données B vers Banque de données A.

      Il est recommandé de conserver la configuration par défaut, qui stocke les snapshots parents et enfants ensemble, dans le répertoire des snapshots. Évitez de modifier les paramètres snapshotDirectoryou de prendre des snapshots entre les modifications des banques de données. Si vous définissez snapshot.redoNotWithParentsur TRUE, réalisez une migration de stockage complète vers une banque de données qui n'est pas utilisée par la machine virtuelle.

       

      Solution : Réalisez une mise à jour manuelle des références du chemin d'accès au disque vers le bon chemin d'accès à la banque de données dans le fichier de la base de données des snapshots et le fichier de description du disque.

      • La migration à froid d'une machine virtuelle dotée d'un disque IDE virtuel d'un hôte ESXi 5.0 vers un hôte ESX/ESXi 4.x échoue, et l'erreur suivante s'affiche : l'opération n'est pas prise en charge sur l'objet.
        Quand vous utilisez vCenter Server 5.0 pour migrer à froid une machine virtuelle dotée d'un ou plusieurs disques IDE virtuels d'un hôte ESXi 5.0 vers un hôte sous ESX/ESXi 4.x, la migration échoue, et l'erreur suivante apparaît : l'opération n'est pas prise en charge sur l'objet.

        Solution : Procédez comme suit :

        1. Sur l'hôte ESXi 5.0, sélectionnez la machine virtuelle.
        2. Si la machine virtuelle réside dans une banque de données d'hôte uniquement sur l'hôte ESXi 5.0, déplacez les fichiers .vmxet .vmdkde la machine virtuelle vers un LUN partagé accessible à l'hôte ESXi 5.0 et à l'hôte ESX/ESXi 4.x.
        3. Migrez à froid la machine virtuelle vers l'hôte ESX/ESXi 4.x en utilisant l'option Changer l'hôte dans l'assistant de migration de machine virtuelle.
           
      • Pendant le passage à l'heure d'été, l'axe du temps sur les graphiques de performance n'est pas actualisé et ne reflète pas le changement d'heure.
        Par exemple, les horloges locales dans les régions qui respectent l'heure d'été ont été avancées d'une heure le dimanche 27 mars 2011 à 3 heures du matin. Les lignes guides sur l'axe du temps des graphiques de performances devraient être libellées ..., 2:00, 2:20, 2:40, 4:00, 4:20, ..., omettant les lignes à 3 heures du matin. Les libellés affichés en réalité sont ..., 2:00, 2:20, 2:40, 3:00, 3:20, 3:40, 4:00, 4:20, ....

        Solution : Aucune

      • Les disques de la machine virtuelle gardent leur format d'origine après l'opération Storage vMotion où l'utilisateur précise un changement de format de disque
        Quand vous tentez de convertir le format de disque en Provisionnement statique immédiatement mis à zéro pendant une opération Storage vMotion d'une machine virtuelle sous tension sur un hôte ESX/ESXi 4.1 ou d'une version antérieure, la conversion ne se fait pas. L'opération Storage vMotion réussit, mais les disques gardent leur format d'origine en raison d'une limite inhérente à ESX/ESXi 4.1 et aux versions antérieures. Si vous effectuez la même opération sur une machine virtuelle sur un hôte ESXi 5.0, la conversion se fait avec succès.

        Solution :Aucune.

      • L'utilitaire de vCenter Server ne peut pas trouver les données de consignation stockées à un endroit sur mesure
        L'utilitaire de vCenter Server ne peut pas localiser les fichiers journaux qui sont stockés en des lieux personnalisés, à savoir autres que par défaut. L'utilitaire de vCenter Server diffère de l'outil de collecte des données de consignation de vSphere Client.

        Solution : Connectez vSphere Client à vCenter Server et utilisez la fonction Exporter les journaux système pour extraire les données du journal. Dans vSphere Client, sélectionnez Administration > Exporter les journaux système.

        Quand vous ne pouvez pas connecter vSphere Client à vCenter Server, vous devez copier manuellement les fichiers dans l'utilitaire.

      • Dans vCenter Server 5.0, un certain nombre d'options de configuration avancée pour vSphere HA ne sont plus prises en charge.
        Les options suivantes ne sont plus prises en charge.

        das.consoleUser
        das.consoleNode
        das.consolePerm
        das.primaryCount
        das.checkVmStateDelay
        das.trace
        das.traceLevel
        das.traceOutput
        das.preferredPrimaries
        das.disableUWSwapRequirement
        das.sensorPollingFreq
        das.bypassNetCompatCheck
        das.defaultfailoverhost
        das.failureDetectionTime
        das.failureDetectionInterval

        Si vous tentez de définir une des options non prises en charge, vCenter Server 5.0 signale que l'option n'est pas valable. Si vous faites une mise à niveau vCenter Server 5.0 depuis une version précédente avec une quelconque de ces options définies, elles seront supprimées, et n'auront plus effet.

        Solution :Aucune.

      • Lorsque qu'un échec d'hôte s'est produit, vSphere HA ne parvient pas à redémarrer une machine virtuelle en cours de migration à l'aide de vMotion.
        Lorsqu'une machine virtuelle est en cours de migration d'un premier hôte vers un second, l'hôte d'origine peut échouer, ne plus répondre ou perdre l'accès à la banque de données contenant le fichier de configuration de la machine virtuelle. Si un tel échec se produit et qu'ensuite vMotion échoue également, il est possible que vSphere HA ne redémarre pas et ne protège pas la machine virtuelle.

        Solution : Si la machine virtuelle échoue et que vSphere HA ne la remet pas sous tension, remettez la machine virtuelle sous tension manuellement. vSphere HA protégera alors la machine virtuelle.

      • Les périphériques USB 3.0 ne fonctionnent pas avec les machines virtuelles Windows 8 ou Windows Server 2012*
        Lorsque vous utilisez des périphériques USB 3.0 avec des machines virtuelles Windows 8 ou Windows Server 2012 avec un système d'exploitation Windows ou Linux comme le Client, des messages d'erreur similaires au suivant peuvent s'afficher :
        Port Reset Failed
        The USB set SEL request failed

        Solution : Aucune

      • Le démarrage PXE ou le redémarrage de RHEL 6 donne lieu à un écran vierge
        Quand vous tentez d'utiliser le programme d'amorçage Red Hat pour démarrer PXE dans RHEL 6 sur une machine EFI virtuelle, l'écran se vide après que vous sélectionnez le système d'exploitation. Ce problème survient aussi si vous supprimez la directive splashscreendu fichier grub.conf dans une installation régulière de RHEL 6 et que vous redémarrez la machine virtuelle.

        Solution : Vérifiez que la directive splashscreenest présente et qu'elle fait référence à un fichier accessible au programme d'amorçage.

      • Plusieurs vNIC se déconnectent au hasard au démarrage de Mac OS X 10.6.x
        Quand vous redémarrez Mac OS X 10.6, un état de lien client incorrect s'affiche pour n >=3 e1000 vNIC.

        Si n(e1000)=3, l'état du lien client est : 2(connecté), 1 (déconnecté).
        Si n(e1000)=5, l'état du lien client est : 3(connecté), 2(déconnecté), etc.

        Solution : Activez et désactivez manuellement les cartes avec l'utilitaire ifconfig. L'activation et la désactivation manuelles ne demeurent pas jusqu'au prochain processus de redémarrage.

      • IBM x3550 M2 Force Legacy Video on Boot doit être désactivé
        IBM x3550 M2 bénéficie d'une option micrologicielle appelée Force Legacy Video on Boot qui active la prise en charge vidéo INT10h traditionnelle au démarrage depuis l'UEFI (Unified Extensible Firmware Interface ou « interface micrologicielle extensible unifiée »). Cette option n'est pas compatible avec ESXi 5.0, et elle doit être désactivée.

        Solution : Au moment de démarrer IBM x3550 M2 depuis l'UEFI, appuyez sur F1 pour saisir la configuration du micrologiciel, et sélectionnez Paramètres système > Prise en charge traditionnelle > Force Legacy Video on Boot et cliquez sur Désactiver.

      • Les utilisateurs dont les noms contiennent des caractères non-ASCII ne peuvent pas se connecter à vCenter Server via vSphere Web Client
        vSphere Web Client n'accepte pas les noms d'utilisateur contenant des caractères non-ASCII. Les utilisateurs dont les noms contiennent des caractères non-ASCII ne peuvent pas utiliser vSphere Web Client pour se connecter à vCenter Server.

        Solution :Utilisez vSphere Client pour vous connecter à vCenter Server.

      • Problèmes liés à la recherche localisée et au domaine de la recherche dans l'aide de vSphere Web Client
        Les problèmes suivants concernant la recherche localisée dans l'aide de vSphere Web Client ont été identifiés :

        • La recherche de langues différentes de l'anglais à l'aide de caractères localisés ne donne aucun résultat.
        • Si vous créez des noms de domaine de recherche avec des caractères non-ASCII, ceux-ci ne s'affichent pas correctement.

        Solution : Modifiez le fichier tomcat-server.xmlpour définir le codage URI au format UTF-8 :

        1. Ouvrez le fichier vSphere_Web_Client_Installation_Directory\springsource-dm-server-2.0.4\config\tomcat-server.xmldans un éditeur de texte.
        2. Modifiez la section suivante du fichier pour ajouter le paramètre URIEncoding="UTF-8"à la fin de la ligne connectionTimeout="20000":

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000"
          redirectPort="9443" emptySessionPath="true"/>


          9090 est la valeur par défaut pour le port du connecteur. Si vous avez changé cette valeur pendant l'installation, un autre numéro de port apparaît. Ne changez pas le numéro du port.

          Après la modification, la section doit prendre la forme suivante :

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000" URIEncoding="UTF-8"
          redirectPort="9443" emptySessionPath="true"/>
        3. Modifiez la section suivante du fichier pour ajouter le paramètre URIEncoding="UTF-8"à la fin de la ligne keystoreFile="config/keystore" :

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore"
          keystorePass="changeit" emptySessionPath="true"/>


          9443 est la valeur par défaut pour le port du connecteur. Si vous avez changé cette valeur pendant l'installation, un autre numéro de port apparaît. Ne changez pas le numéro du port.

          Après la modification, la section doit prendre la forme suivante :

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore" URIEncoding="UTF-8"
          keystorePass="changeit" emptySessionPath="true"/>
        4. Enregistrez le fichier.
    • Migration VMware HA et Fault Tolerance

      Système d'exploitation client

      Matériel pris en charge Internationalisation

    Un conflit entre ports survient quand le service des profils de stockage et un autre service sont configurés pour utiliser le port 31000. vSphere Web Client et vCenter Orchestrator peuvent être à l'origine de ce conflit.

    Solution :Redémarrez le service vSphere Web Client et le service de configuration vCenter Orchestrator. Les services choisiront le prochain port disponible à leur redémarrage. Si un seul des services est présent ou fonctionne sur la machine, vous devrez redémarrer uniquement ce service.

    Gestion des machines virtuelles
    • Pilote indisponible pour le contrôleur xHCI au regard des périphériques USB 3.0
      La version 8 du matériel virtuel inclut la prise en charge pour le contrôleur xHCI et les périphériques USB 3.0. Il se peut toutefois qu'un pilote xHCI ne soit pas disponible pour plusieurs systèmes d'exploitation. Sans pilote installé sur le système d'exploitation client, vous ne pouvez pas utiliser de périphériques USB 3.0. À ce jour, aucun pilote n'est disponible pour le système d'exploitation Windows. Renseignez-vous sur la disponibilité d'un pilote auprès du fournisseur de votre système d'exploitation. Quand vous créez ou mettez à niveau des machines virtuelles équipées de systèmes d'exploitation clients Windows, vous pouvez continuer d'utiliser le contrôleur EHCI+UHCI existant qui prend en charge les périphériques USB 1.1 et 2.0 pour la configuration USB entre un hôte ESXi ou un ordinateur client et une machine virtuelle. Si votre machine virtuelle Windows dispose de contrôleurs USB xHCI et EHCI+UHCI, les périphériques USB 1.1 et USB 2.0 récemment ajoutés seront connectés à xHCI, et le client ne les détectera pas.

      Solution : Retirez le contrôleur xHCI de la configuration de la machine virtuelle pour connecter les périphériques USB à EHCI+UHCI.

    • Les noyaux Linux antérieurs à la version 2.6.27 ne signalent pas l'autoalimentation de 2 cœurs par socket
      À commencer avec ESXi 5.0, la prise en charge des CPU virtuels multi-cœurs permet l'autoalimentation de 2 cœurs par socket. Les noyaux Linux antérieurs à la version 2.6.27 signalent bien uniquement l'alimentation de 2 valeurs pour les cœurs par socket. Par exemple, il se peut que certains systèmes d'exploitation clients Linux ne signalent aucune information d'ID physique quand vous définissez numvcpus = 6et cpuid.coresPerSocket = 3dans le fichier .vmx. Les noyaux Linux 2.6.28 et plus signalent l'UC et la topologie des cœurs correctement.

      Solution : Aucune

    • Quand vous ajoutez de la mémoire à chaud sur les machines virtuelles équipées des systèmes d'exploitation clients Linux 64 bits, Windows 7 ou Windows 8 32 bits, vous ne pouvez pas augmenter la mémoire virtuelle existante à plus de 3 Go
      Les conditions suivantes s'appliquent à l'ajout de mémoire à chaud sur des machines virtuelles dotées des systèmes d'exploitation clients Linux 64 bits ou Windows 7 32 bits.

      • Si la machine virtuelle sous tension dispose d'une mémoire inférieure à 3 Go, vous ne pouvez ajouter à chaud plus de 3 Go de mémoire.
      • Si la machine virtuelle possède 1 Go de mémoire, vous pouvez ajouter 2 Go de mémoire.
      • Si la machine virtuelle possède 2 Go de mémoire, vous pouvez ajouter 1 Go de mémoire.
      • Si la machine virtuelle possède 3 444 Mo de mémoire, vous pouvez ajouter 128 Mo de mémoire.
      • Si la machine virtuelle sous tension dispose d'une mémoire de 3 Go exactement, vous ne pouvez ajouter aucune mémoire à chaud.

      Si la machine virtuelle sous tension dispose d'une mémoire supérieure à 3 Go, vous pouvez augmenter la mémoire de la machine virtuelle jusqu'à 16 fois la taille de celle sur la machine virtuelle initiale sous tension ou jusqu'à la limite de la version matérielle, à savoir la plus petite valeur des deux. La limite de la version matérielle est de 255 Go pour la version matérielle 7 et de 1 011 Go pour la version matérielle 8.

      Les systèmes d'exploitation clients Linux 64 bits et Windows 7 et Windows 8 32 bits se bloquent quand la mémoire croît d'une valeur inférieure ou égale à 3 Go à une valeur supérieure à 3 Go tandis que la machine virtuelle est sous tension. Cette restriction vSphere garantit que vous ne déclencherez pas ce bogue dans le système d'exploitation client.

      Solution :Aucune.

    • Erreur d'ajout à chaud d'un CPU sur les machines virtuelles dotées de la version matérielle 7
      L'ajout à chaud de CPU virtuels est pris en charge avec la fonction CPU virtuels multicœurs pour les machines virtuelles équipées de la version matérielle 8.
      Pour les machines virtuelles dotées de la version matérielle 7 avec plus d'une cœur par socket, quand vous activez la fonction Ajout à chaud de CPU dans la boîte de dialogue Propriétés de la machine virtuelle, et que vous tentez d'ajouter des CPU virtuels à chaud, l'opération échoue, et le message d'erreur suivant apparaît : CPU enfichable à chaud n'est pas pris en charge pour cette machine virtuelle.

      Solution : Pour utiliser la fonction Ajout à chaud de CPU avec des machines virtuelles correspondant à la version matérielle 7, réglez le nombre de cœurs par socket sur 1.
      Pour optimiser les résultats, utilisez des machines virtuelles correspondant à la version matérielle 8.

    • L'ajout à chaud de mémoire sur un système Windows 2003 32 bits qui utilise le pilote LSISAS du 20 novembre 2007 peut entraîner l'absence de réaction de la machine virtuelle
      Le pilote LSI-SAS du 20 novembre 2007 ne peut pas gérer correctement une mémoire supérieure à 3 Go si celle-ci n'est pas présente au démarrage du système. Quand vous ajoutez à chaud de la mémoire à un système qui en disposait moins de 3 Go initialement, et qui se retrouve avec plus de 3 Go de mémoire après l'ajout à chaud, l'état du système Windows est altéré, et Windows peut au final cesser de réagir.

      Solution : Utilisez le dernier pilote LSI SAS disponible sur le site Web de LSI. N'utilisez pas l'adaptateur virtuel LSISAS1068 sur les machines virtuelles Windows 2003.

    • Une adresse IPv6 incorrecte apparaît dans l'onglet Résumé sur les systèmes d'exploitation clients MacOS X Server 10.6.5 et plus
      Quand vous cliquez sur Afficher tout dans l'onglet Résumé dans vSphere Client, la liste des adresses IPv6 comporte une adresse locale de lien incorrecte. L'adresse incorrecte apparaît quand vous exécutez le fichier ifconfig, et que vous comparez la sortie de la commande avec la liste des adresses dans vSphere Client. Elle s'affiche aussi quand vous exécutez la commande vim-cmdpour obtenir les données GuestInfo.

      Solution : Aucune

    • La création d'un grand nombre de machines virtuelles en même temps entraîne l'échec de certaines opérations de fichiers
      Quand vous créez simultanément un grand nombre de machines virtuelles qui résident dans le même répertoire, le système de stockage est submergé, et certaines opérations de fichiers se soldent par un échec. Un message d'erreur vim.fault.CannotAccessFileapparaît, et l'opération Créer une machine virtuelle n'aboutit pas.

      Solution : Créez des machines virtuelles supplémentaires par petits lots, par exemple par lots de 64, ou essayez de créer des machines virtuelles dans des banques de données différentes ou au sein de répertoires divers dans la même banque de données.

    • Il se peut que les périphériques USB transmis d'un hôte ESXi vers une machine virtuelle se déconnectent pendant la migration avec vMotion
      Pendant la transmission d'un périphérique USB vers une machine virtuelle depuis un hôte ESXi tandis que le périphérique est configuré pour rester connecté pendant la migration avec vMotion, il se peut que le périphérique se déconnecte durant l'opération vMotion. Les périphériques peuvent aussi se déconnecter si DRS déclenche une migration. Quand les périphériques se déconnectent, ils retournent à l'hôte et ne sont plus connectés à la machine virtuelle. Ce problème survient plus souvent quand vous migrez des machines virtuelles dotées de plusieurs périphériques USB connectés, mais seulement occasionnellement quand un seul périphérique est connecté ou que leur nombre est plus petit.

      Solution :Remigrez la machine virtuelle vers l'hôte ESXI auquel les périphériques USB sont physiquement raccordés et reconnectez ceux-ci à la machine virtuelle.

    • Une machine virtuelle avec un périphérique de liaison SCSI inaccessible ne parvient pas à mettre sous tension
      Si un périphérique de liaison SCSI fixé à une machine virtuelle dispose d'un support qui s'avère inaccessible depuis l'hôte de la machine virtuelle, celle-ci ne parvient pas à mettre sous tension, et l'erreur suivante apparaît : une erreur inattendue a été reçue de l'hôte ESX lors de la mise sous tension de VM.

      Solution : Effectuez l'une des procédures suivantes :

      • Si l'hôte de la machine virtuelle dispose d'un périphérique SCSI physique, remplacez le support du périphérique de liaison par le périphérique SCSI physique de l'hôte, et mettez sous tension la machine virtuelle.
      • Si l'hôte ne possède pas de périphérique SCSI physique, retirez le périphérique de liaison SCSI de la machine virtuelle, et mettez sous tension celle-ci.

    • Il se peut que l'icône de VMware Tools sur la barre d'état système indique à tort Périmé
      Si une machine virtuelle utilise VMware Tools qui a été installé avec vSphere 4.x, l'icône sur la barre d'état du système d'exploitation client indique à tort Périmé. Dans vSphere 5.0 Client et dans vSphere Web Client, l'onglet Résumé au regard de la machine virtuelle indique l'état Out-of-date (OK. Cette version est prise en charge sur l'hôte existant, mais doit être mise à niveau si la nouvelle fonctionnalité ne fonctionne pas). VMware Tools installé avec vSphere 4.x n'est pas pris en charge, sans exiger forcément de mise à niveau vers vSphere 5.0.

      Solutions : Dans vSphere 5.0, utilisez l'onglet Résumé au regard de la machine virtuelle dans vSphere Client ou dans vSphere Web Client pour déterminer l'état de VMware Tools. Si l'état est en effet Périmé, mais que vous ne voulez pas faire de mise à niveau, vous pouvez utiliser les paramètres suivants pour désactiver les invites de mise à niveau et l'icône de mise en garde dans le système d'exploitation client :

      • Si la machine virtuelle est réglée de sorte à automatiquement mettre VMware Tools à niveau, mais que vous voulez que la machine virtuelle demeure à la version prise en charge la plus basse, définissez la propriété suivante comme paramètre de configuration avancée : définissez tools.supportedOld.autoupgradesur FALSE. Ce paramètre désactive aussi dans le client l'icône du point d'exclamation, qui prévient que VMware Tools n'est pas pris en charge.
      • Si VMware Tools est périmé, et que vous voulez désactivez l'icône du point d'exclamation qui apparaît au niveau de l'icône de VMware Tools dans la barre d'état système, définissez la propriété suivante comme paramètre de configuration avancée : définissez tools.supportedOld.warnsur FALSE.

      Aucun de ces paramètres n'a d'incidence sur le comportement de VMware Tools quand l'onglet Résumé indique l'état Non pris en charge ou Erreur. Dans ces situations, l'icône du point d'exclamation apparaît, et VMware Tools est automatiquement mis à niveau (si telle est la configuration), même quand les paramètres de configuration avancée sont définis sur FALSE. Vous pouvez définir les paramètres de configuration avancée soit en modifiant le fichier de configuration de la machine virtuelle, .vmx, soit en utilisant vSphere Client ou vSphere Web Client pour modifier les paramètres de la machine virtuelle. Dans l'onglet Options, sélectionnez Avancés > Général, et cliquez sur Paramètres de configuration.

    • La fonction de contrôle et de mise à niveau de Tools pendant le cycle d'alimentation ne fonctionne pas dans ESXi 5.0 et les versions ultérieures
      Dans ESX/ESXi 4.1, l'option de contrôle et de mise à niveau de Tools pendant le cycle d'alimentation était disponible pour mettre à niveau VMware Tools au moment de la mise à l'arrêt de la machine virtuelle. Cette fonction ne fonctionne pas dans ESXi 5.0 et les versions ultérieures. Ignorez toutes les procédures décrites dans la documentation concernant cette fonction.

      Solution : Installez VMware Tools manuellement.

    • Les systèmes d'exploitation client Mac OS X à forte utilisation de CPU et de mémoire peuvent se heurter à une alerte de noyau pendant les opérations d'interruption ou de reprise ou de migration de la machine virtuelle
      Suite à des opérations d'interruption ou de reprise d'une machine virtuelle ou à la migration avec vMotion sur un hôte dont la charge en CPU ou en mémoire est lourde, la demande d'invalidation TLB (Translation Lookaside Buffer) risque d'être interrompue. En pareils cas, le système d'exploitation client Mac OS X cesse de réagir, et une variante d'un des messages suivants s'inscrit dans le fichier vmware.log :
      The guest OS panicked. The first line of the panic report is: Panic(CPU 0): Unresponsive processor
      The guest OS panicked. The first line of the panic report is: panic(cpu 0 caller 0xffffff8000224a10): "pmap_flush_tlbs()timeout: " "cpu(s) failing to respond to interrupts,pmap=0xffffff800067d8a0 cpus_to_respond=0x4"@/SourceCache/xnu/xnu-1504.7.4/osfmk/x86_64/pmap.c:2710

      Solution : Diminuez la charge en CPU et en mémoire sur l'hôte ou réduisez le nombre de CPU virtuels à 1.

    • Les opérations de clonage ou de déplacement d'une machine virtuelle de ESXi 5.0 vers ESX/ESXi 4.1 échouent si la réplication est activée
      Si vous utilisez la commande hbr enablereplicationpour activer la réplication sur une machine virtuelle qui réside sur un hôte ESXi 5.0 et cloner la machine virtuelle vers un hôte ESX/ESXi 4.1 ou de version antérieure, la validation échoue, et le message d'erreur suivant apparaît : l'opération n'est pas prise en charge. Le clonage des machines virtuelles ESXi 5.0 sur des hôtes ESX/ESXi 4.1 n'est pas pris en charge.

      Solution :Sélectionnez l'une des solutions suivantes :

      • Clonez la machine virtuelle sur un hôte ESXi 5.0.
      • Clonez ou déplacez une nouvelle machine virtuelle sur un hôte ESX/ESXi 4.1.

  • L'incompatibilité entre vCenter Server 5.0 et les hôtes ESX/ESXi est à l'origine de l'échec des opérations de migration des machines virtuelles avec des disques delta
    Si vCenter Server 5.0 gère un hôte dont la version est antérieure à ESX/ESXi 4.0 Update 3, vous ne pouvez pas migrer des machines virtuelles avec des snapshots ou des disques delta vers l'hôte. Toute tentative d'une telle migration donne lieu au message d'erreur système suivant : Migration of VMs with snapshots or delta disks is not supported due to version incompatibility between vCenter Server and ESX. To continue this operation, please upgrade your ESX host(s) to ESX 4.0 Update 3 or later.
    La même restriction s'applique, et un message d'erreur semblable apparaît pour ESX/ESXi 4.1. ESX/ESXi 4.1 ne prend pas en charge la migration des machines virtuelles avec des disques delta si vCenter Server 5.0 gère l'hôte.

    Solution :Effectuez une mise à niveau de l'hôte ESX/ESXi vers ESX/ESXi 4.0 Update 3 ou une version ultérieure ou vers ESX 4.1 Update 1 ou une version ultérieure.

  • Impossible de définir les scripts VMware Tools sur mesure via l'IU de VMware-Toolbox dans le système d'exploitation client Linux quand le chemin d'accès aux scripts sur mesure contient des caractères non-ASCII
    Des caractères non-ASCII, comme des cases carrées avec un Xà l'intérieur, apparaissent dans la fenêtre Propriétés de VMware Tools dans les systèmes d'exploitation clients Linux quand l'option régionale du système est zh_CN.gb18030, ja_JP.eucjp,ou ko_KR.euckr. En pareils cas, vous ne pouvez pas définir des scripts VMware Tools sur mesure.

    Solution : Exécutez l'une des tâches suivantes :

    • Changez le nom du répertoire où figurent les scripts VMware Tools sur mesure de sorte qu'il contienne des caractères ASCII uniquement.
    • Définissez les scripts VMware Tools sur mesure en tapant la commande vmware-toolbox-cmd scriptà une invite du shell.

  • Les suffixes DNS non-ASCII ne sont pas correctement définis après la personnalisation de Windows XP et de Windows 2003
    Si vous entrez un suffixe DNS non-ASCII dans l'onglet DNS de Propriétés de réseau quand vous utilisez l'assistant de spécification de personnalisation pour personnaliser Windows XP ou Windows 2003, la personnalisation est signalée comme ayant réussi, mais le suffixe DNS non-ASCII n'est pas correctement défini.

    Solution :Définissez le suffixe DNS manuellement dans Windows XP et dans Windows 2003.

  • L'agent SNMP intégré à VMware signale un statut incorrect pour les processeurs dans l'objet hrDeviceStatusdu module HOST-RESOURCES-MIB.
    En présentant les informations du système, l'agent SNMP intégré à VMware affiche un statut incorrect pour les processeurs. L'agent SNMP présente un statut Unknownpour les processeurs de l'objet hrDeviceStatusdans HOST-RESOURCES-MIB. L'implémentation ESX/net-snmp de HOST-RESOURCES-MIB ne renvoie pas l'objet hrDeviceStatus, ce qui revient à signaler un statut unknown.

    Solution : Utilisez les données CIM APIs ou SMBIOS pour vérifier le statut des processeurs.

  • Le chemin du disque des snapshots dans le fichier de la base de données des snapshots .vmsd et le chemin parent dans le fichier descripteur de disque delta ne sont pas mis à jour après la migration.
    Lorsque snapshot.redoNotWithParentest défini sur TRUEet que vous modifiez la configuration de snapshotDirectory, par exemple, de Base de données A en Base de données B, le message Configuration snapshot non valide détectéepeut s'afficher. Ce problème survient lorsque les deux conditions suivantes sont présentes :

    • Vous rétablissez un ancien snapshot dans l'arborescence de snapshot et créez des snapshots depuis ce point de snapshot. Cela résulte en une hiérarchie d'arborescence de snapshot non linéaire.
    • Les liens de disque dans une chaîne de disques couvrent plusieurs banques de données et comprennent à la fois les banques de données source et de destination. Cette situation se produit si vous modifiez les paramètres snapshotDirectoryde sorte à ce qu'ils pointent vers différentes banques de données à plusieurs reprises et prennent des snapshots de la machine virtuelle entre les modifications de snapshotDirectory. Par exemple, vous prenez des snapshots d'une machine virtuelle avec snapshotDirectorydéfini sur Banque de données A, rétablissez un ancien snapshot, puis modifiez les paramètres snapshotDirectoryen Banque de données B et prenez des snapshots supplémentaires. Enfin, vous migrez le disque virtuel de Banque de données B vers Banque de données A.

    Il est recommandé de conserver la configuration par défaut, qui stocke les snapshots parents et enfants ensemble, dans le répertoire des snapshots. Évitez de modifier les paramètres snapshotDirectoryou de prendre des snapshots entre les modifications des banques de données. Si vous définissez snapshot.redoNotWithParentsur TRUE, réalisez une migration de stockage complète vers une banque de données qui n'est pas utilisée par la machine virtuelle.

     

    Solution : Réalisez une mise à jour manuelle des références du chemin d'accès au disque vers le bon chemin d'accès à la banque de données dans le fichier de la base de données des snapshots et le fichier de description du disque.

    • Migration
      • La migration à froid d'une machine virtuelle dotée d'un disque IDE virtuel d'un hôte ESXi 5.0 vers un hôte ESX/ESXi 4.x échoue, et l'erreur suivante s'affiche : l'opération n'est pas prise en charge sur l'objet.
        Quand vous utilisez vCenter Server 5.0 pour migrer à froid une machine virtuelle dotée d'un ou plusieurs disques IDE virtuels d'un hôte ESXi 5.0 vers un hôte sous ESX/ESXi 4.x, la migration échoue, et l'erreur suivante apparaît : l'opération n'est pas prise en charge sur l'objet.

        Solution : Procédez comme suit :

        1. Sur l'hôte ESXi 5.0, sélectionnez la machine virtuelle.
        2. Si la machine virtuelle réside dans une banque de données d'hôte uniquement sur l'hôte ESXi 5.0, déplacez les fichiers .vmxet .vmdkde la machine virtuelle vers un LUN partagé accessible à l'hôte ESXi 5.0 et à l'hôte ESX/ESXi 4.x.
        3. Migrez à froid la machine virtuelle vers l'hôte ESX/ESXi 4.x en utilisant l'option Changer l'hôte dans l'assistant de migration de machine virtuelle.
           
      • Pendant le passage à l'heure d'été, l'axe du temps sur les graphiques de performance n'est pas actualisé et ne reflète pas le changement d'heure.
        Par exemple, les horloges locales dans les régions qui respectent l'heure d'été ont été avancées d'une heure le dimanche 27 mars 2011 à 3 heures du matin. Les lignes guides sur l'axe du temps des graphiques de performances devraient être libellées ..., 2:00, 2:20, 2:40, 4:00, 4:20, ..., omettant les lignes à 3 heures du matin. Les libellés affichés en réalité sont ..., 2:00, 2:20, 2:40, 3:00, 3:20, 3:40, 4:00, 4:20, ....

        Solution : Aucune

      • Les disques de la machine virtuelle gardent leur format d'origine après l'opération Storage vMotion où l'utilisateur précise un changement de format de disque
        Quand vous tentez de convertir le format de disque en Provisionnement statique immédiatement mis à zéro pendant une opération Storage vMotion d'une machine virtuelle sous tension sur un hôte ESX/ESXi 4.1 ou d'une version antérieure, la conversion ne se fait pas. L'opération Storage vMotion réussit, mais les disques gardent leur format d'origine en raison d'une limite inhérente à ESX/ESXi 4.1 et aux versions antérieures. Si vous effectuez la même opération sur une machine virtuelle sur un hôte ESXi 5.0, la conversion se fait avec succès.

        Solution :Aucune.

      • L'utilitaire de vCenter Server ne peut pas trouver les données de consignation stockées à un endroit sur mesure
        L'utilitaire de vCenter Server ne peut pas localiser les fichiers journaux qui sont stockés en des lieux personnalisés, à savoir autres que par défaut. L'utilitaire de vCenter Server diffère de l'outil de collecte des données de consignation de vSphere Client.

        Solution : Connectez vSphere Client à vCenter Server et utilisez la fonction Exporter les journaux système pour extraire les données du journal. Dans vSphere Client, sélectionnez Administration > Exporter les journaux système.

        Quand vous ne pouvez pas connecter vSphere Client à vCenter Server, vous devez copier manuellement les fichiers dans l'utilitaire.

      VMware HA et Fault Tolerance
      • Dans vCenter Server 5.0, un certain nombre d'options de configuration avancée pour vSphere HA ne sont plus prises en charge.
        Les options suivantes ne sont plus prises en charge.

        das.consoleUser
        das.consoleNode
        das.consolePerm
        das.primaryCount
        das.checkVmStateDelay
        das.trace
        das.traceLevel
        das.traceOutput
        das.preferredPrimaries
        das.disableUWSwapRequirement
        das.sensorPollingFreq
        das.bypassNetCompatCheck
        das.defaultfailoverhost
        das.failureDetectionTime
        das.failureDetectionInterval

        Si vous tentez de définir une des options non prises en charge, vCenter Server 5.0 signale que l'option n'est pas valable. Si vous faites une mise à niveau vCenter Server 5.0 depuis une version précédente avec une quelconque de ces options définies, elles seront supprimées, et n'auront plus effet.

        Solution :Aucune.

      • Lorsque qu'un échec d'hôte s'est produit, vSphere HA ne parvient pas à redémarrer une machine virtuelle en cours de migration à l'aide de vMotion.
        Lorsqu'une machine virtuelle est en cours de migration d'un premier hôte vers un second, l'hôte d'origine peut échouer, ne plus répondre ou perdre l'accès à la banque de données contenant le fichier de configuration de la machine virtuelle. Si un tel échec se produit et qu'ensuite vMotion échoue également, il est possible que vSphere HA ne redémarre pas et ne protège pas la machine virtuelle.

        Solution : Si la machine virtuelle échoue et que vSphere HA ne la remet pas sous tension, remettez la machine virtuelle sous tension manuellement. vSphere HA protégera alors la machine virtuelle.

      Système d'exploitation client

      • Les périphériques USB 3.0 ne fonctionnent pas avec les machines virtuelles Windows 8 ou Windows Server 2012*
        Lorsque vous utilisez des périphériques USB 3.0 avec des machines virtuelles Windows 8 ou Windows Server 2012 avec un système d'exploitation Windows ou Linux comme le Client, des messages d'erreur similaires au suivant peuvent s'afficher :
        Port Reset Failed
        The USB set SEL request failed

        Solution : Aucune

      • Le démarrage PXE ou le redémarrage de RHEL 6 donne lieu à un écran vierge
        Quand vous tentez d'utiliser le programme d'amorçage Red Hat pour démarrer PXE dans RHEL 6 sur une machine EFI virtuelle, l'écran se vide après que vous sélectionnez le système d'exploitation. Ce problème survient aussi si vous supprimez la directive splashscreendu fichier grub.conf dans une installation régulière de RHEL 6 et que vous redémarrez la machine virtuelle.

        Solution : Vérifiez que la directive splashscreenest présente et qu'elle fait référence à un fichier accessible au programme d'amorçage.

      • Plusieurs vNIC se déconnectent au hasard au démarrage de Mac OS X 10.6.x
        Quand vous redémarrez Mac OS X 10.6, un état de lien client incorrect s'affiche pour n >=3 e1000 vNIC.

        Si n(e1000)=3, l'état du lien client est : 2(connecté), 1 (déconnecté).
        Si n(e1000)=5, l'état du lien client est : 3(connecté), 2(déconnecté), etc.

        Solution : Activez et désactivez manuellement les cartes avec l'utilitaire ifconfig. L'activation et la désactivation manuelles ne demeurent pas jusqu'au prochain processus de redémarrage.

      Matériel pris en charge
      • IBM x3550 M2 Force Legacy Video on Boot doit être désactivé
        IBM x3550 M2 bénéficie d'une option micrologicielle appelée Force Legacy Video on Boot qui active la prise en charge vidéo INT10h traditionnelle au démarrage depuis l'UEFI (Unified Extensible Firmware Interface ou « interface micrologicielle extensible unifiée »). Cette option n'est pas compatible avec ESXi 5.0, et elle doit être désactivée.

        Solution : Au moment de démarrer IBM x3550 M2 depuis l'UEFI, appuyez sur F1 pour saisir la configuration du micrologiciel, et sélectionnez Paramètres système > Prise en charge traditionnelle > Force Legacy Video on Boot et cliquez sur Désactiver.

      Internationalisation
      • Les utilisateurs dont les noms contiennent des caractères non-ASCII ne peuvent pas se connecter à vCenter Server via vSphere Web Client
        vSphere Web Client n'accepte pas les noms d'utilisateur contenant des caractères non-ASCII. Les utilisateurs dont les noms contiennent des caractères non-ASCII ne peuvent pas utiliser vSphere Web Client pour se connecter à vCenter Server.

        Solution :Utilisez vSphere Client pour vous connecter à vCenter Server.

      • Problèmes liés à la recherche localisée et au domaine de la recherche dans l'aide de vSphere Web Client
        Les problèmes suivants concernant la recherche localisée dans l'aide de vSphere Web Client ont été identifiés :

        • La recherche de langues différentes de l'anglais à l'aide de caractères localisés ne donne aucun résultat.
        • Si vous créez des noms de domaine de recherche avec des caractères non-ASCII, ceux-ci ne s'affichent pas correctement.

        Solution : Modifiez le fichier tomcat-server.xmlpour définir le codage URI au format UTF-8 :

        1. Ouvrez le fichier vSphere_Web_Client_Installation_Directory\springsource-dm-server-2.0.4\config\tomcat-server.xmldans un éditeur de texte.
        2. Modifiez la section suivante du fichier pour ajouter le paramètre URIEncoding="UTF-8"à la fin de la ligne connectionTimeout="20000":

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000"
          redirectPort="9443" emptySessionPath="true"/>


          9090 est la valeur par défaut pour le port du connecteur. Si vous avez changé cette valeur pendant l'installation, un autre numéro de port apparaît. Ne changez pas le numéro du port.

          Après la modification, la section doit prendre la forme suivante :

          <Connector port="9090" protocol="HTTP/1.1"
          connectionTimeout="20000" URIEncoding="UTF-8"
          redirectPort="9443" emptySessionPath="true"/>
        3. Modifiez la section suivante du fichier pour ajouter le paramètre URIEncoding="UTF-8"à la fin de la ligne keystoreFile="config/keystore" :

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore"
          keystorePass="changeit" emptySessionPath="true"/>


          9443 est la valeur par défaut pour le port du connecteur. Si vous avez changé cette valeur pendant l'installation, un autre numéro de port apparaît. Ne changez pas le numéro du port.

          Après la modification, la section doit prendre la forme suivante :

          <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true"
          maxThreads="500" scheme="https" secure="true"
          clientAuth="false" sslProtocol="TLS"
          keystoreFile="config/keystore" URIEncoding="UTF-8"
          keystorePass="changeit" emptySessionPath="true"/>
        4. Enregistrez le fichier.
    • L'information dans l'onglet Machines virtuelles ne se réactualise pas systématiquement
      Parfois, l'information dans l'onglet Machines virtuelles de vSphere Client ne se réactualise pas systématiquement tout de suite. Par exemple, si vous clonez ou enregistrez un grand nombre de machines virtuelles, certaines d'entre elles peuvent ne pas apparaître dans l'onglet Machines virtuelles, alors qu'elles figurent dans l'arborescence de l'inventaire. Si vous mettez sous tension ou hors tension un grand nombre de machines virtuelles, le nouvel état d'alimentation peut ne pas se refléter dans l'onglet Machines virtuelles, tandis qu'il apparaît correctement dans l'arborescence de l'inventaire.

      Solution : Appuyez sur F5 pour actualiser les informations dans l'onglet.

    • La console Web de VMware vCenter Server Appliance dispose d'options pour configurer IPv6, même si IPv6 n'est pas pris en charge
      Bien que VMware vCenter Server Appliance ne prenne pas en charge IPv6, l'onglet Réseau de la console Web de VMware vCenter Server Appliance dispose d'une option de configuration pour IPv6, et attribuera par défaut une adresse IPv6 au dispositif si un serveur DHCPv6 se trouve sur le réseau.

      Solution : Entrez une adresse IPv6 statique non valide pour VMware vCenter Server Appliance afin d'empêcher le dispositif d'obtenir une adresse IPv6 via DHCP.

    • vSphere Web Client ne se charge pas dans Internet Explorer 9 sous Windows Server 2008
      Quand vous tentez de charger vSphere Web Client dans Internet Explorer 9 sous Windows Server 2008, un fond bleu apparaît dans la fenêtre du navigateur Web, sans aucune activité.

      Solution : Sous Windows Server 2008, utilisez Internet Explorer 7 ou 8, ou Mozilla Firefox 3.6 ou une version ultérieure pour accéder à vSphere Web Client.

    • L'état de vSphere Web Client ne demeure pas entre sessions
      L'état de vSphere Web Client demeure normalement entre les sessions, de sorte que quand vous vous reconnectez à vSphere Web Client, les mêmes objets et onglets que ceux sélectionnés quand vous vous êtes déconnecté de la session précédente le sont encore. Toutefois, si les préférences de votre navigateur Web sont définies de façon que le navigateur ne se rappelle pas l'historique, ou si les paramètres de site Web de Flash Player n'allouent pas de stockage pour les sites consultés, Flash Player ne stocke pas les données de vSphere Web Client, et l'état ne demeure pas d'une session à l'autre.

      Solution : Procédez comme suit :

      1. Rendez-vous sur http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html, et assurez-vous que le volume de stockage est réglé à une valeur autre que Aucune.
      2. Si vous utilisez le navigateur Firefox, réglez les paramètres d'historique du navigateur :
        1. Sélectionnez Outils > Options.
        2. Cliquez sur Confidentialité.
        3. Sélectionnez une option autre que Ne jamais mémoriser l'historique.

    • vSphere Web Client produit, par intermittence, l'erreur #2406 : Le fichier chargé ne comporte pas de signature valide.
      Lors de l'utilisation de Mozilla Firefox 3.6.x sur SUSE Linux Enterprise Server 11 ou Red Hat Enterprise Linux 5, le message d'erreur suivant peut survenir par intermittence : Erreur #2406 : Le fichier chargé ne comporte pas de signature valide.

      Redémarrez le navigateur Web et reconnectez-vous à vSphere Web Client.

    • vCenter Server plante lors de l'exportation des journaux système.
      Lorsque vous exportez des journaux système depuis vCenter Server, vCenter Server utilise le dossier spécifié par la variable d'environnement TEMPde Windows. Par défaut, la variable est définie sur C:\Windows\Temp.

      Si vCenter Server est configuré pour stocker une grande quantité de données de journaux, ou si vous sélectionnez un grand nombre d'hôtes à partir desquels télécharger les journaux, le lecteur spécifié dans la variable TEMPpeut manquer d'espace disponible. Si ce lecteur est le même lecteur que celui sur lequel vCenter Server est installé, le service VMware VirtualCenter Server est susceptible de planter.

      Solution : Assurez-vous que le lecteur spécifié par la variable d'environnement TEMPde Windows dispose d'assez d'espace pour les journaux exportés. Envisagez de spécifier un autre lecteur que C:dans la variable TEMPpour éviter l'interruption des services du système.

    • La recherche d'informations dans vSphere Client ou vSphere Web Client présente des résultats dépassés ou expire.
      Lorsque vous consultez l'inventaire vSphere Client ou vSphere Web Client, la recherche peut présenter des informations dépassées ou, dans le cas de vSphere Web Client, expirer.

      Le message d'erreur suivant, indiquant une erreur d'exécution inattendue, apparaît dans le fichier journal du service d'inventaire, ds.log :
      [2011-06-27 18:04:25,367 pool-14-thread-5 ERROR
      com.vmware.vim.query.server.provider.impl.ProviderManagerServiceImpl] Exception d'exécution inattendue :
      com.xhive.error.XhiveInterruptedException : INTERROMPU

      Solution : Redémarrez Inventory Service.

      Pour un système vCenter Server exécuté sur Windows, effectuez les étapes suivantes :

      1. Démarrez Windows Service Manager :
        1. Sélectionnez Démarrer > Exécuter.
        2. Saisissez services.msc .
      2. Cliquez avec le bouton droit de la souris sur vCenter Inventory Service et sélectionnez Redémarrer.

      Pour vCenter Server Appliance, effectuez les étapes suivantes :
      1. Connectez-vous à la console Web de VMware vCenter Server Appliance.
      2. Dans l'onglet vCenter Server, sélectionnez Statut.
      3. Cliquez sur Arrêter vCenter.
      4. Cliquez sur Démarrer vCenter.

        • Divers
          •  
            • Surveillance inexacte des données du capteur dans l'état du matériel de vCenter Server (KB 2012998).

            • L'emplacement des fichiers journaux a changé de /var/logà /var/run/log
              Les fichiers journaux d'ESXi 5.0 sont situés dans /var/run/log. Pour des raisons de compatibilité descendante, le fichier journal contient des liens depuis l'emplacement précédent, /var/log, vers les fichiers journaux les plus récents dans le nouvel emplacement, /var/run/log. Le fichier journal ne contient pas de liens vers les fichiers journaux en rotation.

              Solution : Aucune.

            • Sur des machines virtuelles Linux, vous ne pouvez pas installer des OSP après avoir désinstallé VMware Tools avec le programme d'installation tar
              Après que vous avez désinstallé VMware Tools installé avec le programme d'installation tar sur une machine virtuelle Linux, les fichiers demeurent sur le système. Dans ce cas, vous ne pouvez pas installer d'OSP.

              Solution : Exécutez la commande suivante : rm -rf /usr/lib/vmware-tools /etc/vmware-tools
            • Quand le serveur proxy est activé dans les paramètres LAN d'Internet Explorer, PowerCLI ne parvient pas toujours à ajouter un dépôt en ligne
              Il est possible d'ajouter un dépôt en ligne dans PowerCLI au moyen de la cmdlet Add-ESXSoftwareDepot. Dans certaines conditions, lorsque le serveur proxy est activé pour la machine en cours d'utilisation, PowerCLI ne parvient pas à ajouter le dépôt en ligne dans sa session.
              Cet échec se produit uniquement si toutes les conditions suivantes sont réunies.
              • Le site du client exige un proxy HTTP pour l'accès au Web.
              • Le client héberge un dépôt sur son réseau interne.
              • Le proxy du client ne peut pas se connecter au dépôt sur le réseau interne.

              Solution :
              1. Désactivez le serveur proxy dans les paramètres LAN d'IE.
              2. Ajoutez le dépôt en ligne dans PowerCLI.