ESXi 5.0 Update 3 | 17 octobre 2013 | Build 1311175

Dernière mise à jour : 31 oct 2013

Contenu des notes de mise à jour

Ces notes de mise à jour contiennent les rubriques suivantes :

Nouveautés

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

  • Problèmes résolus :cette version inclut un certain nombre de correctifs de bogues documentés dans la section Problèmes résolus.

Versions antérieures d'ESXi 5.0

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

Internationalisation

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

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

vpxClient -locale en_US

Compatibilité et installation

Compatibilité de version ESXi, vCenter Server et vSphere Client

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

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

Compatibilité ESXi, vCenter Server et VDDK

Virtual Disk Development Kit (VDDK) 5.0.3 ajoute la prise en charge des versions ESXi 5.0 Update 3 et vCenter Server 5.0 Update 3. 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 3, consultez les informations ESXi 5.0 Update 3 du Guide de compatibilité de VMware.

Mises à niveau et installations des CPU pris en charge. vSphere 5.0 Update 3 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 3. 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 3, consultez les informations sur ESXi 5.0 Update 3 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 3. 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 3, mettez le matériel virtuel à niveau. Reportez-vous à la documentation de Mise à niveau vSphere.

Notice d'installation pour cette version

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

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

 

Migration de solutions tierces

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

Accès au stockage NFS routé par commutateur L3

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

Mises à niveau pour cette version

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

Mise à niveau de VMware Tools

VMware ESXi 5,0 Update 3 contient la version la plus récente de VMware Tools. VMware Tools est une suite d'utilitaires qui améliorent les performances du système d'exploitation client de la machine virtuelle. Reportez-vous aux Problèmes résolus de VMware Tools pour une liste des problèmes résolus dans cette version d'ESX relative à VMware Tools.

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

Mises à niveau ESX/ESXi

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

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

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 3

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

ESX4.0 Update 3
ESX 4.0 Update 4

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

ESXi 4.0 Update 3
ESXi 4.0 Update 4

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

ESX 4.1 Update 3

 

ESXi 4.1 :
Inclut
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0 :
Inclut
ESXi 5.0 Update 1
ESXi 5.0 Update 2

VMware-VMvisor-Installer-5.0.0.update03-1311175.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Yes*

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

Non

Non

Non

Non

Oui

Utilisation de définitions de correctif téléchargées depuis le portail VMware (en ligne)

VMware vCenter Update Manager avec ligne de base de correctifs

Non

Non

Non

Non

Oui

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

Les produits livrables de vSphere 5.0 Update 3 ne peuvent pas garantir la compatibilité des chemins d'accès de mise à niveau vers vSphere 5.1.

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 3. 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 3. 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 3. 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 3 sont accessibles sur http://www.vmware.com/download/vsphere/open_source.html, sous l'onglet Open Source. Vous pouvez également télécharger les fichiers source pour une licence GPL, LGPL ou d'autres licences semblables pour lesquelles le code source ou les modifications du code source doivent être disponibles pour la dernière version généralement disponible de vSphere.

Correctifs contenus dans cette version

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

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

ESXi500-201310201-UG : Met à jour le fichier vib esx-base d'ESXi 5.0
ESXi500-201310202-UG : Met à jour le fichier vib tools-light d'ESXi 5.0
ESXi500-201310203-UG : Met à jour le fichier vib misc-drivers d'ESXi 5.0
ESXi500-201310204-UG : Met à jour le fichier scsi-hpsa vib d'ESXi 5.0

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

ESXi500-201310101-SG : Met à jour le fichier vib esx-base d'ESXi 5.0

ESXi500-201310102-SG : Met à jour le fichier net-bnx2x vib d'ESXi 5.0
ESXi500-201310103-SG : Met à jour le fichier misc-drivers vib d'ESXi 5.0

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

ESXi-5.0.0-20131002001-standard

ESXi-5.0.0-20131002001-no-tools

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

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

CIM et API

  • Le démon Small-Footprint CIM Broker peut cesser de répondre lorsque le fournisseur CIM échoue
    Sur un hôte ESXi, le démon Small-Footprint CIM Broker (sfcbd) peut cesser de répondre fréquemment lorsque le fournisseur CIM échoue pendant le délai d'inactivité.

    Ce problème est résolu dans cette version.
  • Le fournisseur CIM LSI transmet des descripteurs de fichiers
    Le fournisseur CIM LSI (l'un des processus sfcb) transmet des descripteurs de fichiers. Cela peut entraîner l'arrêt de sfcb-hhrcet le redémarrage de sfcbd. Le fichier syslogpeut consigner des messages semblables aux messages suivants :

    sfcb-LSIESG_SMIS13_HHR[ ]: Error opening socket pair for getProviderContext: Too many open files
    sfcb-LSIESG_SMIS13_HHR[ ]: Failed to set recv timeout (30) for socket -1. Errno = 9
    ...
    ...

    sfcb-hhrc[ ]: Timeout or other socket error
    sfcb-hhrc[ ]: TIMEOUT DOING SHARED SOCKET RECV RESULT ( )


    Ce problème est résolu dans cette version.
  • L'action WS-Management GetInstance () sur « http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000 » peut émettre une erreur wsa:DestinationUnreachable sur certains serveurs ESXi
    L'action WS-Management GetInstance () sur « http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000 » peut émettre une erreur wsa:DestinationUnreachablesur certains serveurs ESXi. Le chemin d'accès aux objets OMC_MCFirmwareIdentity n'est pas cohérent pour les opérations CIM gi/ei/ein sur le système doté du capteur du contrôleur BMC (Baseboard Management Controller) de l'interface intelligente de gestion de plate-forme (IPMI). Par conséquent, l'action WS-Management GetInstance () émet une erreur wsa:DestinationUnreachablesur le serveur ESXi.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi est déconnecté de vCenter Server en raison de l'épuisement d'inodes par sfcbd
    Les hôtes ESXi se déconnectent de vCenter Server et ne peuvent s'y reconnecter. Ce problème est causé par le service de contrôle de matériel (sfcdb) qui remplit le répertoire /var/run/sfcbavec plus de 5 000 fichiers.

    Le fichier hostd.logse trouvant dans /var/log/indique que l'hôte est à court d'espace :
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device
    VmkCtl Locking (/etc/vmware/esx.conf) : Unable to create or open a LOCK file. Failed with reason: No space left on device


    Le fichier vmkernel.logse trouvant dans /var/logindique qu'il est à court d'inodes :
    cpu4:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.
    cpu5:1969403)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process python because the visorfs inode table is full.
    cpu11:1968837)WARNING: VisorFSObj: 893: Cannot create file /etc/vmware/esx.conf.LOCK for process hostd because the visorfs inode table is full.

    Ce problème est résolu dans cette version.
  • Le service de contrôle du matériel s'arrête et l'onglet État du matériel affiche uniquement un message d'erreur
    L'onglet État du matériel n'affiche pas d'états d'intégrité et affiche un message d'erreur semblable au message suivant :

    Le service de contrôle de matériel sur cet hôte ne répond pas ou n'est pas disponible.

    Le service de contrôle du matériel (sfcdb) s'arrête et le fichier syslogpeut inclure des entrées semblables aux entrées suivantes :

    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 6750210)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 6 payLoadSize 19 chunkSize 0 from 12 resp 6750210
    sfcb-smx[xxxxxx]: spRecvReq returned error -1. Skipping message.
    sfcb-smx[xxxxxx]: spRcvMsg Receive message from 12 (return socket: 4)
    sfcb-smx[xxxxxx]: --- spRcvMsg drop bogus request chunking 220 payLoadSize 116 chunkSize 104 from 12 resp 4
    ...
    ...
    sfcb-vmware_int[xxxxxx]: spGetMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: rcvMsg receiving from 40 419746-11 Resource temporarily unavailable
    sfcb-vmware_int[xxxxxx]: Timeout or other socket error


    Ce problème est résolu dans cette version.
  • Le serveur CIM renvoie une valeur PerceivedSeverity incorrecte pour indication
    Lorsque IBM Systems Director (ISD) est utilisé pour contrôler le serveur ESX, le serveur CIM renvoie une valeur PerceivedSeverity incorrecte pour indication à ISD. La correction du type de capteur et de la valeur de retour PerceivedSeverity résout ce problème.

    Ce problème est résolu dans cette version.
  • Impossible de contrôler l'état du matériel de l'hôte ESXi
    Lorsque le service SFCBD est activé dans le mode de suivi et que le service cesse de fonctionner, l'onglet État du matériel d'un hôte ESXi peut signaler une erreur. Il est possible qu'aucun outil tiers ne parvienne à contrôler l'état matériel de l'hôte ESXi.

    Ce problème est résolu dans cette version.
  • Des messages d'erreur incorrects peuvent être affichés par des fournisseurs CIM
    Des messages d'erreur incorrects semblables aux messages suivants peuvent être affichés par des fournisseurs CIM : :
    \"Request Header Id (886262) != Response Header reqId (0) in request to provider 429 in process 5. Drop response.\"
    Ce problème est résolu dans cette version en mettant à jour le journal d'erreurs et en redémarrant l'agent de gestion sfcbd pour afficher des messages d'erreur corrects semblables aux messages suivants :
    Header Id (373) Request to provider 1 in process 0 failed. Error:Timeout (or other socket error) waiting for response from provider.

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

