ESXi 5.0 Update 1 | 15 MARS 2012 | Version 623860

Dernière mise à jour : 29 MAR 2012

Vérifiez les compléments et les mises à jour pour ces notes de mise à jour.

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 de nouveaux processeursESXi 5.0 Update 1prend en charge les nouveaux processeurs AMD et Intel. Voir le Guide de compatibilité VMware pour plus d'informations.
  • Prise en charge de systèmes d'exploitation client supplémentaires ESXi 5.0 Update 1ajoute la prise en charge de Mac OS X Server Lion 10.7.2 et 10.7.3.
  • Pilotes de périphérique mis à niveau ou nouveauxESXi 5.0 Update 1ajoute la prise en charge des pilotes de stockage natifs pour le chipset Intel série C600 et met à niveau le pilote LSI MegaRAID SAS vers la version 5.34.

Problèmes résolus : cette version offre de plus, 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

La version antérieure d'ESXi 5.0 Update 1 est ESXi 5.0. Les fonctions et les problèmes identifiés d'ESXi 5.0 sont décrits dans les notes de mise à jour disponibles sur Notes de mise à jour de VMware vSphere 5.0.

Internationalisation

VMware vSphere 5,0 Update 1 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 1, vous pouvez configurer VMware vSphere Client™ pour fournir l'interface textuelle en anglais, même si la machine sur laquelle il fonctionne 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 ajoute la prise en charge des versions ESXi 5,0 Update 1 et vCenter Server 5,0 Update 1. 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 1, consultez les informations ESXi 5.0 Update 1 du Guide de compatibilité de VMware.

Mises à niveau et installations des CPU pris en charge. vSphere 5.0 Update 1 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 1. 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 1, consultez les informations sur ESXi 5.0 Update 1 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 1. 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 1, mettez le matériel virtuel à niveau. Reportez-vous à la documentation 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. Quand vous mettez un hôte 4.x à niveau avec des VIB personnalisés qui ne figurent dans l'ISO de la mise à niveau, vous pouvez procéder, 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 1 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. Reportez-vous à la documentation du fournisseur du routeur pour plus d'informations.
  • Respecter les meilleures pratiques pour l'accès à NFS routé par commutateur L3 recommandées par le 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 1 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

vSphere 5.0 Update 1 propose les outils suivants pour mettre les hôtes ESX/ESXi à niveau.

  • 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 1 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 1 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 1.
Chemins d'accès de mise à niveau pris en charge pour la mise à niveau vers ESXi 5.0 Update 1 :

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 1

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

ESXi 4.1 :
Inclut
ESXi 4.1 Update 1

ESXi 4.1 Update 2

ESXi 5.0

VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Oui*

update-from-esxi5.0-5.0_update01.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • Interface de ligne de commande VMware vSphere
  • Mise à niveau depuis un CD
  • Mise à niveau à base de script

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 depuis ESXi 5.0 en utilisant VMware-VMvisor-Installer-5.0.0.update01-623860.x86_64.ison'est pas prise en charge. À la place, vous devez effectuer la mise à niveau en utilisant update-from-esxi5.0-5.0_update01.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 1. 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 1. 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 1. 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 1 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 ESXi50-Update01 contient les bulletins individuels suivants :

ESXi500-201203201-UG : Met à jour le fichier vib esx-base d'ESXi 5.0
ESXi500-201203202-UG : Met à jour le fichier vib tools-light d'ESXi 5.0
ESXi500-201203203-UG : Met à jour le fichier vib ehci-ehci-hcd d'ESXi 5.0
ESXi500-201203204-UG : Met à jour le fichier vib scsi-megaraid-sas d'ESXi 5.0
ESXi500-201203205-UG : Met à jour le fichier vib misc-drivers d'ESXi 5.0
ESXi500-201203206-UG : Met à jour les fichiers vib sata d'ESXi 5.0
ESXi500-201203207-UG : Met à jour le fichier vib net-e1000e d'ESXi 5.0
ESXi500-201203208-UG : Met à jour le fichier vib scsi-rste d'ESXi 5.0
ESXi500-201203209-UG : Met à jour le fichier vib net-nx-nic d'ESXi 5.0
ESXi500-201203210-UG : Met à jour le pilote scsi-mpt2sas d'ESXi 5.0
ESXi500-201203211-UG : Met à jour le pilote scsi-aacraid d'ESXi 5.0


La version de correctifs ESXi50-Update01 Security-only contient les bulletins individuels suivants :

ESXi500-201203101-SG : Met à jour le fichier vib esx-base d'ESXi 5.0
ESXi500-201203102-SG : Met à jour le fichier vib tools-light d'ESXi 5.0
ESXi500-201203103-SG : Met à jour le fichier vib net-e1000e d'ESXi 5.0

La version de correctifs ESXi50-Update01 contient les profils d'image suivants :

ESXi-5.0.0-20120302001-standard
ESXi-5.0.0-20120302001-no-tools

La version de correctifs ESXi50-Update01 Security-only contient les profils d'image suivants :

ESXi-5.0.0-20120301001s-standard
ESXi-5.0.0-20120301001s-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 :

Les problèmes résolus précédemment documentés comme des problèmes connus sont signalés par le symbole †.