Divers

  • Netlogond peut cesser de répondre et l'hôte ESXi peut perdre la fonction Active Directory
    Il est possible que Netlogond consomme beaucoup de mémoire supérieure dans un environnement Active Directory en présence de plusieurs contrôleurs de domaine injoignables. Par conséquent, Netlogond peut échouer et l'hôte ESXi peut perdre la fonction Active Directory.

    Ce problème est résolu dans cette version.
  • Il est possible que vous ne puissiez pas activer un cluster High Availability (HA) après qu'un hôte du même cluster HA a été placé en mode de maintenance
  • Ce problème se produit lorsque la valeur du numéro de descripteur d'inode n'est pas correctement définie dans le système de fichiers root d'ESX (VisorFS) et par conséquent les appels de statistiques sur ces inodes échouent.
    Ce problème est résolu dans cette version.
  • L'hôte ESXi affiche des valeurs incorrectes pour le compteur système resourceCpuAllocMax
    Lorsque vous récupérez la valeur des compteurs système resourceCpuAllocMaxet resourceMemAllocMaxà partir des options Performance >> Diagrammes de performances avancés >> Diagramme système, l'hôte ESX renvoie des valeurs incorrectes. Ce problème se produit sur un client vSphere Client connecté à un système vCenter Server.

    Ce problème est résolu dans cette version.
  • Des tentatives de configuration d'une règle de filtre qui contient la lettre de lecteur d'un volume hébergeant un système de fichiers non pris en charge peut entraîner la défaillance d'une machine virtuelle Windows Server 2003 ou Windows XP avec un écran bleu
    Lorsque vous tentez de définir une règle de filtre contenant la lettre de lecteur d'un volume hébergeant un système de fichiers non pris en charge, la machine virtuelle Windows Server 2003 ou Windows XP peut échouer et afficher un écran bleu, et éventuellement des messages d'erreur semblables aux messages suivants :
    Error code 1000007e, parameter1 c0000005, parameter2 baee5d3b, parameter3 baa69a64, parameter4 baa69760.
    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.Data:
    0000: 53 79 73 74 65 6d 20 45 System E
    0008: 72 72 6f 72 20 20 45 72 rror Er
    0010: 72 6f 72 20 63 6f 64 65 ror code
    0018: 20 31 30 30 30 30 30 37 10000070020: 65 20 20 50 61 72 61 6d e Param
    0028: 65 74 65 72 73 20 63 30 eters c0
    0030: 30 30 30 30 30 35 2c 20 000005,
    0038: 62 61 65 65 35 64 33 62 baee5d3b
    0040: 2c 20 62 61 61 36 39 61 , baa69a
    0048: 36 34 2c 20 62 61 61 36 64, baa6
    0050: 39 37 36 30 9760

    Ce problème se produit principalement lorsque la lettre de lecteur Q:\créée par la solution Microsoft App-V est ajoutée dans la règle de filtre.

    Ce problème est résolu dans cette version.
  • Des messages d'erreur du contrôleur de mémoire peuvent être signalés de manière incorrecte comme des erreurs TLB lorsque des hôtes ESXi échouent avec un écran violet
    Lorsque des hôtes ESXi échouent avec un écran violet, les messages d'erreur du contrôleur de mémoire peuvent être signalés de manière incorrecte comme des messages d'erreur TLB (Translation Look-aside Buffer), Level 2 TLB Error.

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