CIM et API

  • Le délai d'attente de la requête WinRM expire lorsque OpenManage 6.5 est installé sur un hôte ESXi 5.0
    Lorsque l'opération d'énumération Windows Remote Management (WinRM) est exécutée pour la classe CIM_SoftwareIdentitysur un hôte ESXi 5.0 installé avec Dell OpenManage Server Administrator (OMSA) 6.5, le délai d'attente de la requête peut expirer avec un message d'erreur similaire au suivant :

    Le client WinRM ne peut pas terminer l'opération dans le délai spécifié. Vérifiez si le nom de la machine est valide et qu'il soit accessible sur le réseau

    Des messages d'erreur similaires au suivant sont écrits dans var/log/syslog.log :

    2011-09-22T15:18:53Z sfcb-vmware_base[4927]: spGetMsg receiving from 50 4927-11 Resource temporarily unavailable
    2011-09-22T15:18:53Z sfcb-vmware_base[4927]: rcvMsg receiving from 50 4927-11 Resource temporarily unavailable
    2011-09-22T15:18:53Z sfcb-vmware_base[4927]: Timeout or other socket error


    La requête fonctionne lorsque le logiciel OMSA n'est pas installé.

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

  • L'API RefreshDatastore n'affiche aucune erreur lorsqu'elle est appelée sur une banque de données qui est hors ligne
    Lorsque vous déconnectez un câble de stockage d'ESXi4.0, accédez à la banque de données créée sur cette baie SAN FC à l'aide de MOB (Managed Object Browser) et appelez la méthode RefreshDatastoresur le MoRef (Managed Object Reference) de la banque de données qui n'existe plus,.l'API RefreshDatastoren'affiche aucune erreur.

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

  • Les indications CIM peuvent échouer lorsque plusieurs clients sont configurés
    Si vous vous abonnez aux indications CIM de l'hôte ESXi depuis plusieurs clients (C1 et C2 par exemple) et que vous supprimez l'abonnement depuis le premier client (C1), l'autre client (C2) peut ne pas recevoir les notifications d'indication envoyées par l'hôte.

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

  • Les indications CIM peuvent échouer en raison d'une fuite de mémoire
    Vous pouvez remarquer que la taille de la mémoire sfcb-ProviderMaaugmente. Le processus sfcb-ProviderMaéchoue lorsque la taille de la mémoire atteint la limite de 17 920 Mo. Les indications CIM sont arrêtées, et un message similaire au suivant, indiquant que la limite de taille de la mémoire a été atteinte, est écrit dans vmkernel.log:

    2011-12-04T10:49:41.852Z cpu4:3570)MemSched: vm 3570: UserReserveBStore:7987: Invalid memSize=17221 + memSizeResv=0 + nPages=1101 > memSizeLimit=17920

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

  • Le service WSMan signale l'erreur Service indisponible si un paramètre comporte des baies dans l'opération d'appel de WS-Management
    Le service WSMan sur un hôte ESXi ne prend pas en charge les paramètres d'entrée de baie à un élément pour effectuer une opération d'appel.

    Ce problème est résolu dans cette version. Les paramètres d'entrée de baie ne sont pas pris en charge.

  • Erreur CIM lorsqu'une instance d'énumération est effectuée depuis un client exécuté dans JRE 1.6U29
    Lorsque des instances d'énumération sont exécutées sur un hôte ESX depuis un client CIM exécuté dans JRE 1.6U29, le client CIM peut afficher l'erreur HTTP 500 Method not implementeden raison de l'incompatibilité entre le service sfcbdet JRE. Ce problème ne survient pas si le client CIM est exécuté dans JRE 1.6U27 ou une version précédente.

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

  • Les fournisseurs CIM tiers peuvent dépasser l'allocation SFCB par défaut de 256 descripteurs de fichier
    Des messages d'erreur similaires au suivant sont écrits dans vmkernel.log:

    socketcall: UserSocketUnix: AllocRecvMsg:3294: Unable to reserve fd.

    No free fds /sbin/sfcbd -d -l 7: (256 allocated)

    UserObj descriptors limit exceeded


    Ce problème a été observé avec le fournisseur de CIM Emulex.

    Ce problème est résolu dans cette version. Vous pouvez maintenant configurer le fichier /etc/sfcb/sfcb.cfgpour mettre à jour la valeur des descripteurs de fichier.

Système d'exploitation client

  • Les mouvements de la souris peuvent provoquer une journalisation excessive
    Les mouvements de la souris peuvent générer l'écriture répétée de messages SVGA similaires aux suivants dans vmware.log :

    May 02 12:01:28.464: mks| SVGA: Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
    May 02 12:01:30.468: mks| SVGA: Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip


    L'E/S générée par cette journalisation excessive peut générer une charge accrue sur les systèmes de stockage.

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

  • La personnalisation du clonage à chaud d'une machine virtuelle exécutant le système d'exploitation client Windows 2008 R2 échoue et le clonage redémarre en permanence
    La personnalisation du clonage à chaud d'un système d'exploitation client Windows 2008 R2 échoue avec le message d'erreur auto vérification introuvable, et la machine virtuelle redémarre en permanence.

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

  • QueryPerformanceCounter se comporte d'une manière incorrecte à l'intérieur d'une machine virtuelle lorsque /usepmtimer est utilisé avec certaines couches HAL Windows (KB 1011714).

  • Problèmes avec ESXi 5.0 avec des machines virtuelles de démarrage PXE avec le serveur de provisionnement Citrix (KB 2008436).

  • La machine virtuelle Windows 8 affiche un écran noir si le pilote WDDM est installé
    Si vous installez le pilote WDDM sur une machine virtuelle Windows 8 sur laquelle le 3D est désactivé, la console de la machine virtuelle peut afficher un écran noir.

    Dans cette version, le pilote WDDM n'est pas installé sur les machines virtuelles Windows 8 par défaut.

Gestion des licences

  • Un client tiers peut effectuer des opérations qui sont réservées pour les licences payées lorsqu'une licence vRAM d'hyperviseur est affectée à un hôte ESXi
    À partir de cette version, les clients tiers sont restreints depuis l'API VIM si l'hôte ESXi est affecté avec une licence vRAM d'hyperviseur.

  • Gestion de vSphere Essentials pour ROBO et vSphere Essentials Plus pour ROBO
    Dans cette version, vSphere Essentials pour ROBO et vSphere Essentials Plus pour ROBO peuvent toujours être gérés par les éditions suivantes de vCenter Server :
    • VMware vCenter Server Standard
    • VMware vCenter Server for Essentials
    • VMware vCenter Server Foundation
    Cependant, pour gérer ces éditions, vous devez effectuer une mise à niveau vers ESXi 5.0 Update 1 et utiliser les nouvelles clés ROBO.

  • L'édition vSphere Enterprise ne liste pas la fonction VAAI
    Dans vCenter Server, la fonction API vStorage pour l'intégration de baies (VAAI) n'apparaît pas sous Configuration > Fonctions sous licence dans l'édition vSphere Client pour vSphere Enterprise.

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

  • La clé de licence de VMware vSphere Hypervisor ne peut pas être affectée à un hôte ESXi avec une pRAM supérieure à 32 Go
    Dans les versions précédentes de vSphere, il était possible d'affecter la clé de licence Hypervisor aux hôtes ayant une taille de mémoire RAM de plus de 32 Go. À partir de la version ESXi 5.0 Update 1, vous pouvez affecter uniquement la clé de licence Hypervisor à un hôte ESXi avec une taille de mémoire pRAM inférieure ou égale à 32 Go.

Divers

  • L'hôte ESXi échoue au redémarrage si VMkernel.Boot.maxVMs est défini sur une valeur inférieure à 6
    Si vous limitez le nombre de machines virtuelles pouvant être mises sous tension en définissant VMkernel.Boot.maxVMs( Paramètres avancés > VMkernel > Démarrage) sur une valeur inférieure à 6, l'hôte ESXi peut échouer au redémarrage en affichant un écran violet. Un message d'erreur similaire au suivant s'affiche sur l'écran de diagnostic :

    NOT_IMPLEMENTED /vmkernel/main/lpage.c:3275


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

  • Impossible d'ajouter un périphérique USB à une machine virtuelle (KB 1039359).
  • Lorsqu'un hôte ESXi est connecté via Managed Object Browser (MOB), les valeurs de réservation de CPU et de mémoire s'affichent comme étant Non définies
    Lorsqu'un hôte ESXi 5.0 est connecté via Managed Object Browser (MOB), VirtualMachineConfigSummaryaffiche la valeur de réservation de CPU [ virtualMachineConfigSummary.cpuReservation] et la valeur de réservation de mémoire [ virtualMachineConfigSummary.memoryReservation] pour une machine virtuelle Non définies.

    Ce problème est résolu dans cette version.
  • La copie de grandes quantités de données sur un stockage USB peut entraîner la corruption des données
    Les données sont corrompues si vous copiez de grandes quantités de données (plus d'un Go) d'une machine virtuelle Windows 64 bits sur un périphérique de stockage USB.

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

  • La modification de snapshots en utilisant la commande vim-cmd échoue dans certaines structures d'arborescence de snapshot
    La modification de snapshots en utilisant la commande vim-cmd vmsvc/snapshot.removeou vim-cmd vmsvc/snapshot.revertéchoue lorsqu'elle est appliquée sur certaines structures d'arborescence de snapshot.

    Ce problème est résolu dans cette version. À présent, un identifiant unique, snapshotId, est créé pour chaque snapshot associé à une machine virtuelle. Vous pouvez obtenir snapshotIden exécutant la commande vim-cmd vmsvc/snapshot.get <vmid>. Vous pouvez utiliser la nouvelle syntaxe suivante lorsque vous travaillez avec les mêmes commandes :

    Revenir au snapshot : vim-cmd vmsvc/snapshot.revert <vmid> <snapshotId> [suppressPowerOff/suppressPowerOn]
    Supprimer un snapshot : vim-cmd vmsvc/snapshot.remove <vmid> <snapshotId>
  • Les caractères non-ASCII sur certains sites Web apparaissent altérés dans le navigateur Internet Explorer 9
    Sur une machine virtuelle Windows 7 3D exécutée sur un hôte ESXi 5.0, les caractères non-ASCII sur certains sites Web peuvent apparaître altérés dans le navigateur Internet Explorer 9. Ce problème peut survenir lorsque vous naviguez sur certains sites Web asiatiques.

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

  • Le thread d'agent ESXi hostd (vix-async-pipe) consomme beaucoup de CPU, entraînant une charge moyenne élevée

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

  • Le basculement de vCenter SRM échoue en raison d'une mauvaise configuration de machine virtuelle
    Si une machine virtuelle configurée dans le plan de récupération de VMware vCenter Site Recovery Manager (SRM) utilise un ou plusieurs fichiers de mappage de périphérique brut (RDM), et si le fichier de pointeur se trouve dans un autre dossier que le dossier de base, le processus de basculement de VMware vCenter SRM échoue. Les journaux SRM contiennent des entrées similaires à :

    [2011-05-05 09:26:35.756 22348 verbose 'RSVm-49592-Task'] Error set to (vim.fault.InvalidDeviceBacking)

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

  • Les disques volumineux effectuent une synchronisation complète de disque inutilement
    Lorsque les disques de plus de 256 Go sont protégés en utilisant VR (vSphere Replication), toute opération qui provoque un redémarrage interne du disque virtuel amène le disque à effectuer une synchronisation complète. Les redémarrages internes sont provoqués par plusieurs conditions :  
    • Une machine virtuelle est redémarrée
    • Une machine virtuelle fait l'objet de vMotion
    • Une machine virtuelle est reconfigurée
    • Un snapshot d'une machine virtuelle est pris
    •  
    • La réplication est interrompue momentanément et reprise
    Ce problème est résolu dans cette version.

  • Un hôte ESXi installé sur un serveur avec plus de 8 nœuds NUMA échoue et affiche un écran violet

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

  • Le service vmsyslogd échoue si le paramètre Syslog.global.LogDir est configuré d'une manière incorrecte
    Si vous configurez le paramètre Syslog.global.LogDird'une manière incorrecte, le service vmsyslogdéchoue sans afficher de message d'erreur, et les journaux ne sont pas écrits dans le répertoire /var/log.

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

  • Les journaux sont écrits sur le serveur syslog même si l'ensemble de règles du pare-feu syslog n'est pas activé sur l'hôte ESXi

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

  • Activation de la temporisation de session dans le mode Tech Support Mode (TSM) ESXi
    Après s'être connecté à un hôte ESXi sur la console, puis à Tech Support Mode (Mode) comme utilisateur root et après avoir initialisé une session d'accès à la console du serveur distant, un utilisateur qui ne dispose pas de privilèges peut obtenir un accès root à l'hôte ESXi, si la session d'accès à distance n'est pas arrivée à expiration ou reste inactive.

    À partir de cette version, vous pouvez configurer une temporisation de session pour quitter le mode de support technique (TSM) ESXi de la manière suivante :
    1. Connexion à Tech Support Mode (Mode) en tant qu'utilisateur racine.
    2. Éditez le fichier /etc/profileen ajoutant TMOUT=<timeout value in seconds>.
    3. Quittez Tech Support Mode (Mode).

Mise en réseau

  • Utilisation de l'offre groupée NIC Emulex BE2/BE2 (pilote be2net)
    Lors de l'utilisation de vSphere 5.0 avec les NIC Emulex BE2/BE3 (pilote be2net) dans un environnement HP FlexFabric/Flex-10 ou IBM Virtual Fabric Adapter (VFA), il se peut que la connectivité ne fonctionne pas correctement sur les machines virtuelles Windows ou sur le serveur lorsque des VLAN sont configurés.

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

  • Après la mise hors tension d'une machine virtuelle principale FT, la suppression de l'hôte de sa machine virtuelle secondaire d'un vDS échoue.
    Si vous mettez hors tension une machine virtuelle FT, les dvPorts fantômes utilisés par sa machine virtuelle secondaire demeurent dans vmkernel. Cela empêche la suppression depuis le vDS de l'hôte que la machine virtuelle secondaire exécutait.

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

  • Inclut le port TCP pour le DNS dans le pare-feu ESXi
    Vous ne pouvez pas ajouter un hôte ESXi au domaine Active Directory (AD). Lorsque vous tentez d'associer un hôte ESXi 5.0 à un environnement AD par l'intermédiaire de vSphere Client, la tâche échoue avec un message d'erreur similaire au suivant :

    Impossible de se joindre au domaine <domainname> : Le domain spécifié n'existe pas ou n'est pas accessible.

    Ce problème est résolu dans cette version. À présent, le port TCP sortant 53 sur le pare-feu de l'hôte ESXi est activé par défaut.
  • La connectivité réseau peut échouer si les VLAN et les PVLAN sont configurés sur le même vNetwork Distributed Switch
    Les machines virtuelles sur un vNetwork Distributed Switch (vDS) configuré avec des VLAN peuvent perdre la connectivité réseau au démarrage si vous configurez des VLAN privés sur le vDS. Toutefois, déconnecter, puis reconnecter la liaison montante résout le problème. Ce problème est survenu sur des NIC be2net et des vNIC ixgbe.

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

  • Écran de diagnostic violet avec vShield ou des produits de pare-feu intégrés vSphere tiers (KB 2004893)

  • Le serveur DHCP manque d'adresses IP
    Un problème au niveau du client DHCP peut entraîner l'envoi par le client DHCP de messages DHCPRELEASE en utilisant l'adresse MAC de diffusion du serveur. Toutefois, les messages de version peuvent être éliminés par un routeur de proxy DHCP intermédiaire. Le serveur DHCP finit par manquer d'adresses IP.

    Ce problème est résolu dans cette version. Les messages de version sont envoyés en utilisant des adresses de monodiffusion.

  • L'hôte ESXi génère des diffusions RARP excessives avec un trafic multidiffusion
    L'hôte ESXi génère des paquets RARP (Reverse Address Resolution Protocol) lorsque les machines virtuelles rejoignent ou quittent des groupes de multidiffusion.

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

  • L'hôte ESXi peut échouer avec un écran violet lorsqu'une machine virtuelle connectée à une vNIC VMXNET 2 est mise sous tension
    L'écran de diagnostic violet affiche un message d'erreur similaire au suivant :

    0x412261b07ef8:[0x41803b730cf4]Vmxnet2VMKDevTxCoalesceTimeout@vmkernel#nover+0x2b stack: 0x412261b0
    0x412261b07f48:[0x41803b76669f]Net_HaltCheck@vmkernel#nover+0xf6 stack: 0x412261b07f98


    Un message d'erreur similaire au suivant est écrit dans VMkernel.log:

    WARNING: Vmxnet2: 5720: failed to enable port 0x2000069 on vSwitch1: Limit exceeded^[[0m

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

  • L'hôte ESXi échoue en raison d'un problème avec le pilote de réseau nx_nic
    Un problème au niveau du pilote de réseau nx_nic peut entraîner l'échec de l'hôte ESXi avec un écran violet. Un message d'erreur similaire au suivant affiché sur l'écran de diagnostic peut indiquer qu'une temporisation de transmission (TX) s'est produite :

    0x4122096c7eb0:[0x41801545eee4]unm_tx_timeout_task@com.netxen.nx_nic#9.2.0.0+0x10b stack: 0x0

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

  • Certaines versions du pilote VMXNET 3 ne parviennent pas à initialiser le périphérique lorsque le nombre de vCPU n'est pas égal à deux (KB 2003484 ).

  • Hostd peut cesser de répondre lors des copies du fichier de réseau
    Dans de rares cas, hostd peut cesser de répondre lors d'une opération de copie du fichier de réseau. Ceci est généralement déclenché par des problèmes de mise en réseau dans l'environnement. Des messages de journal Hostd similaires au suivant sont écrits dans /var/log/vmware/hostdà bref intervalle (plusieurs fois par milliseconde), entraînant une utilisation élevée de CPU (80-100 %) :

    [2010-12-14 13:15:39.238 F5135B90 warning 'Libs'] [NFC ERROR] NfcFssrvrRecv: failed with code = 9
    [2010-12-14 13:15:39.238 F5135B90 info 'Libs'] NfcNetTcpRead: timed out waiting for data


    Ces messages sont consignés jusqu'à ce que vous redémarriez hostd.

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

  • L'ajout et la suppression d'une NIC physique peut entraîner l'échec d'un hôte ESXi avec un écran violet
    L'écran de diagnostic violet affiche un message d'erreur similaire au suivant :

    NDiscVlanCheck (data=0x2d16, timestamp=<value optimized out>) at bora/vmkernel/public/list.h:386

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

  • Cette version met à jour le pilote e1000e afin de la connexion de serveur à deux ports PB Intel PRO/1000 afin de prendre en charge la fonction d'adresses MAC secondaires.

  • Un hôte ESXi s'arrête et affiche un écran de diagnostic violet lorsque le contrôle d'E/S réseau est utilisé avec un adaptateur réseau qui ne prend pas en charge le déchargement de VLAN (KB 2011474).

  • La transmission des données via un port série virtuel depuis un système d'exploitation client peut s'arrêter soudainement
    Si un système d'exploitation client reçoit et transmet des données simultanément, la transmission des données peut s'arrêter dans certaines conditions de charge.

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

Sécurité

  • Les systèmes d'exploitation client Mac OS X ne traitent pas les disques virtuels comme des périphériques internes

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

  • Met à jour le module Python
    La bibliothèque tierce Python est mise à jour vers la version 2.6.7 sur ESXi pour résoudre plusieurs problèmes de sécurité.

    Le projet CVE (Common Vulnerabilities and Exposures) ( cve.mitre.org) a affecté les noms CVE-2009-3560, CVE-2009-3720, CVE-2010-1634, CVE-2010-2089 et CVE-2011-1521 à ces problèmes.

  • Met à jour la bibliothèque bzip2
    La bibliothèque bzip2 est mise à jour vers la version 1.0.6, ce qui résout un problème de sécurité.

    Le projet CVE (Common Vulnerabilities and Exposures) ( cve.mitre.org) a affecté le nom CVE-2010-0405 à ce problème.

Configuration des serveurs

  • L'application d'un profil d'hôte à un hôte en conformité provoque une non-conformité (KB 2003472).

  • Un hôte ESXi sur lequel le partage de page est désactivé échoue avec un écran violet
    Si vous effectuez une opération VMotion sur un hôte ESXi sur lequel le partage de page de l'option d'heure de démarrage est désactivé, l'hôte ESXi peut échouer avec un écran violet.

    Désactiver le partage de page a une incidence importante sur les performances de l'hôte ESXi. Étant donné que le partage de page ne doit jamais être désactivé, l'option de configuration du partage de page est supprimée depuis cette version.

  • L'onglet BIOS sur l'interface utilisateur graphique de Dell OpenManage Server Administrator (OMSA) n'affiche pas toutes les options
    Sur un serveur Dell exécuté en mode UEFI (Unified Extensible Firmware Interface), si vous démarrez un hôte ESXi installé avec OMSA, l'onglet BIOS sur OMSA n'affiche pas certaines options, telles que le verrouillage NIC et NUM.

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

Stockage

  • Un volume VMFS endommagé provoque l'épuisement de la mémoire du segment VMFS
    Si un hôte ESXi rencontre un volume VMFS endommagé, le pilot VMFS entraîne une fuite de mémoire du pilote VMFS et un épuisement du segment VMFS. Ceci arrête toutes les opérations VMFS, entraînant des machines virtuelles orphelines et des banques de données manquantes. Les opérations de vMotion peuvent ne pas fonctionner et les tentatives de démarrage de nouvelles machines virtuelles peuvent échouer avec des erreurs concernant des fichiers manquants et un épuisement de mémoire. Ce problème peut concerner tous les hôtes ESXi qui partagent le LUN endommagé et ont des machines virtuelles en exécution sur ce LUN.

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

  • Les banques de données qui résident sur les LUN d'un contrôleur qui est occupé seront affichées comme étant inactives dans vCenter Server bien que l'E/S soit restaurée
    Sur une paire de contrôleurs de stockage HA configurés pour être redondants, si vous occupez un contrôleur, les banques de données qui résident sur les LUN du contrôleur occupé peuvent s'afficher comme étant inactives et rester inactives jusqu'à ce qu'une nouvelle analyse manuelle soit effectuée.

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

  • Une charge d'E/S élevée sur des disques SCSI paravirtuels (PVSCSI) utilisés avec des systèmes d'exploitation clients Windows peut entraîner des erreurs d'E/S
    Dans certains scénarios, une charge d'E/S élevée sur des disques SCSI paravirtuels (PVSCSI) utilisés avec des systèmes d'exploitation clients Windows peut entraîner des erreurs d'E/S. L'erreur suivante peut apparaître dans le journal des événements Windows :

    Operating system returned error 1117 (The request could not be performed because of an I/O device error.)

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

  • Dans cette version, le pilote SAS MegaRAID est mis à niveau vers la version 5.34.

  • Le plug-in par défaut SATP est modifié pour les baies LSI prises en charge par ALUA dans ESXi 5.0 Update 1 (KB 2016753).
  • Cette version ajoute la prise en charge des pilotes de stockage natifs pour le chipset Intel série C600.

  • Aucun message d'erreur n'est consigné lorsque VMkernel arrête une machine virtuelle sur une banque de données ayant l'état PDL
    Lorsqu'un périphérique SCSI passe à l'état de perte de périphérique permanente (PDL), toutes les machines virtuelles qui utilisent les banques de données sauvegardées par ce périphérique SCSI sont affectées. Certaines solutions HA tierces ont une option VMX, où disk.terminateVMOnPDLDefaulta la valeur True. Avec cette option, le VMkernel arrêtera ces machines virtuelles affectées.

    À partir de cette version, lorsque VMkernel arrête les machines virtuelles affectées, un message d'avertissement similaire au suivant est consigné dans vmkernel.logune fois pour chaque machine virtuelle.

    WARNING: VSCSI: CompleteIOCommand:4033: handle 8193(vscsi0:1):opened by wid 4061 (vmm0:win2k3-sp1) has Permanent Device Loss. Killing world group with leader id <id>

  • L'hôte ESXi 5.0 ne détecte pas les disques durs SAS qui sont supérieurs à 2 To connectés à des HBA dirigés par le pilote mpt2sas
    Ceci est du au fait que le lecteur SAS renvoie des données d'analyse dans un format de descripteur qu'ESXi ne prend pas en charge.

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

  • Certaines commandes SCSI spécifiques au fournisseur, telles que 0xc1, émises sur des LUN RDM physiques peuvent ne pas fonctionner
    La récupération d'espace peut échouer sur les LUN cibles du fait d'un problème avec certaines commandes SCSI spécifiques au fournisseur, émises sur des LUN RDM physiques. Ce problème a été observé avec NetApp SnapDrive, utilisé pour la récupération d'espace sur NetApp Filers.

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

  • Un hôte ESXi échoue avec un écran de diagnostic violet lorsque plusieurs processus accèdent à la même ressource pendant l'initialisation du cache dentry

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

  • vSphere Storage APIs for Array Integration (VAAI) envoie les commandes XCOPY au périphérique source en violation de la spécification de VAAI
    Les commandes XCOPYque VAAI envoie au périphérique source peuvent échouer. Par défaut, les commandes XCOPYdoivent être envoyées au périphérique de stockage de destination conformément à la spécification de VAAI.

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

  • Utilisation de vmkfstools pour récupérer les blocs supprimés par VMFS sur des LUN à approvisionnement dynamique (KB 2014849).

  • L'hôte SXi peut ne pas répondre en raison d'un problème avec le pilote aacraid dans le traitement des requêtes d'abandon SCSI
    Des messages d'erreur similaires au suivant sont affichés sur la console :

    0:00:25:03.275 cpu0:4204)WARNING: SCSILinuxAbortCommands Failed, Driver AAC, for vmhba0
    0:00:25:03.407 cpu0:4204)<3>aacraid: Host adapter abort request (2,0,0,0) - cmd 0x41000a023fc0 (0x28)
    0:00:25:03.415 cpu0:4204)<3>aacraid: Host adapter abort request (2,0,0,0) - cmd 0x41000a023fc0 (0x28) - FAILED
    0:00:25:03.425 cpu0:4204)WARNING: SCSILinuxAbortCommands Failed, Driver AAC, for vmhba0
    0:00:25:03.461 cpu2:4203)<3>aacraid: Host adapter abort request (2,3,0,0) - cmd 0x41000a02bdc0 (0x0)
    0:00:25:03.469 cpu2:4203)<3>aacraid: Host adapter abort request (2,3,0,0) - cmd 0x41000a02bdc0 (0x0) - SUCCESS
    0:00:25:03.479 cpu2:4203)WARNING: SCSILinuxAbortCommand - The driver failed to call scsi_done from itsabort handler and yet it returned SUCCESS

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