Mise en réseau

  • Un hôte ESXi n'arrive pas à signaler les problèmes de configuration si la partition de vidage mémoire et les services Dump Collector ne sont pas configurés
    Si un hôte ESX n'est pas configuré avec une partition de vidage mémoire et n'est pas configuré pour diriger les vidages mémoire dans un service Dump Collector, nous risquons de perdre d'importantes informations de dépannage. L'inclusion d'un contrôle de configuration et de partition de vidage mémoire au démarrage du service hostd résout ce problème.

    Ce problème est résolu dans cette version.
  • Les hôtes ESXi qui redémarrent dans un mode sans état figurent avec le nom localhost dans le fichier syslog
    Lorsqu'un hôte ESXi sans état redémarre et qu'il est configuré pour obtenir une configuration et un nom d'hôte DNS d'un serveur DHCP, le fichier syslog indique le nom d'hôte localhost à la place du nom d'hôte obtenu du serveur DHCP. Par conséquent, pour un collecteur syslog distant, tous les hôtes ESXi semblent avoir le même nom d'hôte.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi peut échouer avec un écran violet et envoyer une erreur d'exception de fichier d'échange
    Lorsque des machines virtuelles sont configurées avec des adaptateurs réseau e1000, les hôtes ESXi peuvent échouer avec un écran de diagnostic violet et afficher des messages semblables aux messages suivants :

    @BlueScreen: #PF Exception 14 in world 8229:idle37 IP 0x418038769f23 addr 0xc
    0x418038600000 VMK uptime: 1:13:10:39.757
    0x412240947898:[0x418038769f23]E1000FinalizeZeroCopyPktForTx@vmkernel#nover+0x1d6 stack: 0x41220000
    0x412240947ad8:[0x41803877001e]E1000PollTxRing@vmkernel#nover+0xeb9 stack: 0x41000c958000
    0x412240947b48:[0x418038771136]E1000DevAsyncTx@vmkernel#nover+0xa9 stack: 0x412240947bf8
    0x412240947b98:[0x41803872b5f3]NetWorldletPerVMCB@vmkernel#nover+0x8e stack: 0x412240947cc0
    0x412240947c48:[0x4180386ed4f1]WorldletProcessQueue@vmkernel#nover+0x398 stack: 0x0
    0x412240947c88:[0x4180386eda29]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x2
    0x412240947ce8:[0x4180386182fc]BHCallHandlers@vmkernel#nover+0xbb stack: 0x100410000000000
    0x412240947d28:[0x4180386187eb]BH_Check@vmkernel#nover+0xde stack: 0xf2d814f856ba
    0x412240947e58:[0x4180387efb41]CpuSchedIdleLoopInt@vmkernel#nover+0x84 stack: 0x412240947e98
    0x412240947e68:[0x4180387f75f6]CpuSched_IdleLoop@vmkernel#nover+0x15 stack: 0x70
    0x412240947e98:[0x4180386460ea]Init_SlaveIdle@vmkernel#nover+0x13d stack: 0x0
    0x412240947fe8:[0x4180389063d9]SMPSlaveIdle@vmkernel#nover+0x310 stack: 0x0

    Ce problème est résolu dans cette version.
  • La passerelle par défaut est laissée vide si le groupe de ports dans lequel elle figure est désactivé, puis réactivé
    Si vous désactivez un groupe de ports DHCP qui contient la passerelle par défaut, celle-ci est laissée vide. Lorsque vous réactivez le groupe de ports, la passerelle par défaut est toujours laissée vide.

    Ce problème est résolu dans cette version. La passerelle par défaut est désormais mise à jour et n'est plus laissée vide.
  • Des hôtes ESXi peuvent échouer avec un écran violet lorsque le trafic réseau traverse le pilote de périphérique bnx2x
    Lorsque le trafic réseau traverse le pilote de périphérique bnx2x et que le vmklinux reçoit les paquets générés par LRO (Large Receive Offload), les paquets réseau risquent d'être supprimés entraînant ainsi l'échec des hôtes ESXi avec un écran violet.
    Les hôtes ESXi subissent une exception division par zéro pendant la scission TSO pour finalement échouer.
    Ce problème se produit lorsque le pilote bnx2x envoie le paquet LRO avec une valeur MSS TSO (TCP Segmentation Offload) définie à zéro.
    En outre, l'hôte ESXi échoue lorsque le paquet reçu n'est pas valide pour l'une des raisons suivantes :
    • La taille GSO est de zéro
    • Le type GSO n'est pas pris en charge
    • L'ID vLAN est incorrect

    Ce problème est résolu dans cette version.
  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en présence d'un conflit entre deux processus DVFilter
  • Si deux processus DVFilter tentent de gérer simultanément une variable de configuration, alors qu'un processus efface la configuration du filtre existante et que l'autre processus tente de la verrouiller, l'hôte ESXi peut échouer. Ce problème se produit lorsque vous arrêtez le système d'exploitation invité pendant le processus de nettoyage de DVFilter.
    Ce problème est résolu dans cette version.
  • Un snapshot pris sur une machine virtuelle disposant d'une carte réseau vmxnet3 inclut des statistiques de trafic incorrectes
    Lorsque vous prenez un snapshot d'une machine virtuelle disposant d'une carte réseau vmxnet3, l'interface réseau de la machine virtuelle est déconnectée, puis reconnectée, ce qui réinitialise le compteur de diffusion et entraîne une représentation incorrecte des statistiques réseau.

    Ce problème est résolu dans cette version.
  • Des hôtes ESXi risquent d'échouer avec un écran violet en raison de conditions concurrentielles dans une pile TCP/IP ESXi
    Des hôtes ESXi peuvent échouer avec un écran violet et afficher des messages d'erreur de ce type :
    2013-02-22T15:33:14.296Z cpu8:4104)@BlueScreen: #PF Exception 14 in world 4104:idle8 IP 0x4180083e796b addr 0x1
    2013-02-22T15:33:14.296Z cpu8:4104)Code start: 0x418007c00000 VMK uptime: 58:11:48:48.394
    2013-02-22T15:33:14.298Z cpu8:4104)0x412200207778:[0x4180083e796b]ether_output@ # +0x4e stack: 0x41000d44f360
    2013-02-22T15:33:14.299Z cpu8:4104)0x4122002078b8:[0x4180083f759d]arpintr@ # +0xa9c stack: 0x4100241a4e00

    Ce problème se produit en présence de conditions concurrentielles dans une pile TCP/IP ESXi.

    Ce problème est résolu dans cette version.
  • Des banques de données NFS connectées via un réseau acheminé par la couche 3 peuvent présenter une valeur GAVG élevée pour des machines virtuelles s'y exécutant sous une faible valeur IOPS
    Lorsque des banques de données NFS sont connectées via un réseau acheminé par la couche 3 et que la carte vmknic NFS ne se trouve pas dans le même sous-réseau que le gestionnaire de fichiers NFS, les banques de données peuvent présenter une valeur GAVG (Guest Average Latency) élevée pour les machines virtuelles s'y exécutant. Ce problème se produit lorsque la valeur IOPS (E/S par seconde) est faible. Pour une valeur IOPS égale ou inférieure à 1, la valeur GAVG pour les banques de données NFS peut atteindre 40 ms. Lorsqu'une charge d'E/S intense est envoyée, les valeurs GAVG diminuent pour les banques de données NFS.

    Ce problème est résolu dans cette version.
  • Les tentatives d'obtention de l'adresse MAC permanente pour une carte réseau VMXNET3 peuvent échouer
    Lorsque vous utilisez la commande ioctl ETHTOOL_GPERMADDR pour obtenir l'adresse MAC permanente d'une carte réseau VMXNET3, aucun résultat n'est obtenu si la version du noyau Linux est comprise entre 2.6.13 et 2.6.23. Si la version du noyau Linux est ultérieure à 2.6.23, l'adresse MAC renvoyée ne contient que des zéros.

    Ce problème est résolu dans cette version.
  • Les machines virtuelles disposant d'un pilote de carte réseau e1000 mises en mode suspendu D3 risquent d'échouer
    Une machine virtuelle risque d'échouer et des messages d'erreur semblables aux messages suivants peuvent être écrits dans le fichier vmware.loglorsqu'un système d'exploitation invité disposant d'un pilote de carte réseau e1000 est mis en mode suspendu D3 :

    2013-08-20T10:14:35.121Z[+13.605]| vcpu-0| SymBacktrace[2] 000003ffff023be0 rip=000000000039d00f
    2013-08-20T10:14:35.121Z[+13.606]| vcpu-0| Unexpected signal: 11

    Ce problème se produit sur la machine virtuelle qui utilise des alias IP alors que le nombre d'adresses IP est supérieur à 10.

    Ce problème est résolu dans cette version.
  • Les machines virtuelles Solaris qui utilisent l'adaptateur réseau VMXNET3 risquent de générer de façon répétitive des messages dans les fichiers journaux
    Lorsqu'un message provenant de la machine virtuelle Solaris comporte trop de segments pour tenir dans l'anneau TX, l'adaptateur réseau VMXNET3 écrit de façon répétitive les messages suivants dans les fichiers journaux :

    last message repeated 274 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 399 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 398 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 393 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    last message repeated 399 times
    vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)


    Ce problème est résolu dans cette version.
  • Les machines virtuelles qui accèdent à un lecteur de CD-ROM client risquent de cesser de répondre si la connexion réseau de vSphere Client est interrompue
    Si la connexion réseau de vSphere Client est interrompue lorsqu'une machine virtuelle utilise un lecteur de CD-ROM client, la machine virtuelle risque de cesser de répondre et de ne pas être accessible sur le réseau pendant un certain temps.

    Ce problème est résolu dans cette version.
  • La commande Linux ip link ou ip addr peut afficher un état de lien Unknown pour les adaptateurs VMXNET3 au lieu de UP
    Lorsque vous créez des adaptateurs VMXNET3 sur le système d'exploitation invité, la commande Linux, ip linkou ip addrpeut afficher l'état de lien Unknownau lieu de Up.
    Ce problème se produit lorsque l'état de lien par défaut pour les adaptateurs est défini sur le mode carrier oket par conséquent operstate n'est pas mis à jour.

    Cette version résout le problème en définissant l'état de lien par défaut pour les adaptateurs sur le mode no carrier.
  • Des machines virtuelles peuvent se déconnecter du réseau après leur redémarrage ou leur migration
    Lors de l'utilisation de vShield Endpoint et de Deep Security, un problème lié au module DvFilter peut entraîner l'épuisement de netGPHeap et une fuite de mémoire. Cela peut provoquer la déconnexion de machines virtuelles du réseau après leur redémarrage ou leur migration à l'aide de vMotion.
    Les fichiers journaux peuvent contenir des messages semblables aux messages suivants :
    2012-11-30T11:29:06.368Z cpu18:923386)WARNING: E1000: 8526: failed to enable port 0x30001b6 on vSwitch1: Out of memory

    Ce problème est résolu dans cette version.
  • Il se peut que des machines virtuelles ne puissent pas contrôler le trafic réseau sortant lorsque des adaptateurs réseau virtuels sont utilisés en mode Promiscuité
    Si vous utilisez des adaptateurs réseau virtuels en mode Promiscuité pour suivre l'activité du réseau, un problème lié à la fonction de mise en miroir des ports peut désactiver un port miroir et conduire les machines virtuelles à arrêter le suivi du trafic réseau sortant.

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

Sécurité

  • La mise à jour des adresses de la bibliothèque OpenSSL résout plusieurs problèmes de sécurité
    La bibliothèque ESXi userworld OpenSSL est mise à jour vers la version openssl-0.9.8ypour résoudre plusieurs problèmes de sécurité.
    Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué les noms CVE-2013-0169 et CVE-2013-0166.
  • Une mise à jour de la bibliothèque libxml2 résout plusieurs problèmes de sécurité
    La bibliothèque ESXi userworld libxml2 a été mise à jour pour résoudre un problème de sécurité.
    Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué le nom CVE-2013-0338 à ce problème.
  • Mise à jour de libxslt
    Le module ESXi userworld libxsltest mis à jour.
  • VMware ESXi et ESX contiennent une vulnérabilité dans hostd-vmdb
    Pour exploiter cette vulnérabilité, un pirate doit intercepter et modifier le trafic de gestion. L'exploitation de cette faille peut entraîner un déni de service du service hostd-vmdb.
    Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué le nom CVE-2013-5970 à ce problème.