Mise à niveau et installation

Gestion des VM

  • L'hôte ESXi cesse de répondre lorsque des requêtes SNMP sont envoyées en utilisant un fichier MIB
    Un hôte ESXi peut cesser de répondre si vous activez l'agent SNMP intégré sur l'hôte et si vous envoyez des requêtes SNMP en utilisant le fichier MIB VMWARE-VMINFO-MIB.mibsur des machines virtuelles qui sont migrées, clonées, créées ou supprimées.

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

  • Dans vCenter Server, une machine virtuelle Windows 2000 Professional clonée affiche Windows 2000 comme système d'exploitation client dans le fichier vmx au lieu de Windows 2000 Professional

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

  • Les limites de réseau de machines virtuelles ne fonctionnent pas correctement lorsque la limite est supérieure à 2048 Mbit/s
    Sur un hôte ESXi, si vous configurez le contrôle d'E/S de réseau (NetIOC) pour définir la Limite d'hôte pour le Trafic de machine virtuelle avec une valeur supérieure à 2048 Mbit/s, la limite de bande passante n'est pas appliquée.

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

  • Les performances des serveurs de terminaux Windows 2000 diminuent après une mise à niveau depuis ESXi 4.x
    Après la mise à niveau vers ESXi 5.0 depuis ESXi 4.x, les serveurs de terminaux Windows 2000 peuvent mal fonctionner. Les consoles de ces machines virtuelles peuvent cesser de répondre, et leur utilisation de CPU affiche constamment 100 %.

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

  • Une machine virtuelle peut devenir orpheline après une récupération après une défaillance de l'hôte ESXi 5.0
    Dans certaines situations, si un hôte ESXi 5.0 échoue après une opération de provisionnement sur une machine virtuelle, la machine virtuelle peut devenir orpheline après la récupération de l'hôte. Les tentatives de mise sous tension de la machine virtuelle échouent, avec un message d'erreur similaire au suivant :

    La tentative de mise sous tension de la VM <VM name> a échouée parce que la VM était introuvable sur l'hôte ESX attendu

    Ce problème ne se produit pas sur les hôtes ESXi 5.0 sans état.

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

  • Une machine virtuelle ne répond pas à certaines opérations d'arrêt
    Il peut arriver qu'il soit impossible d'arrêter une machine virtuelle en utilisant l'option d' arrêt du client de vSphere Client. La machine virtuelle affiche le message Vous pouvez maintenant éteindre votre ordinateur en toute sécurité, mais ne s'arrête pas complètement. Exécuter la commande vmware-cmd stop vm_vmx softdepuis la ligne de commande peut également ne pas arrêter la machine virtuelle. Toutefois, l'opération d'arrêt fonctionne dans le système d'exploitation client.

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

  • Le type de carte réseau e1000e devient flexible sur une machine virtuelle clonée à chaud
    Si vous clonez à chaud une machine virtuelle, le type de carte réseau e1000e sur la machine virtuelle clonée devient flexible si le système d'exploitation client sélectionné à l'origine est Autre > Autre (64 bits).

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