Configuration des serveurs

  • Les diagrammes de performances indiquent une consommation électrique constante de 0 watt pour les serveurs IBM System x iDataPlex dx360 M3
    Lorsque vous analysez le diagramme de performances associé à la consommation électrique d'un serveur IBM System x iDataPlex dx360 M3, le diagramme indique une valeur constante de 0 watt. Ce problème est dû à un changement dans les ID des capteurs IPMI utilisés par les serveurs IBM System x iDataPlex dx360 M3.

    Ce problème est résolu dans cette version.
  • Une machine virtuelle Red Hat Enterprise Linux 4.8 32 bits peut présenter une charge moyenne plus élevée sur ESXi 5.0 que sur ESX/ESXi 4.0
    Une machine virtuelle Red Hat Enterprise Linux 4.8 32 bits soumise à une charge de travail pratiquement inactive avec l'activation intermittente ou simultanée de plusieurs tâches peut présenter une charge moyenne plus élevée sur ESXi 5.0 que sur ESX/ESXi 4.0.

    Ce problème est résolu dans cette version.
  • Plusieurs serveurs ESXi peuvent cesser de répondre lors de l'ajout d'un serveur ESXi au système vCenter Server
    Lorsque vous tentez d'ajouter un serveur ESXi au système vCenter Server, plusieurs serveurs ESXi peuvent cesser de répondre et un message semblable au message suivant peut s'afficher :
    Unable to access the specified host, either it doesn't exist, the server software is not responding, or there is a network problem.
    Ce problème se produit lorsqu'un volume élevé de demandes HTTP URL est envoyé à hostd et que le service hostd échoue.

    Ce problème est résolu dans cette version.
  • Les machines virtuelles qui ont migré de ESX/ESXi 3.5 vers ESXi 5.0 peuvent ne pas réussir à redémarrer
    Plusieurs machines virtuelles peuvent ne pas réussir à redémarrer et générer le fichier noyau VMX après le redémarrage. Ce problème est constaté sur des machines virtuelles qui ont migré à l'aide de vMotion à partir d'hôtes ESX/ESXi 3.5 vers des hôtes ESX/ESXi utilisant les versions ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1 Update 2, ESXi 5.0 Update 2, et versions ultérieures.

    Ce problème est résolu pour les hôtes ESXi 5.0 dans cette version.
  • La vérification de conformité d'hôte échoue avec une erreur liée à l'extraction de la configuration d'indication
    En présence d'un abonnement CIM non valide dans le système, si vous effectuez une vérification de conformité de profil d'hôte par rapport à un hôte, un message d'erreur semblable au message suivant peut s'afficher :

    Erreur lors de l'extraction de la configuration d'indications : (6, u'L'objet demandé est introuvable')

    Vous ne pouvez pas appliquer le profil d'hôte sur l'hôte.

    Ce problème est résolu dans cette version. Vous pouvez appliquer des profils d'hôte même si une indication non valide figure dans le profil d'hôte.
  • Un hôte ESXi cesse de répondre lors de l'arrêt ou du redémarrage de l'hôte ESXi au moyen de l'interface utilisateur de la console directe (DCUI)
    Lorsque vous tentez d'arrêter ou de redémarrer un hôte ESXi au moyen de l'interface utilisateur de la console directe (DCUI), l'hôte cesse de répondre et l'utilisateur est incapable d'exécuter le processus de mise à l'arrêt.

    Ce problème est résolu dans cette version.
  • Les tentatives d'application d'un profil d'hôte complexe peuvent entraîner une expiration de délai d'attente
    Lorsque vous appliquez un profil d'hôte complexe, par exemple un profil d'hôte contentant un grand nombre de groupes de ports et de banques de données, le délai d'attente de l'opération peut expirer avec un message d'erreur semblable au message suivant :
    2013-04-09T15:27:38.562Z [4048CB90 info 'Default' opID=12DA4C3C-0000057F-ee] [VpxLRO] -- ERROR task-302 -- -- vim.profile.host.profileEngine.HostProfileManager.applyHostConfig: vmodl.fault.SystemError:
    --> Result:
    --> (vmodl.fault.SystemError) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> reason = "",
    --> msg = "Une erreur système générale s'est produite : ",
    --> }
    Le délai d'attente par défaut du service hostd est de 10 minutes. Dans la mesure où applyHostConfig n'est pas une tâche progressive, le service hostd ne peut pas faire la distinction entre une tâche ayant échoué et une tâche de longue durée pendant le délai d'attente de hosttd. Par conséquent, le service hostd signale que la tâche applyHostConfig a échoué.

    Ce problème est résolu dans cette version en installant un délai d'attente de 30 minutes dans le cadre de l'objet géré HostProfileManager. Cependant, ce problème risque de se produire à nouveau si vous tentez d'appliquer un profil d'hôte volumineux et que la tâche peut dépasser le délai d'attente maximal de 30 minutes. Pour résoudre ce problème, réappliquez le profil d'hôte.
  • Un hôte ESXi peut être déconnecté du système vCenter Server lorsque hostd échoue
    Des hôtes ESXi peuvent être déconnectés du système vCenter Server lorsque hostd échoue avec des messages d'erreur semblables aux messages suivants :
    2013-06-04T11:47:30.242Z [6AF85B90 info 'ha-eventmgr'] Event 110 : /sbin/hostd a planté (1 fois jusqu'à maintenant) et un fichier noyau peut avoir été créé à /var/core/hostd-worker-zdump.000. Cela peut avoir provoqué l'abandon des connexions vers l'hôte.
    Ce problème se produit lorsqu'une vérification est effectuée afin de s'assurer que la configuration du cache est correcte.

    Ce problème est résolu dans cette version.
  • La connexion à l'hôte ESXi peut être perdue lorsque vous exécutez des commandes ESXCLI ou utilisez des outils de contrôle qui reposent sur l'agent SNMP
    Lorsque vous exécutez des commandes ESXCLI ou si vous utilisez des outils de contrôle qui reposent sur des données provenant de l'agent SNMP dans ESXi, la connexion à l'hôte ESXi peut être perdue en raison de l'échec du service hostd.

    Ce problème est résolu dans cette version.
  • Impossible d'attribuer une autorisation aux utilisateurs et aux groupes Active Directory
    Après l'ajout d'un hôte ESXi 5.0 dans un domaine Active Directory (AD), une tentative d'attribution d'autorisation à des utilisateurs et des groupes AD peut échouer. Vous ne pouvez pas voir le domaine auquel vous avez joint l'hôte dans le menu déroulant pour ajouter des autorisations à des utilisateurs et des groupes AD. Le problème se produit lorsque le service lsassdsur l'hôte s'arrête. Le fichier lsassd.logaffiche des entrées semblables aux entrées suivantes :

    20111209140859:DEBUG:0xff92a440:[AD_DsEnumerateDomainTrusts() /build/mts/release/bora-396388/likewise/esxi-esxi/src/linux/lsass/server/auth-providers/ad-provider/adnetapi.c:1127] Failed to enumerate trusts at host.your.domain.name.net (error 59)
    20111209140859:DEBUG:0xff92a440:[AD_DsEnumerateDomainTrusts() /build/mts/release/bora-396388/likewise/esxi-esxi/src/linux/lsass/server/auth-providers/ad-provider/adnetapi.c:1141] Error code: 40096 (symbol: LW_ERROR_ENUM_DOMAIN_TRUSTS_FAILED)


    Ce problème est résolu dans cette version.
  • Un hôte ESXi échoue avec un écran de diagnostic violet en raison d'un dépassement de mémoire tampon et d'une troncature dans le gestionnaire de processus hpsc
    Lorsque vous exécutez la commande cat sur un contrôleur HP Smart Array comportant au moins 40 numéros d'unités logique, l'hôte ESXi échoue avec un écran de diagnostic violet. Cet incident se produit en raison du dépassement de mémoire tampon et de la troncature de données dans le gestionnaire hpsc.

    Ce problème est résolu dans cette version.
  • Lorsque vous démarrez à partir d'un SAN, la découverte du périphérique de démarrage peut être plus longue selon la bande passante du réseau
    Lorsque vous démarrez à partir d'un SAN, le processus de découverte du périphérique de démarrage peut être plus long à s'exécuter. L'envoi d'un paramètre de délai d'expiration de la réanalyse à la ligne de commande ESX avant le processus de démarrage permet à l'utilisateur de configurer la valeur du délai d'attente, ce qui résout le problème.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi peut arrêter la consignation des messages dans des fichiers journaux en raison d'erreurs liées à la mémoire
    En raison d'une allocation de mémoire insuffisante au pool de ressources de journalisation, ESXi peut arrêter de consigner des messages dans les fichiers journaux. Des messages semblables aux messages suivants sont inclus dans les fichiers journaux :

    <TimeStamp> vmsyslog.main : ERROR ] Watchdog 2625 fired (child 2626 died with status 256)!
    <TimeStamp> vmsyslog : CRITICAL] vmsyslogd daemon starting (69267)
    <TimeStamp> vmsyslog.main : ERROR ] Watchdog 2625 exiting
    <TimeStamp> vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/hostd0.gz failed
    <TimeStamp> vmsyslog.main : ERROR ] failed to write log, disabling
    <TimeStamp> vmsyslog.main : ERROR ] failed to send vob: [Errno 28] No space left on device


    Ce problème est résolu dans cette version. La limite du pool de mémoire de journalisation augmente pour passer à 48 Mo.
  • Les interfaces réseau VMkernel autres que vmk0 perdent leur adresse IP non liée sur un serveur DHCP
    Lorsqu'une interface VMkernel a acquis son bail IP d'un serveur DHCP dans un autre sous-réseau, des messages d'erreur semblables aux messages suivants peuvent être affichés par le serveur DHCP :
    2012-08-29T21:36:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:36:35Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:36:49Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:08Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:39Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:37:52Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:01Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:19Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:29Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:41Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:38:53Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:39:09Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67
    2012-08-29T21:39:24Z dhclient-uw[4884]: DHCPREQUEST on vmk1 to 192.168.2.210 port 67

    La fourniture au serveur DHCP d'une interface sur le même sous-réseau que le port VMkernel pour permettre le renouvellement DHCP résout ce problème.

    Ce problème est résolu dans cette version.
  • VMKernel échoue lorsqu'un moniteur de machine virtuelle renvoie un numéro de page machine non valide
    Lorsque VMX transmet une valeur VPN pour lire une page, VMKernel ne parvient pas à trouver un numéro de page machine valide pour cette valeur VPN ce qui entraîne l'échec de l'hôte avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.
  • Un hôte ESX peut échouer suite à un échec d'allocation de mémoire à partir du tas World (vmkernel) pour les traces de déclenchement
    Des hôtes ESX peuvent échouer avec un écran de diagnostic violet suite à un échec d'allocation de mémoire à partir du tas World pour les traces de déclenchement, mécanisme utilisé par vmkernel pour effectuer un traitement par lot après l'écriture de traces dans les pages invité. Ce problème se produit lorsque cet échec d'allocation de mémoire n'est pas géré correctement.

    Ce problème est résolu dans cette version.
  • L'exécution de commandes esxcfg-nassur un hôte ESXi donne lieu à un avertissement PREF
    Lorsque vous exécutez la commande esxcfg-nas -l, l'hôte ESXi affiche un message d'avertissement semblable au message suivant :
    PREF Warning: PreferenceGet(libdir) before Preference_Init, do you really want to use default?

    Ce problème est résolu dans cette version.
  • L'exécution des tests de performance Hostd provoque des problèmes de régression
    Pendant les tests de performances hostd, lorsque vous effectuez certaines opérations de machine virtuelle telles que la création, la reconfiguration ou le nettoyage des machines virtuelles, ces opérations peuvent entraîner des problèmes de régression. Cela se produit parce qu'un appel d'actualisation de banque de données est traité pour chaque message vdiskupdate. La modification de la logique d'actualisation de banque de données résout ce problème.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi inclut des messages Unknown associés au stockage dans des fichiers syslog.log
    Lorsque vpxa écrit des entrées syslog d'une longueur supérieure à 1 024, il classe le corps du message au-delà des 1 024 premiers octets comme Unknown et place ces entrées dans le fichier syslog.loget non dans le fichier vpxa.log. Par la suite, l'hôte ESXi inclut des messages Unknown liés au stockage dans les fichiers syslog.log. Dans cette version, la limite de tampon de ligne est augmentée pour résoudre ce problème.

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