vMotion et Storage vMotion

  • Une opération de vMotion échoue avec des messages d'erreur indiquant que le CPU ou les ressources mémoire sont insuffisantes
    Une opération de vMotion peut échouer avec des messages d'erreur similaires au suivant :

    Impossible d'initialiser la migration sur la source. Erreur 0xbad00a4. Le démarrage de VMotion n'a pas réussi en raison de cpu ou mémoire insuffisant.

    La tâche de vMotion a échoué : cet hôte a déjà atteint sa limite de migration simultanée.


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

VMware Tools

  • vSphere Client affiche l'état de VMware Tools comme étant Périmé
    Après l'installation de VMware Tools sur une machine virtuelle avec un système d'exploitation Windows NT 4.0, vSphere Client affiche l'état de VMware Tools suivant : "VMware Tools: Périmé" au lieu de OK, même si VMware Tools est à jour.

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

  • Les règles udev pour la temporisation SCSI ne sont pas appliquées correctement après une mise à jour de VMware Tools
    Après une mise à jour des OSP de VMware Tools, les règles udev pour la temporisation SCSI peuvent ne pas être appliquées correctement sur certains systèmes d'exploitation client Linux. Par exemple, sur SLES10, le délai d'attente est de 60 secondes même si la règle udev devrait le définir sur 180 secondes. Vous pouvez vérifier si votre version du noyau est affectée, en exécutant la commande #cat /sys/block/sda/*/timeoutpour déterminer si le délai d'attente est défini sur 180 secondes.

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

  • La mise à niveau de VMware Tools échoue car certains dossiers dans /tmp sont supprimés sur certains systèmes d'exploitation Linux
    Lorsque vous mettez à niveau VMware Tools, la mise à niveau peut échouer car certaines distributions de Linux suppriment régulièrement les anciens fichiers et dossiers dans /tmp. La mise à niveau de VMware Tools requiert ce répertoire dans /tmppour les mises à niveau automatiques.

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

  • Le composant GuestInfo dans VMware Tools pour Windows peut subir des fuites de mémoire
    Le composant GuestInfodans VMware Tools pour Windows peut subir des fuites de mémoire s'il est impossible d'accéder au serveur DNS du système d'exploitation client. Cette fuite de mémoire augmente de manière excessive la mémoire de l'ensemble de travail du processus vmtoolsd.exe.

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

  • VMware Tools pour les hôtes provisionnés avec le déploiement automatique (KB 2004018).

  • L'installation de VMware Tools sur des systèmes d'exploitation client Ubuntu 11.04 et 11.10 génère un message d'avertissement
    Si VMware Tools est installé sur des systèmes d'exploitation client Ubuntu 11.04 et 11.10, un message d'avertissement similaire au suivant est affiché sur la console :

    Avertissement : installer ces packages sans verification [Oui/Non] ?

    L'installation se termine avec succès si vous appuyez sur Y.

    Ce problème est résolu dans cette version. Ce message d'avertissement ne s'affiche plus.

  • L'installation de VMware Tools dans une version Windows de 32 bits qui n'est pas en anglais (US) s'annule et échoue avec l'état d'erreur MSI 1603 (KB 2012665).