Stockage

  • Des problèmes de performances peuvent être constatés sur des hôtes ESXi lors de la migration de disques statiques mis à zéro en différé
    Les vitesses de migration de certains disques statiques mis à zéro en différé peuvent être faibles sur certains hôtes ESXi par comparaison à d'autres transferts de disque de même taille. Ce problème se produit lorsque des pages de mémoire pour le cache du système de fichiers (cache de mémoire tampon) se trouvent dans la première zone de 2 Mo de la mémoire. Les vitesses de migration deviennent donc faibles pour ESXi.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi échoue avec un écran de diagnostic violet lorsque vous ajoutez un hôte à un cluster
    Lorsque vous ajoutez un hôte au cluster et reconfigurez High Availability, l'hôte ESXi échoue avec un écran de diagnostic violet.
    Ce problème est résolu dans cette version.
  • Un hôte ESXi peut échouer avec un écran violet en raison de la corruption de métadonnées de LUN
    Lorsque vous effectuez certaines opérations de machine virtuelle, un problème lié à la corruption de métadonnées de LUN peut parfois causer l'échec d'un hôte ESXi avec un écran violet et afficher des messages d'erreur semblables aux messages d'erreur suivants :
    @BlueScreen: #DE Exception 0 in world 4277:helper23-15 @ 0x41801edccb6e3:21:13:31.624 cpu7:4277)Code start: 0x41801e600000
    VMK uptime: 3:21:13:31.6243:21:13:31.625 cpu7:4277)0x417f805afed0:[0x41801edccb6e]Fil3_DirIoctl@esx:nover+0x389 stack:
    0x410007741f603:21:13:31.625 cpu7:4277)0x417f805aff10:[0x41801e820f99]FSS_Ioctl@vmkernel:nover+0x5c stack:
    0x2001cf5303:21:13:31.625 cpu7:4277)0x417f805aff90:[0x41801e6dcf03]HostFileIoctlFn@vmkernel:nover+0xe2 stack:
    0x417f805afff03:21:13:31.625 cpu7:4277)0x417f805afff0:[0x41801e629a5a]helpFunc@vmkernel:nover+0x501 stack: 0x03:21:13:31.626 cpu7:4277)0x417f805afff8:[0x0] stack: 0x0


    Ce problème est résolu dans cette version. La corruption des métadonnées de LUN entraînera désormais un message d'erreur.
  • NetApp a demandé une mise à jour à la règle de réclamation SATP qui empêche iSCSI de cesser de répondre
    NetApp a demandé une mise à jour à la règle de réclamation SATP qui empêche le conflit de réservation pour un numéro d'unité logique (LUN). La règle de réclamation SATP mise à jour utilise l'option de réinitialisation pour effacer la réservation du LUN et permettre à d'autres utilisateurs de définir l'option de réservation.

    Ce problème est résolu dans cette version.
  • De faux messages d'état Device Busy (D:0x8) peuvent être inclus dans des fichiers journaux VMkernel lorsque VMKlinux définit de manière incorrecte l'état du périphérique
    Lorsque VMKlinux définit de manière incorrecte l'état du périphérique, de faux messages d'état Device Busy (D:0x8)sont écrits dans des fichiers journaux de VMkernel, semblables aux messages suivants :
    2013-04-04T17:56:47.668Z cpu0:4012)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x412441541f80) 0x16, CmdSN 0x1c9f from world 0 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x0 D:0x8 P:0x0 Possible sense data: 0x0 0x0 0x0
    Cela génère de fausses alarmes, car la baie de stockage n'envoie pas de message d'état Device Busy pour des commandes SCSI.
    Ce problème est résolu dans cette version en désignant correctement des messages d'état Host Bus Busy (H:0x2) pour les problèmes dans les pilotes de périphériques semblables aux messages suivants :
    2013-04-04T13:16:27.300Z cpu12:4008)ScsiDeviceIO: SCSICompleteDeviceCommand:2311: Cmd(0x4124819c2f00) 0x2a, CmdSN 0xfffffa80043a2350 from world 4697 to dev "naa.600601601fb12d00565065c6b381e211" failed H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

  • Ce problème est résolu dans cette version.
  • La taille d'un disque de machine virtuelle à provisionnement statique de 2 To est indiquée comme étant de 0 octet dans le navigateur de banques de données.
  • Lorsque vous créez un fichier de disque de machine virtuelle (VMDK) à approvisionnement statique d'une taille de 2 To, le navigateur de banques de données indique la taille du disque VMDK de façon incorrecte comme étant de 0,00 octet.
    Ce problème est résolu dans cette version.
  • Le clonage et la migration à froid de machines virtuelles disposant de fichiers VMDK et de snapshot volumineux peuvent échouer
    Il se peut que vous ne puissiez pas cloner des machines virtuelles ni en effectuer une migration à froid vers d'autres banques de données si ces machines virtuelles disposent de fichiers de disque de machine virtuelle (VMDK) et de snapshot volumineux. Ce problème se produit lorsque le processus vpxa dépasse la limite d'allocation de mémoire lors de la migration à froid. L'hôte ESXi perd alors la connexion au système vCenter Server et la migration échoue.

    Ce problème est résolu dans cette version.
  • De fausses alarmes peuvent être générées lorsque la valeur de l'espace provisionné pour une banque de données NFS n'est pas correctement calculée
    Sous certaines conditions, la valeur de l'espace provisionné pour une banque de données NFS risque de ne pas être correctement calculée et de provoquer la génération de fausses alarmes.

    Ce problème est résolu dans cette version.
  • vCenter Server ou vSphere Client peut être déconnecté de l'hôte ESXi pendant la création de la banque de données VMFS
    vCenter Server ou vSphere Client peut être déconnecté de l'hôte ESXi pendant la création de la banque de données VMFS. Ce problème se produit lorsque le service hostd échoue avec un message d'erreur semblable au message suivant dans le journal hostd :
    Panic: Assert Failed \\\"matchingPart != __null\\\"
    Le processus hostd échoue pendant la création d'une banque de données VMFS sur des disques disposant d'une configuration de partition nécessitant un alignement de partition.

    Ce problème est résolu dans cette version.
  • Il est possible que l'entrée/sortie du cluster de basculement Microsoft ne soit pas conservée avec Storage Fault Tolerance
    Il est possible que l'entrée/sortie du cluster de basculement Microsoft ne soit pas conservée avec Storage Fault Tolerance et qu'elle échoue en raison d'un conflit de réservation. Ce problème se produit lorsque deux machines virtuelles à cluster de basculement sont placées sur deux hôtes ESXi différents et que la baie de stockage s'exécute dans une configuration ALUA.

    Ce problème est résolu dans cette version.
  • Impossible de monter une banque de données NFS dont le nom de chemin distant compte 115 caractères ou plus
    Il se peut que vous ne puissiez pas monter une banque de données NFS dont le nom de chemin distant compte 115 caractères ou plus. Un message d'erreur similaire au message suivant s'affiche :
    Unable to get Console path for Mount

    Un hôte ESXi gère le volume NAS comme une combinaison de l'adresse IP du serveur NFS et du nom de chemin complet du partage exporté. Ce problème se produit lorsque la longueur de cette combinaison dépasse 128 caractères.

    Ce problème est résolu dans cette version en portant la taille du volume NAS à 1 024.
  • Un hôte ESXi peut cesser de répondre à partir du système vCenter Server lorsque vous attribuez une nouvelle signature à un grand nombre de volumes de snapshot VMFS
    Un hôte ESXi peut cesser de répondre de façon intermittente ou être déconnecté du système vCenter Server lorsque vous attribuez une nouvelle signature à un grand nombre de volumes de snapshot VMFS (Virtual Machine File System).

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

Mise à niveau et installation

  • Échec de la correction des hôtes sur des bulletins qui n'ont qu'un impact Redémarrer
    Au cours du processus de correction d'un hôte ESXi sur une ligne de base de correctifs, qui se compose de bulletins n'ayant qu'un impact Redémarrer, Update Manager ne met pas hors tension ni ne suspend les machines virtuelles résidant sur l'hôte. Par conséquent, l'hôte ne peut pas entrer en mode de maintenance et la correction ne peut pas être effectuée.

    Ce problème est résolu dans des bulletins créés dans cette version et dans des versions ultérieures.
  • Fichier de sauvegarde state.tgz introuvable sur le périphérique de démarrage lors d'une tentative de mise à niveau de l'hôte ESXi
    Lorsque vous tentez de mettre à niveau un hôte ESXi en utilisant l'image ISO, il se peut que vous ne puissiez pas trouver le fichier de sauvegarde state.tgzsur le périphérique de démarrage.
    Ce problème survient si le fichier de sauvegarde state.tgzn'est pas mis à jour parce que vous n'avez pas arrêté correctement votre machine avant de procéder à la mise à niveau. Le message d'erreur d'exception No such a files'affiche donc lorsque vous réinitialisez la licence ESXi.

    Ce problème est résolu dans cette version.
  • La commande esxcli ne parvient pas à gérer les noms de banques de données qui incluent des espaces ou des parenthèses
    Les noms de banques de données comportant des espaces ou des parenthèses ne sont pas gérés correctement par la commande esxcli. Ce problème est constaté lorsque l'utilisateur tente une mise à niveau d'ESXi à l'aide de la commande esxcli.

    Ce problème est résolu dans cette version.
  • Il se peut que la configuration du serveur Syslog ne puisse pas être migrée vers de nouvelles configurations lors de la mise à niveau de plusieurs serveurs ESXi 4.x vers des serveurs ESXi 5.x
    Dans ESXi 4.x, la configuration du chemin Syslog.Local.DatastorePathest stockée dans le fichier /etc/syslog.conf.
    Cependant, dans ESXi 5.x, le fichier /etc/syslog.confest remplacé par le fichier /etc/vmsyslog.confet la configuration du répertoire Syslog.global.logDirest stockée dans le fichier /etc/vmsyslog.conf.
    Par conséquent, les configurations du serveur Syslog des attributs logfileet loghostdans le fichier /etc/syslog.confne sont pas migrées dans les nouveaux attributs configurés logdiret loghostdans le nouveau fichier /etc/vmsyslog.conf. Pour cette raison, lors de la mise à niveau de plusieurs serveurs ESXi 4.x vers des serveurs ESXi 5.x, vous devez configurer manuellement le répertoire Syslog.global.logDirà la fin de chaque mise à niveau.

    Ce problème est résolu dans cette version par la mise à jour des attributs de la manière suivante :
    1. L'attribut loghostdans le fichier /etc/syslog.confest conservé dans le nouveau fichier /etc/vmsyslog.conf.
    2. L'attribut logfilen'est maintenant plus valide. Cet attribut est migré vers l'attribut logdirdans le nouveau fichier /etc/vmsyslog.conf. La valeur de l'attribut logdirest le nom de répertoire de l'ancienne valeur d'attribut logfile. La migration s'exécute uniquement lorsque le répertoire est toujours un répertoire valide sur le système mis à niveau.
  • Des tentatives de mise à niveau d'un hôte ESXi dans un cluster HA peuvent échouer avec vCenter Update Manager
    La mise à niveau d'un hôte ESXi dans un cluster HA (High Availability) peut échouer avec un message d'erreur semblable au message suivant avec vCenter Update Manager (VUM) :
    the host returned esx update error code 7
    Ce problème se produit lorsque plusieurs opérations de transfert sont exécutées avec différentes lignes de base dans Update Manager.

    Ce problème est résolu dans cette version.
  • L'installation ou la mise à niveau d'ESXi par script à partir d'un lecteur USB connecté peut échouer si le type de système de fichiers de l'un des lecteurs USB n'est ni Fat 16 ni Fat 32
    Si plusieurs lecteurs flash USB sont connectés à un hôte ESXi, l'installation ou la mise à niveau d'ESXi par script effectuée à l'aide de l'option ks=usbpeut échouer avec une erreur d'exception si le type de système de fichiers de l'un des lecteurs USB disposant d'une partition MS-DOS n'est ni Fat 16 ni Fat 32.

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

vCenter Server et vSphere Client

  • L'onglet Résumé peut afficher des valeurs d'espace provisionné incorrectes pour des machines virtuelles et des banques de données NFS ou NAS sur des hôtes sur lesquels VAAI est activé
    Lorsqu'un disque virtuel disposant du format de provisionnement statique mis à zéro en différé est créé sur un NAS pris en charge par VAAI dans un hôte ESXi sur lequel VAAI est activé, l'espace provisionné pour la machine virtuelle et la banque de données correspondantes peut ne pas s'afficher correctement.

    Ce problème est résolu dans cette version.
  • Un diagramme de performances personnalisé ne fournit pas l'option permettant d'afficher les diagrammes de disques virtuels pour des objets de machines virtuelles
    Lorsque vous utilisez la mesure de disque virtuel pour afficher les diagrammes de performances, vous pouvez uniquement afficher les diagrammes de performances de disque virtuel correspondant aux objets de disques virtuels disponibles.

    Cette version vous permet également d'afficher les diagrammes de performances de disques virtuels pour les objets de machines virtuelles. Cela est pratique lorsque vous devez déclencher des alarmes en fonction de l'utilisation des disques virtuels par des machines virtuelles.