Problèmes connus

Les problèmes connus suivants ont été rencontrés lors de tests rigoureux. Nous espérons qu'ils vous aideront à comprendre certains désagréments que vous pourriez rencontrer dans cette version. Cette liste de problèmes concerne uniquement cette version d'ESXi 5.0 Update 1 et ESXi 5.0. Certains problèmes connus des éditions précédentes peuvent aussi s'appliquer à cette édition. Si vous rencontrez un problème non répertorié ici, vous pouvez étudier les problèmes connus des éditions précédentes, fouiller la Base de connaissances VMware ou encore nous contacter.

Liste des problèmes identifiés

Lisez la liste complète des problèmes identifiés pour trouver ce qui vous concerne. Les problèmes connus qui n'ont pas été documentés auparavant sont marqués du symbole *. Les problèmes sont classés comme suit.

Problèmes d'installation
  • Un message d'avertissement superflu lié à la mise en réseau s'affiche après l'installation d'ESXi 5.0 Update 1 *
    Après l'installation d'ESXi 5.0 Update 1, l'interface DCUI (Direct Console User Interface) d'ESXi affiche un message d'avertissement similaire au suivant :

    Avertissement : DHCP look up failed. You may be unable to access this system until you customize its network configuration


    Cependant, l'hôte acquiert l'IP DHCP et peut envoyer un ping aux autres hôtes.

    Solution : Ce message d'erreur n'est pas important et peut être ignoré. Le message d'erreur disparaît si vous appuyez sur Entrée sur le clavier.

  • Dans les installations basées sur un script, le programme d'installation ESXi n'applique pas l'option --fstypepour la commande partdans le fichier ks
    L'option --fstypepour la commande partest déconseillée dans ESXi 5.0. Le programme d'installation accepte l'option --fstypesans afficher de message d'erreur, mais le programme d'installation ne crée pas le type de partition spécifié par l'option --fstype. Par défaut, le programme d'installation crée toujours des partitions VMFS5 dans ESXi 5.0. Vous ne pouvez pas spécifier un type de partition différent avec l'option --fstypepour la commande part.

  • Information manquantes sur les règles pendant l'exécution de la cmdlet d'Image Builder pour afficher le profil d'image modifié dans PowerShell 1.0
    Vous installez vSphere PowerCLI sur Microsoft PowerShell 1.0. Ensuite, vous ajoutez un package logiciel OEM à un profil d'image. Lorsque vous listez le profil d'image, l'information à propos des propriétés de Règles est manquante.

    Solution : Accédez à l'information des règles en affichant les propriétés des Règles de l'objet du profil d'image.

  • L'installation ou la mise à niveau scriptée d'ESXi à partir d'un CD ou d'un DVD échoue, sauf si la commande de ligne du démarrage utilise des majuscules pour le nom du fichier script
    Quand vous procédez à une installation ou une mise à niveau scriptée depuis une image ISO du programme d'installation d'ESXi 5.0 gravée sur un CD ou un DVD avec le script d'installation ou de mise à niveau (fichier kickstart), le programme d'installation reconnaît le nom de fichier kickstart uniquement s'il figure en majuscules. Par exemple, si le fichier kickstart s'appelle ks.cfg, et que vous utilisez la commande de ligne du démarrage ks=cdrom:/ks.cfgpour indiquer l'emplacement du fichier kickstart, l'installation échouera, et un message d'erreur semblable à ce qui suit apparaîtra : HandledError: Erreur (voir le journal pour plus d'info): impossible de trouver le fichier kickstart sur cd-rom with path -- /ks.cfg.

    Solution : Tapez le nom de fichier kickstart en majuscules dans la commande de ligne du démarrage, par ex. : ks=cdrom:/KS.CFG

  • Message d'erreur fallacieux quand vous tentez d'installer des VIB, et que vous utilisez un chemin relatif
    Quand vous tentez d'installer un dépôt, un VIB ou un profil au moyen de la commande esxcli software vib, et que vous indiquez un chemin relatif, l'opération échoue, et l'erreur suivante apparaît : No such file or directory: '/var/log/vmware/a.vib'

    Solution : Précisez le chemin absolu quand vous effectuez l'installation.

  • Impossible d'installer vSphere Client dans un dossier dont le nom contient des caractères spéciaux
    Quand vous installez vSphere Client dans un dossier ou un répertoire dont le nom contient un caractère spécial (point-virgule (;), crochet gauche ([), crochet droit (]), signe égal (=), signe plus (+), virgule (,) ou dièse (#)), le message d'erreur suivant apparaît :

    le chemin d'installation contient un caractère ';'. Veuillez sélectionner un répertoire d'installation avec ce caractère.

    Même si le nom du dossier ne contient pas de point-virgule (;), vous ne pourrez pas installer vSphere Client dans le dossier indiqué. Si vous installez vSphere Client dans un dossier personnalisé dont le nom contient un dièse ( #), le client ne pourra pas se connecter à vCenter Server.

    Solution : Prenez soin de ne pas installer vSphere Client dans un dossier personnalisé dont le nom contient un caractère spécial, à savoir le point-virgule (;), le crochet gauche ([), le crochet droit (]), le signe égal (=), le signe plus (+), la virgule (,) ou le dièse (#) ..

  • Après l'installation de vSphere Web Client, quand l'utilisateur clique sur Terminer dans l'assistant d'installation, un navigateur s'ouvre, et une page vierge apparaît
    Après que vous avez installé vSphere Client, un navigateur s'ouvre, et une page vierge apparaît quand vous cliquez sur Terminer dans l'assistant d'installation. La page demeure vierge, et le navigateur n'établit pas la connexion avec l'application d'administration vSphere.

    Solution : Fermez le navigateur, et lancez l'Application d'administration vSphere depuis le menu Démarrer.

Problèmes de mise à niveau
  • Il est impossible d'appliquer les VIB d'ESXi 5.0 Update 1 par l'intermédiaire de PowerCLI sur un hôte ESXi connecté par l'intermédiaire de vCenter Server *
    Sur un hôte ESXi 5.0 géré par vCenter Server, les tentatives d'application des VIB d'ESXi 5.0 Update 1 en utilisant les commandes GET-ESXCLI sur PowerCLI échouent avec des messages d'erreur similaires aux suivants :
    2011-11-18T09:53:50Z esxupdate: root: ERROR: Traceback (most recent call last):
    2011-11-18T09:53:50Z esxupdate: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 441, in <module>
    2011-11-18T09:53:50Z esxupdate: root: ERROR: main()
    2011-11-18T09:53:50Z esxupdate: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 432, in main
    2011-11-18T09:53:50Z esxupdate: root: ERROR: ret = CMDTABLE[command](options)
    2011-11-18T09:53:50Z esxupdate: root: ERROR: File "/usr/lib/vmware/esxcli-software", line 329, in VibInstallCmd
    2011-11-18T09:53:50Z esxupdate: root: ERROR: raise Exception("No VIBs specified with -n/--vibname or -v/--viburl.")
    2011-11-18T09:53:50Z esxupdate: root: ERROR: Exception: No VIBs specified with -n/--vibname or -v/--viburl.


    Solution : Aucune
  • Échec d'une mise à jour en direct avec ESXCLI, et affichage du message VibDownloadError
    Lorsque vous accomplissez les tâches suivantes, dans l'ordre, l'opération de redémarrage obligatoire échoue, et le message VibDownloadErrorapparaît.

    1. Mise à jour d'installation en direct avec la commande esxcli software profile updateou esxcli vib update.
    2. Avant le redémarrage, vous effectuez une opération qui nécessite un redémarrage, et l'opération n'aboutit pas. La vérification de la signature, qui peut se vérifier uniquement après que le VIB a été téléchargé, constitue un échec possible courant.
    3. Sans redémarrer l'hôte, vous tentez d'effectuer une autre opération qui nécessite un redémarrage. L'opération n'aboutit pas, et le message VibDownloadErrorapparaît.

Solution : La résolution du problème s'effectue en deux étapes.

  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 : Quand 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.

  • Problèmes d'octroi 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 dans un conteneur sont de la même version que la licence que vous associez audit 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.

    Problèmes de 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 Fermer la session dans l'interface Web de la banque de données pour terminer la session avant de fermer la fenêtre du navigateur.

    Problèmes de mise en réseau
    • Un profil d'hôte avec la 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 *
      Lorsque vSphere Auto Deploy est utilisé 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 l'option Fault Tolerance, et redémarrez la machine virtuelle avant d'activer DirectPath I/O with 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.

    Problèmes de 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 des 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 : Retirez 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 : Quand vous testez l'équilibrage de charge 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 apparaît : 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 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 changer le mode du disque en Indépendant persistent.

    • 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 apparaît : Une erreur interne s'est produite : impossible de sérialiser la réponse.

      Solution : Commencez par configurer FCoE 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 : Désenregistrez manuellement un fournisseur à la fois.

    • 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 rendre les banques de données visibles, cliquez sur Actualiser dans l'écran Configuration > Stockage de vSphere Client.

    Problèmes de configuration de serveur
    • 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 : Procédez au choix comme suit :

      • 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 : Actualisez le fichier de réponses pour le profil avant d'effectuer la vérification de la 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 : Réalisez une des opérations 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.

    • Problèmes vCenter Server et vSphere Client
      • Erreur de base de données lors de l'enregistrement d'AutoDeploy sur vCenter Virtual Appliance (VCVA) (article 2014087 dans la base de connaissances).*
      • 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://localhostdans les 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 : Quand vous exécutez la commande snmpwalk, utilisez l'option -tpour indiquer le délai d'inactivité et l'option -rpour fixer le nombre de 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 l'hôte local 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 : Procédez au choix comme suit :

        • 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 de 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 d'exporter, faites défiler la liste pour vérifier que toutes les machines virtuelles sont affichées.

      • 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 quand vous tentez de visualiser les profils de stockage des machines virtuelles
        Quand 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 : Il n'est pas possible de connecter VC 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.

        Problèmes de 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 ou Windows 7 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 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 le résultat, 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 : Procédez au choix comme suit :

          • 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 options 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 : Faites une mise à niveau de l'hôte ESX/ESXi vers ESX/ESXi 4.0 Update 3 ou plus ou vers ESX 4.1 Update 1 ou plus.

      • 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 de disque vers le bon chemin de la banque de données dans le fichier de la base de données des snapshots et le fichier descripteur de 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 seulement sur l'hôte ESXi 5.0, déplacez la machine virtuelle .vmxet les fichiers .vmdkvers 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 de consignation. 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 si vSphere HA ne la remet pas sous tension, remettez la machine virtuelle sous tension manuellement. vSphere HA protègera alors la machine virtuelle.

          • 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.xml pour préciser le chiffrement 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.
        • Problèmes de migration Problèmes VMware HA et Fault Tolerance Problèmes de système d'exploitation client
          Problèmes de matériel supporté Problèmes d'internationalisation
        • 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 rafraîchir l'information 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 plus, 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 Aucun.
          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 le service d'inventaire.

          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.

          Problèmes divers
          • Surveillance inexacte des données du capteur dans État du matériel 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 renouvelés.

            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 où le serveur proxy est activé au regard de la machine utilisée, 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 : Désactivez le serveur proxy dans les paramètres LAN d'IE. Ajoutez le dépôt en ligne dans PowerCLI.