Gestion des machines virtuelles

  • La mise sous tension de machines virtuelles échoue lorsque leurs fichiers VMDK ne sont pas accessibles
    Sur un hôte ESXi, la mise sous tension d'une machine virtuelle échoue si son fichier VMDK n'est pas accessible et si, dans son fichier VMX, disk.powerOnWithDisabledDiskest défini sur TRUEet answer.msg.disk.notConfiguredest défini sur Yes. Le message d'erreur suivant s'affiche :
    The system cannot find the file specified.

    Ce problème est résolu dans cette version.
  • Le fichier VMX d'une machine virtuelle n'est pas mis à jour après que vous avez pris son snapshot mis au repos
    Lorsque vous prenez un snapshot mis au repos d'une machine virtuelle, le fichier vmx n'est mis à jour que lors de la prochaine mise sous tension de la machine virtuelle. La configuration vmxest obsolète et elle pointe vers le VMDK d'origine. Si la machine virtuelle échoue entre l'opération de snapshot et la mise sous tension suivante, une perte de données se produit et le VMDK est laissé dans un état orphelin. 

    Ce problème est résolu dans cette version.
  • Les tentatives d'installation de Linux sur une machine virtuelle peuvent échouer
    Lorsqu'une image disquette est liée à une machine virtuelle, une tentative d'installation du système d'exploitation Linux sur celle-ci peut échouer.
    Le fichier vmware.logpeut contenir des entrées similaires aux entrées suivantes :

    RemoteFloppyVMX: Remote cmd uid 0 timed out.
    | vcpu-3| Caught signal 11 -- tid 115057
    | vcpu-3| SIGNAL: eip 0x1f5c2eca esp 0xcaf10da0 ebp 0xcaf10e00
    | vcpu-3| SIGNAL: eax 0x0 ebx 0x201826a0 ecx 0x593faa10 edx 0x201d63b0 esi 0x0 edi 0x593faa00
    | vcpu-3| r8 0x593faa00 r9 0x0 r10 0x1fd79f87 r11 0x293 r12 0x2022d000 r13 0x0 r14 0x0 r15 0x1fd6eba0
    | vcpu-3| Backtrace:
    | vcpu-3| Backtrace[0] 00000000caf109a0 rip=000000001f8caf9e rbx=000000001f8cad70 rbp=00000000caf109c0 r12=0000000000000000 r13=00000000caf198c8 r14=00000000caf10b50 r15=0000000000000080
    ....
    | vcpu-3| SymBacktrace[2] 00000000caf10ad0 rip=000000000038c00f
    | vcpu-3| Unexpected signal: 11.
    | vcpu-3| Writing monitor corefile "/vmfs/volumes/519f119b-e52d3cf3-6825-001999db3236/EMS/vmmcores.gz"


    Ce problème est résolu dans cette version.
  • Une erreur de page dans le moniteur de machine virtuel provoque une panne de l'hôte ESXi
    Une erreur de page dans le moniteur de machine virtuel peut provoquer l'échec d'un hôte ESXi avec un écran de diagnostic violet et la signalisation d'une erreur d'exception de page semblable à l'entrée suivante dans vmware.log :
    2013-05-15T12:48:25.195Z| vcpu-1| W110: A core file is available in "/vmfs/volumes/5088c935-f71201bf-d750-90b11c033174/BF-TS5/vmx-zdump.000" 2013-05-15T12:48:25.196Z| vcpu-1| I120: Msg_Post: Error 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1) 2013-05-15T12:48:25.196Z| vcpu-1| I120+ vcpu-1:VMM fault 14: src=MONITOR rip=0xfffffffffc243748 regs=0xfffffffffc008e98 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5088c935-f71201bf-d750-90b11c033174/BF-TS5/vmware.log". 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support. 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86] 2013-05-15T12:48:25.196Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support". 2013-05-15T12:48:25.196Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement. 2013-05-15T12:48:25.196Z| vcpu-1| I120:


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


  • Des machines virtuelles peuvent échouer lorsque vous effectuez des opérations liées à un disque virtuel
    Des opérations d'E/S associées à un disque virtuel, notamment celles associées à de nouvelles tentatives d'accès à un CD-ROM, peuvent provoquer l'échec de machines virtuelles.
    Les fichiers journaux peuvent contenir des entrées similaires aux suivantes :
    <Time_Stamp> vmx| [msg.vmxaiomgr.retrycontabort.rudeunplug] The operation on file "/vmfs/volumes/16b2bd7c-1d66d7ef/VMware/VMware-VIMSetup-all-5.1.0-947939.iso" failed.
    <Time_Stamp> vmx| --> If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media.
    <Time_Stamp> vmx| --> Select Retry to attempt the operation again.
    ...
    Followed by:

    <Time_Stamp> vmx| MsgQuestion: msg.vmxaiomgr.retrycontabort.rudeunplug reply=0
    <Time_Stamp> vmx| VMXAIOMGR: Reopening /vmfs/volumes/16b2bd7c-1d66d7ef/VMware/VMware-VIMSetup-all-5.1.0-947939.iso and retrying outstanding IOs
    ...


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

  • Les tentatives d'exportation d'une machine virtuelle au format OVF échouent avec une erreur de délai d'attente
    Lorsque vous tentez d'exporter une machine virtuelle au format OVF (Open Virtualization Format), si la machine virtuelle est composée d'une grande proportion de blocs vides sur le disque, par exemple 210 Go ou plus, et utilise un système de fichiers Ext 2 ou Ext 3, l'opération expire.

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

vMotion et Storage vMotion

  • Une sauvegarde incrémentielle peut échouer avec une erreur FileFault pour QueryChangedDiskAreasaprès le déplacement d'un VMDK dans un autre volume à l'aide de vMotion pour une machine virtuelle sur laquelle le suivi CBT est activé
    Lorsque vous activez CBT (Changed Block Tracking) sur une machine virtuelle et effectuez QueryChangedDiskAreasaprès le déplacement d'un disque de machine virtuelle (VMDK) dans un autre volume à l'aide de vMotion, la sauvegarde incrémentielle peut échouer avec une erreur FileFault semblable à l'erreur suivante :
    2012-09-04T11:56:17.846+02:00 [03616 info 'Default' opID=52dc4afb] [VpxLRO] -- ERROR task-internal-4118 -- vm-26512 -- vim.VirtualMachine.queryChangedDiskAreas: vim.fault.FileFault:
    --> Result:
    --> (vim.fault.FileFault) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> file = "/vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> msg = "Erreur provoquée par le fichier /vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> }

    Ce problème se produit lorsqu'une fonction de bibliothèque réinitialise de manière incorrecte la fonction de suivi de changement de disques.

    Ce problème est résolu dans cette version.
  • Une opération Storage vMotion sur une machine virtuelle disposant d'un stockage de 2 To peut échouer
    Lorsque vous utilisez Storage vMotion pour migrer des machines virtuelles disposant d'un stockage de 2 To , c'est-à-dire 2 disques de 1 To, un message d'erreur semblable au message suivant peut s'afficher :
    A general system error occurred: La source a détecté que la destination n'a pas pu reprendre ses opérations.


    La machine virtuelle ne peut pas démarrer sur l'hôte de destination et un message d'erreur semblable au message suivant s'affiche :
    Error: "VMware ESX unrecoverable error: (vmx) Unexpected signal 8".

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

VMware HA et Fault Tolerance

  • Le basculement d'une machine virtuelle vers un hôte de basculement désigné peut échouer pour un hôte ESXi sur lequel HA est activé
    Lorsque High Availability (HA) est activé sur l'hôte ESXi et que vMotion est exécuté, le basculement d'une machine virtuelle vers un hôte de basculement désigné peut échouer.
    Ce problème se produit lorsque les fichiers d'échange de la machine virtuelle (fichiers .vswp) sont verrouillés après que les agents FDM (Fault Domain Manager) pour HA n'ont pas réussi à basculer la machine virtuelle sur l'hôte désigné.

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

VMware Tools

  • Le pilote d'interface de communication de machines virtuelles (VMCI) échoue la compilation sur un noyau Linux 3.8.0-rc3+
    Lorsque vous installez VMware Tools sur un noyau Linux 3.8.0-rc3+, la compilation des pilotes VMCI échoue. La suppression de certains pilotes Linux du noyau résout ce problème.

    Ce problème est résolu dans cette version.
  • Après l'installation de VMware Tools sur une machine virtuelle CentOS 6.4 32 bits, le système redémarre en boucle
    Après l'installation de VMware Tools sur une machine virtuelle CentOS 6.4 32 bits et le redémarrage de la machine virtuelle, cette dernière redémarre en boucle. Ce problème est dû à l'incompatibilité du noyau.

    Ce problème est résolu dans cette version.
  • Il se peut que SMVI ne puisse pas sauvegarder la machine après la mise à niveau de VMware Tools
    Après la mise à niveau de VMware, il se peut que NetApp SnapManager for Virtual Infrastructure (SMVI) ne puisse pas sauvegarder la machine. En outre, la création d'un snapshot mis au repos peut échouer avec un message d'erreur semblable au message suivant :
    Impossible de créer un snapshot suspendu car l'opération a dépassé la limite de temps autorisée de blocage des E/S sur la machine virtuelle interrompue.

    Ce problème se produit avec des machines virtuelles Windows Server 2008, Windows Server 2008 R2 et Windows Server 2012. Ce problème ne se produit pas avec des machines virtuelles Windows 2003.

    Ce problème est résolu dans cette version.
  • La propriété prefixLength de l'objet de données NetIpConfigInfoIpAddress peut afficher des informations de masque de sous-réseau incorrectes sur certaines machines virtuelles
    L'objet de données, NetIpConfigInfoIpAddress, fournit des informations sur une adresse IP spécifique. Pour certaines machines virtuelles, la propriété prefixLength de l'objet de données NetIpConfigInfoIpAddress, qui est utilisée pour indiquer la longueur d'un préfixe d'adresse réseau Internet générique, peut afficher des informations de masque de sous-réseau incorrectes.
    Ce problème se produit lorsque l'attribut endianness de l'adresse IP, qui détermine combien d'octets sont ordonnés dans la mémoire de l'ordinateur, est erroné dans le calcul du masque de sous-réseau.
    Ce problème se produit avec des machines virtuelles Windows Server 2008 R2 (64 bits) et Windows Server 2003.

    Ce problème est résolu dans cette version.
  • Le pilote SVGA par défaut peut conduire des machines virtuelles Windows Server 2008 à cesser de répondre après l'installation de VMware Tools
    Après l'installation de VMware Tools, des machines virtuelles Windows Server 2008 peuvent cesser de répondre lorsqu'une opération de redémarrage est initiée dans la page de connexion au système. Ce problème se produit lorsque les paramètres par défaut des pilotes SVGA qui sont installés avec VMware Tools sont incorrects. Les machines virtuelles peuvent aussi cesser de répondre si vous déplacez la souris et appuyez sur une touche pendant le processus de redémarrage.

    Ce problème est résolu dans cette version.
  • Lorsque vous installez VMware Tools en utilisant des packages spécifiques du système d'exploitation (OPS), le répertoire /tmp/vmware-root se remplit de fichiers vmware-db.pl.*
  • Lorsque vous installez VMware Tools en utilisant des OSP, vous pouvez constater une augmentation du nombre de fichiers journaux dans le répertoire /tmp/vmware-root. Ce problème est constaté sur SUSE Linux Enterprise Server 11 Service Pack 2 et Red Hat Enterprise Linux Server 6.

    Ce problème est résolu dans cette version.
  • Des tentatives d'installation de VMware Tools peuvent échouer avec le noyau Linux version 3.7 et versions ultérieures
    Les pilotes de VMware Tools ne sont pas compilés, car les scripts d'installation de VMware Tools ne peuvent pas identifier le chemin d'en-tête du nouveau noyau avec le noyau Linux version 3.7 et versions ultérieures, et version 3.8. Cela peut entraîner des échecs d'installation de VMware Tools.

    Ce problème est résolu dans cette version.
  • Le service VMware Tools échoue lorsque la clé de registre IntallPath est manquante
    Pendant l'installation de VMware Tools, le processus vmusrpeut échouer. Cela se produit parce que le processus de désinstallation commence avant la fin du processus vmusr. Plus spécifiquement, le processus de désinstallation supprime une clé de registre que le processus vmusrtente de lire ultérieurement, ce qui entraîne l'échec du service VMware.

    Ce problème est résolu dans cette version.
  • L'agent de protection de vCenter affiche un message d'avertissement pour un exécutable non signé dans une mise à jour de VMware Tools
    Lorsque vous tentez d'effectuer une mise à jour de VMware Tools sur un poste de travail VMware, l'agent de protection de vCenter affiche un message indiquant l'utilisation d'un exécutable non signé. L'inclusion du fichier dans le formulaire signé résout ce problème.

    Ce problème est résolu dans cette version.
  • Impossible d'afficher les noms et descriptions du processeur de la VM ou les compteurs de performances de la mémoire de la VM sous Windows Vista ou des versions ultérieures des systèmes d'exploitation invités
    Lors de la configuration d'un journal de performances à distance sur des systèmes d'exploitation invités, tels que Windows Vista ou versions ultérieures, s'exécutant en tant qu'administrateur, il se peut que les noms et descriptions du processeur de la VM et des compteurs de la mémoire de la VM ne s'affichent pas dans la console Analyseur de performances Windows (perfmon).
    Cela se produit lorsque les paramètres régionaux du système d'exploitation invité Windows sont autres que en_us ou de. Ce problème se produit avec VMware Tools version 8.3.1.2.

    Ce problème est résolu dans cette version.
  • Les modules pré-intégrés (PBM) UEK2-200 et UEK-400 peuvent être manquants dans le programme d'installation de Linux Tools pour les noyaux Oracle 5.x
    Les modules pré-intégrés (PBM) UEK2-200 et UEK-400 peuvent être manquants dans le programme d'installation de Linux Tools pour les noyaux Oracle 5.9 2.6.39-200/400.

    Ce problème est résolu dans cette version.
  • VMware Tools est mis à jour pour fournir des modules prédéfinis (PBM) pour SUSE Linux Enterprise Server 11 SP3 et Oracle Linux 6.4

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 ne concerne que cette version d'ESXi 5.0 Update 3, ESXi 5.0 Update 2, 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. Les problèmes connus qui n'ont pas été documentés auparavant sont marqués du symbole *.

Liste des problèmes identifiés

Les problèmes sont classés comme suit.

Installation
  • Un message d'avertissement superflu lié à la mise en réseau s'affiche après l'installation d'ESXi 5.0 Update 3
    Après l'installation d'ESXi 5.0 Update 3, l'interface DCUI (Direct Console User Interface) d'ESXi affiche un message d'avertissement semblable 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 --fstype< pour la commande part dans 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 il 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.

  • Informations 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
    Après avoir installé vSphere PowerCLI sur Microsoft PowerShell 1.0 et ajouté un progiciel OEM à un profil d'image, lorsque vous listez le profil d'image, il manque des informations concernant les propriétés des Règles.

    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 exemple : ks=cdrom:/KS.CFG

  • Message d'erreur erroné lorsque vous tentez d'installer des VIB, et que vous utilisez un chemin relatif
    Lorsque 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.

  • Après avoir installé vSphere Web Client, un navigateur s'ouvre et affiche une page vierge
    Après avoir installé vSphere Client, un navigateur s'ouvre et affiche une page vierge lorsque 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.

Mise à niveau

  • Impossible d'appliquer les VIB d'ESXi 5.0 Update 3 via 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 3 en utilisant la commande GET-ESXCLIsur PowerCLI échouent avec des messages d'erreur semblables 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 : Procédez comme suit pour résoudre le problème.

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

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

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

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

vSphere

  • L'adaptateur réseau Emulex be2net portant l'ID de périphérique 0710 ne peut pas être sondé dans ESXi 5.0 (KB  2041665 )

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

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

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

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

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

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

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

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

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

     

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

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

     

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

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

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

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

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

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

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

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

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

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

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

     

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

    Solution :Aucune.

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

    Solution :Aucune.

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

    Solution :Aucune.

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

    Solution :Aucune.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Solution :Aucune.

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

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

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

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

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

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

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

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

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Solution : Effectuez l'une des actions suivantes :

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

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

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


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

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

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

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

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

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

     

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

    Solution : Effectuez l'une des actions suivantes :

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

     

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

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

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

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

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

vCenter Server et vSphere Client

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

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

  • Erreur de base de données lors du réenregistrement d'AutoDeploy sur vCenter Virtual Appliance (VCVA) (KB 2014087).
  • Le commande snmpwalk renvoie un message d'erreur quand vous l'exécutez sans l'option -t
    Quand la commande snmpwalkest exécutée sans les options -tet -rpour l'interrogation des données SNMP, l'agent SNMP intégré à VMware ne montre pas les données dans leur intégralité, et affiche le message d'erreur : aucune réponse de l'hôte.

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

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

Gestion des machines virtuelles

  • Il se peut que le pointeur de la souris ne puisse pas sortir d'une machine virtuelle Windows Server 2012 R2 et Windows 8.1 après l'installation de VMware Tools*
    Lorsque vous installez VMware Tools sur une machine virtuelle Windows Server 2012 R2 et Windows 8.1, il se peut que le pointeur de la souris ne puisse pas sortir de la machine virtuelle. Ce problème se produit lorsque vous configurez un contrôleur USB 2.0 avant d'installer VMware Tools.

    Solution : Définissez l'option de configuration suivante dans le fichier .vmx :
    mouse.vusb.enable = "FALSE"

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

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

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

    Solution : Aucune

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

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

     

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

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

    Solution :Aucune.

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

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

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

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

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

    Solution : Aucune

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

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

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

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

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

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

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

     

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

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

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

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

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

    Solution : Installez VMware Tools manuellement.

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

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

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

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

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

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

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

     

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

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

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

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

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

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

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

     

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

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

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

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

Système d'exploitation client

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

    Solution : Aucune

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

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

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

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

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

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

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

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

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

      Solution : Aucune.

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

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

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