VMware ESXi 5.1 Update 2 | 16 janvier 2014 | Build 1483097

Dernière mise à jour : 24 juillet 2014

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

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

Cette version de VMware ESXi contient les améliorations suivantes :

  • Prise en charge de systèmes d'exploitation clients supplémentaires Cette version met à jour la prise en charge de nombreux systèmes d'exploitation clients.
    Pour obtenir la liste complète des systèmes d'exploitation clients pris en charge avec cette version, reportez-vous au Guide de compatibilité VMware.

  • Problèmes résolus Cette version corrige également divers bogues documentés dans la section Problèmes résolus.

Versions antérieures d'ESXi 5.1

Les fonctions et problèmes connus d'ESXi 5.1 sont décrits dans les notes de mise à jour de chaque version. Pour afficher les notes de mise à jour des versions précédentes d'ESXi 5.1, consultez les

Internationalisation

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

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

Compatibilité et installation

Compatibilité des versions ESXi, vCenter Server et vSphere Web 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 Web 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 Client et vSphere Web Client sont empaquetés avec vCenter Server et le fichier ZIP contenant 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

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

Compatibilité matérielle pour ESXi

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

La liste des processeurs pris en charge a été élargie dans cette version. Pour déterminer les processeurs compatibles avec cette version, reportez-vous au 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 ESXi 5.1 Update 2, consultez les informations sur ESXi 5.1 Update 2 du Guide de compatibilité de VMware.

Avec vSphere 5.1, des modifications des niveaux de prise en charge d'anciens systèmes d'exploitation ont été introduites. Pour connaître les descriptions de chaque niveau de prise en charge, reportez-vous à l' Article 2015161 de la base de connaissances. Le Guide de compatibilité de VMware fournit des informations détaillées sur la prise en charge de toutes les versions des systèmes d'exploitation et des produits VMware.

Les versions suivantes des systèmes d'exploitation qui ne sont plus prises en charge par leurs éditeurs respectifs sont abandonnées. Les prochaines versions de vSphere ne prendront pas en charge ces systèmes d'exploitation clients, bien que vSphere 5.1 Update 2 les prenne en charge.

  • Windows NT
  • Toutes les versions de Windows et DOS 16 bits (Windows 98, Windows 95, Windows 3.1)
  • Debian 4.0 et 5.0
  • Red Hat Enterprise Linux 2.1
  • SUSE Linux Enterprise 8
  • SUSE Linux Enterprise 9 antérieure au SP4
  • SUSE Linux Enterprise 10 antérieure au SP3
  • SUSE Linux Enterprise 11 antérieure au SP1
  • Ubuntu 8.04, 8.10, 9.04, 9.10 et 10.10
  • Toutes les versions de Novell Netware
  • Toutes les versions d'IBM OS/2

 

Compatibilité des machines virtuelles pour ESXi

Les machines virtuelles compatibles avec ESX 3.x et les versions ultérieures (version matérielle 4)sont prises en charge par ESXi 5.1 Update 2. Les machines virtuelles compatibles avec ESX 2.x et les versions ultérieures (version matérielle 3) ne sont plus prises en charge. Pour utiliser ces machines virtuelles sur ESXi 5.1 Update 2, effectuez une mise à niveau de la compatibilité de la machine virtuelle. 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.

Bien que les installations soient simples, plusieurs étapes de configuration ultérieures sont indispensables. Lisez tout particulièrement ce qui suit :

Migration de solutions tierces

Vous ne pouvez pas migrer directement des solutions tierces installées sur un hôte ESX ou ESXi dans le cadre de la mise à niveau d'un hôte. Les modifications architecturales entre ESXi 5.0 et ESXi 5.1 provoquent la perte des composants tiers et peuvent rendre le système instable. Pour effectuer ces migrations, vous pouvez créer un fichier ISO personnalisé avec Image Builder. Pour plus d'informations sur la mise à niveau avec des personnalisations tierces, voir la documentation Mise à niveau de vSphere. Pour plus d'informations sur l'utilisation d'Image Builder pour créer un fichier ISO personnalisé, voir la documentation Installation et configuration de vSphere.

Mises à niveau et installations non autorisées pour les CPU non pris en charge

vSphere 5.1 Update 2 prend uniquement en charge les CPU avec les jeux d'instructions LAHF et SAHF. Au cours d'une installation ou d'une mise à niveau, le programme d'installation vérifie la compatibilité de la CPU hôte avec vSphere 5.1 Update 2. Si le matériel de votre hôte n'est pas compatible, un écran violet apparaît et affiche un message d'information mentionnant l'incompatibilité, et vous ne pouvez ni installer vSphere 5.1 Update 1 ni effectuer une mise à niveau vers cette version.

Mises à niveau pour cette version

Pour obtenir des instructions sur la mise à niveau de vCenter Server et des hôtes ESX/ESXi, consultez la documentation Mise à niveau de vSphere.

ESXi 5.1 Update 2 propose les outils suivants pour mettre à niveau les hôtes ESX/ESXi :

  • M ise à niveau interactive au moyen d'une image ISO du programme d'installation d'ESXi sur CD-ROM, DVD ou lecteur flash USB. Vous pouvez lancer le programme d'installation d'ESXi 5.1 Update 2 à partir d'un CD-ROM, DVD ou lecteur flash USB afin d'effectuer une mise à niveau interactive. Cette méthode convient à un petit nombre d'hôte.
  • Exécution d'une mise à niveau scriptée. Vous pouvez mettre à niveau ou migrer des hôtes ESX/ESXi 4.x et des hôtes ESXi 5.0.x et ESXi 5.1.x vers ESXi 5.1 Update 2 en appelant un script de mise à jour qui permet d'effectuer une mise à niveau efficace et 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.

  • vSphere Auto Deploy. Si votre hôte ESXi 5.x a été déployé avec vSphere Auto Deploy, vous pouvez utiliser Auto Deploy pour reprovisionner l'hôte en le redémarrant avec un nouveau profil d'image qui contient la mise à niveau d'ESXi.

  • esxcli. Vous pouvez mettre à niveau et appliquer des correctifs aux hôtes ESXi 5.1.x à l'aide de l'utilitaire de ligne de commande esxcli, ce qui peut être fait depuis un dépôt de téléchargement sur vmware.com ou depuis un fichier ZIP téléchargé sur un dépôt préparé par un partenaire de VMware. Vous ne pouvez pas utiliser esxcli pour mettre à niveau des hôtes ESX ou ESXi vers les versions 5.1.x à partir de version d'ESX/ESXi antérieures à la version 5.1.

Chemins d'accès de mise à niveau pris en charge pour la mise à niveau vers ESXi 5.1 Update 2 :

Produits livrables de mise à niveau

Outils de mise à niveau pris en charge

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

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

ESX4.0 Update 3
ESX 4.0 Update 4

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

ESXi 4.0 Update 3
ESXi 4.0 Update 4

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

ESX 4.1 Update 3

 

ESXi 4.1 :
Inclut
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0 :
Inclut
ESXi 5.0 Update 1

ESXi 5.0 Update 2
ESXi 5.0 Update 3

ESXi 5.1
Inclut
ESXi 5.1 Update 1

VMware-VMvisor-Installer-5.1.0.update02-xxxxxxx.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Oui

Oui

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

Non

Non

Non

Non

Oui

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

Non

Oui

Composants en libre accès pour VMware vSphere 5.1 Update 2

Les déclarations de copyright et les licences applicables aux composants logiciels en libre accès distribués dans vSphere 5.1 Update 2 sont accessibles sur http://www.vmware.com/download/open_source.html. 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.

Remarques concernant l'assistance produit

  • vSphere Client. Dans vSphere 5.1, toutes les nouvelles fonctionnalités de vSphere sont uniquement disponibles par l'intermédiaire de vSphere Web Client. Le vSphere Client traditionnel continuera à fonctionner, prenant en charge le même ensemble de fonctions que vSphere 5.0, mais il n'exposera pas les nouvelles fonctionnalités de vSphere 5.1.

    vSphere 5.1 et les mises à jour et versions de correctifs suivantes sont les dernières versions à inclure le vSphere Client traditionnel. Les futures versions majeures de VMware vSphere incluront uniquement l'architecture vSphere Web Client.

    Avec vSphere 5.1, les correctifs de bogue de vSphere Client traditionnel sont limités aux problèmes critiques et aux problèmes de sécurité . Les bogues critiques sont des écarts d'une fonctionnalité spécifique d'un produit qui provoquent des corruptions des données, des pertes de données, des blocages du système ou d'importantes interruptions de l'application cliente lorsqu'il n'existe aucune solution à mettre en œuvre.

  • VMware Toolbox. vSphere 5.1 est la dernière version incluant VMware Toolbox, l'interface utilisateur graphique de VMware Tools. VMware continuera de mettre à jour et de prendre en charge l'interface de ligne de commande (CLI) de Toolbox afin de pouvoir exécuter les fonctions de VMware Tools.

  • Paravirtualisation VMI. vSphere 4.1 était la dernière version à prendre en charge l'interface de paravirtualisation des systèmes d'exploitation clients VMI. Pour des informations sur la migration de machines virtuelles activées pour VMI en vue de leur fonctionnement sur des versions ultérieures de vSphere, reportez-vous à l' Article 1013842 de la base de connaissances.

  • Personnalisation du système d'exploitation client Windows. vSphere 5.1 est la dernière version à prendre en charge la personnalisation des systèmes d'exploitation clients Windows 2000. VMware continuera de prendre en charge la personnalisation des nouvelles versions des clients Windows.

  • Sockets VMCI. Les communications de client à client (de machine virtuelle à machine virtuelle) sont abandonnées dans la version 5.1 de vSphere. Cette fonctionnalité sera supprimée dans la prochaine version majeure. VMware continuera à prendre en charge les communications d'hôte à client.

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 ESXi510-Update02 contient les bulletins individuels suivants :

ESXi510-201401201-UG : Met à jour le fichier vib esx-base d'ESXi 5.1
ESXi510-201401202-UG : Met à jour le fichier vib tools-light d'ESXi 5.1
ESXi510-201401203-UG : Met à jour le fichier vib net-tg3 d'ESXi 5.1
ESXi510-201401204-UG : Met à jour le fichier vib net-e1000e d'ESXi 5.1
ESXi510-201401205-UG : Met à jour le fichier vib scsi-rste d'ESXi 5.1
ESXi510-201401206-UG : Met à jour le fichier vib scsi-mpt2sas d'ESXi 5.1
ESXi510-201401207-UG : Met à jour le fichier vib sata-ata-piix d'ESXi 5.1
ESXi510-201401208-UG : Met à jour le fichier vib sata-ahci d'ESXi 5.1


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

ESXi510-201401101-SG : Met à jour le fichier vib esx-base d'ESXi 5.1
ESXi510-201401102-SG : Met à jour le fichier vib tools-light d'ESXi 5.1
ESXi510-201401103-SG : Met à jour le fichier vib esx-xlibs d'ESXi 5.1

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

ESXi-5.1.0-20140102001-standard
ESXi-5.1.0-20140102001-no-tools

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

ESXi-5.1.0-20140101001s-standard
ESXi-5.1.0-20140101001s-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 :

CIM et API

  • 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 que l'hôte 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.
  • 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.
  • 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 de matériel (sfcdb) s'arrête et le fichier syslogcontient 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.
  • L'action WS-Management GetInstance () peut générer une erreur wsa:DestinationUnreachable sur un serveur ESXi
    L'action WS-Management GetInstance ()sur http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity?InstanceID=46.10000peut générer une erreur wsa:DestinationUnreachablesur certains serveurs ESXi. Le chemin d'accès aux objets OMC_MCFirmwareIdentityn'est pas cohérent pour les opérations CIM gi/ei/einsur 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 ()génère une erreur wsa:DestinationUnreachablesur le serveur ESXi.

    Ce problème est résolu dans cette version.
  • vmklinux_9:ipmi_thread de vmkapimod indique une utilisation de la CPU à cent pour cent pendant une heure
    Dans un hôte ESXi, lors de la lecture de données d'inventaire d'unités remplaçables sur site (FRU) à l'aide de l'outil d'interface intelligente de gestion de plate-forme (IPMI), vmklinux_9:ipmi_threadde vmkapimodindique par erreur une utilisation de la CPU à cent pour cent. Cela est dû au fait que l'outil IPMI utilise la commande Read FRU Dataplusieurs fois pour lire les données d'inventaire.

    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.
  • Impossible d'effacer le journal d'événements système (SEL) de l'interface intelligente de gestion de plate-forme (IPMI) sur l'hôte ESXi
    Le journal d'événements système d'IPMI de l'hôte n'est pas effacé dans un environnement de clusters. Pour résoudre ce problème, ajoutez une nouvelle prise en charge de l'interface de ligne de commande pour effacer le journal d'événements système (SEL) de l'interface intelligente de gestion de plate-forme (IPMI).

    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 du processus sfcb-hhrc et le redémarrage du processus sfcbd. Le fichier syslog peut 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.
  • Impossible de désactiver les chiffrements faibles sur le port CIM 5989
    Pour désactiver les algorithmes CBC (cipher block chaining) pour la conformité PCI (Payment Card Indusry), vous devrez peut-être désactiver les chiffrements faibles sur le port CIM  5989. Cela n'est pas autorisé.  

    Ce problème est résolu dans cette version. Vous pouvez mettre à jour la configuration dans le fichier sfcb.cfg afin de désactiver les chiffrements faibles à l'aide des commandes suivantes :
    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart
  • L'hôte ESXi échoue avec une erreur sfcb-CIMXML-Pro-zdump
    L'hôte ESXi échoue avec une erreur sfcb-CIMXML-Pro-zdump, lorsque le sous-processus sfcb pour le traitement httpappelle par erreur atexit et prend fin après une commande fork.

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

Divers

  • Certaines applications 3D affichent une géométrie mal positionnée lorsque la prise en charge 3D est activée sur des machines virtuelles Windows 7 ou Windows 8
    Certaines applications 3D affichent une géométrie mal positionnée sur une machine virtuelle Windows 7 ou Windows 8 si l'option Activer la prise en charge 3D est sélectionnée.

    Ce problème est résolu dans cette version.
  • Netlogond peut cesser de répondre et l'hôte ESXi peut perdre la fonction Active Directory
    Netlogond peut consommer beaucoup de mémoire 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 fonctionnalité Active Directory.

    Ce problème est résolu dans cette version.
  • La commande snmpwalk pour un OID snmp spécifique échoue
    Lorsque vous exécutez la commande snmpwalkpour ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10, un message d'erreur semblable au message suivant s'affiche :

    Il n'existe actuellement aucune instance comparable sur cet OID pour ifHCOutOctets 1.3.6.1.2.1.31.1.1.1.10

    Ce problème est résolu dans cette version.
  • Le pilote vSocket exécuté sur un hôte ESXi avec vShield Endpoint peut subir un blocage
    Le pilote vSocket peut subir un blocage sur une machine virtuelle Windows exécutée sur un hôte ESXi avec vShield Endpoint. Un écran de diagnostic bleu s'affiche avec le journal suivant :
    esx-<host_name>-2013-07-01--09.54/vmfs/volumes/50477c5b-d5ad9a53-8e9c-047d7ba55d90/B15E030S/vmware.log:
    2013-06-27T20:44:05.812Z| vcpu-0| TOOLS installed legacy version 8384, available legacy version 8389
    2013-06-27T20:44:05.813Z| vcpu-0| Guest: toolbox: Version : build-515842
    ...
    2013-06-28T20:38:16.923Z| vcpu-1| Ethernet1 MAC Address: 00:50:56:bf:73:52
    2013-06-28T20:38:16.923Z| vcpu-0| Ethernet0 MAC Address: 00:50:56:bf:73:51
    2013-06-28T20:38:16.927Z| vcpu-1| Ethernet2 MAC Address: 00:50:56:bf:73:53
    2013-06-28T20:39:16.930Z| vcpu-0| Guest: vfile: vf-AUDIT: VFileAuditSvmConnectivity : Lost connectivity to SVM, irpStatus: 0xc0000001 ## disconnect SecureVM
    2013-06-28T20:41:06.185Z| vmx| GuestRpcSendTimedOut: message to toolbox timed out.
    2013-06-28T20:41:06.186Z| vmx| Vix: [4304191 guestCommands.c:2194]: Error VIX_E_TOOLS_NOT_RUNNING in VMAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest
    2013-06-28T20:48:28.341Z| mks| MKS disabling SVGA
    2013-06-28T20:48:34.346Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 30 '
    2013-06-28T20:48:43.349Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 35 '
    2013-06-28T20:48:52.353Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 40 '
    2013-06-28T20:49:01.357Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 45 '
    2013-06-28T20:49:09.360Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 50 '
    2013-06-28T20:49:19.366Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 70 '
    2013-06-28T20:49:28.368Z| mks| WinBSOD: (30) `Dumping physical memory to disk: 80


    Ce problème est résolu dans cette version.
  • Impossible de restaurer vShield et d'autres composants
    vShield et d'autres composants risquent de ne pas se restaurer lorsque vous annulez l'installation.

    Ce problème est résolu dans cette version.
  • La machine virtuelle ne répond plus en raison d'une erreur signal 11 lors de l'exécution d'un code SVGA
    La machine virtuelle ne répond plus en raison d'une erreur signal 11, lors de l'exécution de code SVGA dans svga2_map_surface.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi échoue car des milliers de fichiers .png à 0 octet ne sont pas effacés du dossier /tmp
    L'hôte ESXi échoue car des milliers de fichiers .pngà 0 octet ne sont pas effacés du dossier /tmp. Cela se produit car une fonction utilitaire d'image ne parvient pas à effacer les fichiers tempFileName de vCloud Director. La suppression des fichiers .pngdu dossier temprésout ce problème.

    Ce problème est résolu dans cette version.
  • L'hôte peut cesser de répondre et générer un vidage hostd-worker
    Après le retrait du disque dur et une tentative de récupération des dernières informations sur l'hôte, l'hôte ESXi 5.1 peut cesser de répondre et générer un vidage hostd-worker.

    Ce problème est résolu dans cette version.
  • Impossible de créer des machines virtuelles sur une banque de données vSphere Storage Appliance montée à distance
    Un hôte ESXi créant des machines virtuelles sur une banque de données VSA montée à distance peut cesser de répondre. Cet incident est dû au fait que le plug-in VSA NAS ne gère pas correctement les erreurs réseau.

    Ce problème se produit en raison d'erreurs de communication et parce que la fonction sous-jacente renvoie un pointeur NULL au plug-in VSA NSA.

    Ce problème est résolu dans cette version.
  • Pendant des réinitialisations de cibles, lsilogic d'une machine virtuelle attend des commandes en provenance de toutes les cibles
    Lorsque l'adaptateur virtuel lsilogic effectue une réinitialisation de cibles, il attend des commandes pour toutes les cibles sur l'adaptateur. La réinitialisation de cibles bloque ainsi la machine virtuelle pendant une période anormalement longue.

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

Mise en réseau

  • Plusieurs hôtes ESXi 5.1 peuvent ne plus répondre de façon intermittente lorsque la surveillance NetFlow est activée sur un groupe de ports distribués
    Si la surveillance NetFlow est activée sur un groupe de ports distribués, la fonction IPFIX (Internet Protocol Flow Information Export) est utilisée pour surveiller le trafic du commutateur. Ue condition de concurrence peut se produire dans la fonction de filtre IPFIX lorsque des enregistrements disposant de la même clé coexistent dans la table de hachage ; les hôtes ESXi cessent alors de répondre avec une trace de débogage semblable à celle-ci :

    cpu8:42450)Panic: 766: Panic from another CPU (cpu 8, world 42450): ip=0x41801d47b266:
    #GP Exception 13 in world 42450:vmm0:Datacen @ 0x41801d4b7aaf
    cpu8:42450)Backtrace for current CPU #8, worldID=42450, ebp=0x41221749b390
    cpu8:42450)0x41221749b390:[0x41801d4b7aaf]vmk_SPLock@vmkernel#nover+0x12 stack: 0x41221749b3f0, 0xe00000000000
    cpu8:42450)0x41221749b4a0:[0x41801db01409]IpfixFilterPacket@ # +0x7e8 stack: 0x4100102205c0, 0x1, 0x
    cpu8:42450)0x41221749b4e0:[0x41801db01f36]IpfixFilter@ # +0x41 stack: 0x41801db01458, 0x4100101a2e58


    Ce problème est résolu dans cette version.
  • Les contrôleurs USB perdent leur configuration comme périphériques relais d'E/S DirectPath lorsque les hôtes ESXi redémarrent
    Si des contrôleurs USB sont ajoutés comme périphériques relais pour des machines virtuelles configurées avec DirectPath et si l'hôte exécutant la machine virtuelle redémarre, les contrôleurs USB perdent leur statut de relais et ne sont plus disponibles pour un accès direct aux machines virtuelles.

    Ce problème est résolu dans cette version.
  • Il se peut que l'adaptateur VMXNET 3 ne réussisse pas à se charger dans Windows Server 2012 avec une CPU virtuelle (VCPU) 64 voies
    Il se peut que l'adaptateur VMXNET 3 ne réussisse pas à se charger dans Windows Server 2012 avec une CPU virtuelle (VCPU) 64 voies après le redémarrage.

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

  • L'utilitaire tcpdump-uw peut uniquement capturer des paquets d'une taille inférieure à 8 138 octets
    L'utilitaire de capture de trames tcpdump-uw intégré à ESXi peut uniquement capturer des paquets d'une taille inférieure à 8 138 octets. Ce problème se produit en raison de la présence d'un tampon de socket dont la taille est définise sur 8 Ko dans la mise en œuvre VMware de tcpdump-uw. Le tampon de socket est défini sur 8 192 octets et environ 54 octets sont requis pour les données de contrôle, ce qui laisse une capacité de capture maximale de 8 138 octets.

    La taille de tampon par défaut est augmentée à 64 Ko pour résoudre ce problème.
  • La carte d'interface réseau de gestion non-Vmk0 utilise par défaut Vmk0 après la mise à niveau d'ESXi 5.0 vers ESXi 5.1
    Si une vmknic non-vmk0 est utilisée pour l'interface de gestion sur ESXi 5.0 et que vous mettez à niveau ESXi 5.0 vers ESXi 5.1, l'interface de gestion utilise par défaut vmk0 qui est la première vmknic créée après redémarrage. Cela n'est pas correct.

    Ce problème est résolu dans cette version.
  • Une perte de paquets réseau est signalée par erreur dans esxtop entre deux machines virtuelles sur le même hôte ESXi et vSwitch
    Lorsque deux machines virtuelles sont configurées avec un pilote e1000 sur le même vSwitch sur un hôte, le trafic réseau entre les deux machines virtuelles peut signaler un rejet de paquets significatif dans esxtop. Cela se produit car des paquets fractionnés ne sont pas pris en compte durant le signalement, lorsque vous activez TSO à partir du système invité.

    Ce problème est résolu dans cette version.
  • Les commandes Linux, ip link ou ip addr, peuvent afficher l'état de liaison des adaptateurs VMXNET3 comme étant Unknown au lieu de Up
    Lorsque vous créez des adaptateurs VMXNET3 sur le système d'exploitation invité, les commandes Linux, ip link ou ip addr, peuvent afficher l'état de liaison comme étant Unknown au lieu de Up. Ce problème se produit lorsque l'état de liaison par défaut des adaptateurs est défini sur le mode carrier ok, ce qui explique pourquoi operstate ne peut pas être mis à jour.

    Ce problème est résolu dans cette version en définissant l'état de liaison par défaut des adaptateurs sur le mode no carrier.
  • Les machines virtuelles disposant du système d'exploitation invité Solaris 10 et des pilotes VMXNET3 affichent des messages de journaux overfragmented sur la console
    Lorsque vous installez VMware Tools sur une machine virtuelle Solaris 10 et créez un périphérique VMXNET3 sur le système d'exploitation invité, des messages de journaux semblables aux messages suivants s'affichent sur la console de la machine virtuelle :
    Apr 3 22:44:54 daxa020z last message repeated 274 times Apr 3 22:45:00 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 22:51:35 daxa020z last message repeated 399 times
    Apr 3 22:51:40 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 22:58:12 daxa020z last message repeated 398 times
    Apr 3 22:58:20 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)
    Apr 3 23:04:53 daxa020z last message repeated 393 times
    Apr 3 23:05:00 daxa020z vmxnet3s: [ID 450982 kern.notice] vmxnet3s:0: overfragmented mp (16)

    Ce problème est résolu dans cette version.
  • L'obtention de l'adresse MAC permanente pour une carte réseau VMXNET3 risque d'é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 supérieure à 2.6.23, l'adresse MAC renvoyée ne contient que des zéros.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi 5.x disposant de machines virtuelles utilisant un adaptateur virtuel E1000 ou E1000e échoue avec un écran de diagnostic violet
    Un hôte ESXi obtient un écran de diagnostic violet signalant des erreurs pour E1000PollRxRing et E1000DevRx lorsque le tampon rxRing est saturé et que l'anneau Rx maximal est défini sur une valeur supérieure à 2. Le paquet Rx suivant traité par le deuxième anneau est NULL, ce qui provoque une erreur de traitement.

    L'écran de diagnostic violet ou la trace de débogage contient des entrées semblables à celles-ci :

    @BlueScreen: #PF Exception 14 in world 63406:vmast.63405 IP 0x41801cd9c266 addr 0x0
    PTEs:0x8442d5027;0x383f35027;0x0;
    Code start: 0x41801cc00000 VMK uptime: 1:08:27:56.829
    0x41229eb9b590:[0x41801cd9c266]E1000PollRxRing@vmkernel#nover+0xdb9 stack: 0x410015264580
    0x41229eb9b600:[0x41801cd9fc73]E1000DevRx@vmkernel#nover+0x18a stack: 0x41229eb9b630
    0x41229eb9b6a0:[0x41801cd3ced0]IOChain_Resume@vmkernel#nover+0x247 stack: 0x41229eb9b6e0
    0x41229eb9b6f0:[0x41801cd2c0e4]PortOutput@vmkernel#nover+0xe3 stack: 0x410012375940
    0x41229eb9b750:[0x41801d1e476f]EtherswitchForwardLeafPortsQuick@ # +0xd6 stack: 0x31200f9
    0x41229eb9b950:[0x41801d1e5fd8]EtherswitchPortDispatch@ # +0x13bb stack: 0x412200000015
    0x41229eb9b9c0:[0x41801cd2b2c7]Port_InputResume@vmkernel#nover+0x146 stack: 0x412445c34cc0
    0x41229eb9ba10:[0x41801cd2ca42]Port_Input_Committed@vmkernel#nover+0x29 stack: 0x41001203aa01
    0x41229eb9ba70:[0x41801cd99a05]E1000DevAsyncTx@vmkernel#nover+0x190 stack: 0x41229eb9bab0
    0x41229eb9bae0:[0x41801cd51813]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0x2
    0x41229eb9bc60:[0x41801cd0b21b]WorldletProcessQueue@vmkernel#nover+0x486 stack: 0x41229eb9bd10
    0x41229eb9bca0:[0x41801cd0b895]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x10041229eb9bd20
    0x41229eb9bd20:[0x41801cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x41229eb9be20
    0x41229eb9be20:[0x41801cdbc9bc]CpuSchedIdleLoopInt@vmkernel#nover+0x13b stack: 0x29eb9bfa0
    0x41229eb9bf10:[0x41801cdc4c1f]CpuSchedDispatch@vmkernel#nover+0xabe stack: 0x0
    0x41229eb9bf80:[0x41801cdc5f4f]CpuSchedWait@vmkernel#nover+0x242 stack: 0x412200000000
    0x41229eb9bfa0:[0x41801cdc659e]CpuSched_Wait@vmkernel#nover+0x1d stack: 0x41229eb9bff0
    0x41229eb9bff0:[0x41801ccb1a3a]VmAssistantProcessTask@vmkernel#nover+0x445 stack: 0x0
    0x41229eb9bff8:[0x0] stack: 0x0

    Ce problème est résolu dans cette version.
  • Les machines virtuelles disposant d'une carte réseau e1000 peuvent échouer lorsqu'elles sont suspendues
    La machine virtuelle peut échouer et afficher des messages d'erreur dans un fichier vmware.logsemblables aux messages suivants lorsque le système d'exploitation invité disposant du pilote de la carte réseau e1000 est suspendu :

    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: Msg_Post: Error
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-08-02T05:28:48Z[+11.453]| vcpu-1| I120+ 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.
  • L'adresse IP affichée sur DCUI change lors d'une réinitialisation lorsque le trafic de gestion est activé sur plusieurs ports vmkernel
    Lorsque vous réinitialisez un réseau de gestion dans lequel le trafic de gestion est activé sur plusieurs ports vmkernel, l'adresse IP affichée sur l'interface DCUI (Direct Console User Interface) change.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi affiche un écran de diagnostic violet avec l'erreur : #PF Exception 14 in world 10669:vmm1:TREND_M IP
    Les hôtes ESXi disposant du module DvFilterpeuvent afficher un écran de diagnostic violet. Une trace de débogage semblable à la trace suivante s'affiche :

    2013-07-18T06:41:39.699Z cpu12:10669)0x412266b5bbe8:[0x41800d50b532]DVFilterDispatchMessage@com.vmware.vmkapi#v2_1_0_0+0x92d stack: 0x10
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bc68:[0x41800d505521]DVFilterCommBHDispatch@com.vmware.vmkapi#v2_1_0_0+0x394 stack: 0x100
    2013-07-18T06:41:39.700Z cpu12:10669)0x412266b5bce8:[0x41800cc2083a]BH_Check@vmkernel#nover+0x185 stack: 0x412266b5bde8, 0x412266b5bd88,

    Ce problème est résolu dans cette version.
  • Les ports VDS (vSphere Distributed Switch) inutilisés ne sont pas effacés du répertoire .dvsData sur les banques de données
    Pendant une opération vMotion d'une machine virtuelle disposant d'une vNIC connectée à VDS, les fichiers de port de l'hôte source VMotion ne sont pas effacés dans le répertoire .dvsDatamême après un certain temps.

    Ce problème est résolu dans cette version.
  • Le pilote de l'interface réseau Intel e1000e peut cesser de répondre sur le trafic reçu (RX).
    Le pilote de l'interface réseau Intel e1000e peut cesser de répondre sur le trafic reçu (RX).

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

  • Un hôte ESXi peut échouer avec un écran de diagnostic violet en raison d'un conflit entre deux processus DVFilter
    Si deux processus de filtre DVF tentent de gérer simultanément une variable de configuration unique, alors qu'un processus libère la configuration de filtre et que l'autre processus tente de la verrouiller, cela peut provoquer une panne d'hôte ESXi.

    Ce problème est résolu dans cette version.
  • La valeur renvoyée de net.throughput.usage dans le diagramme de performances de vCenter et dans vmkernel sont contradictoires
    Dans le diagramme de performances de vCenter, la valeur associée net.throughput.usageest indiquée en kilo-octets, alors que la même valeur est renvoyée en octets dans vmkernel. Cela entraîne une représentation incorrecte des valeurs dans le diagramme de performances de vCenter.

    Ce problème est résolu dans cette version.
  • Les hôtes ESXi peuvent ne plus répondre lorsque la fonction L2Echo ne peut pas gérer le trafic réseau
    Lorsque la fonction de vérification de l'intégrité du réseau est activée, la fonction L2Echo peut ne pas être en mesure de gérer un niveau élevé de trafic réseau et les hôtes ESXi peuvent arrêter de répondre et afficher un écran de diagnostic violet et un suivi arrière semblable à celui-ci :

    cpu4:8196)@BlueScreen: PCPU 1: no heartbeat (2/2 IPIs received)
    cpu4:8196)Code start: 0x418024600000 VMK uptime: 44:20:54:02.516
    cpu4:8196)Saved backtrace from: pcpu 1 Heartbeat NMI
    cpu4:8196)0x41220781b480:[0x41802468ded2]SP_WaitLockIRQ@vmkernel#nover+0x199 stack: 0x3b
    cpu4:8196)0x41220781b4a0:[0x4180247f0253]Sched_TreeLockMemAdmit@vmkernel#nover+0x5e stack: 0x20
    cpu4:8196)0x41220781b4c0:[0x4180247d0100]MemSched_ConsumeManagedKernelMemory@vmkernel#nover+0x1b stack: 0x0
    cpu4:8196)0x41220781b500:[0x418024806ac5]SchedKmem_Alloc@vmkernel#nover+0x40 stack: 0x41220781b690
    ...
    cpu4:8196)0x41220781bbb0:[0x4180247a0b13]vmk_PortOutput@vmkernel#nover+0x4a stack: 0x100
    cpu4:8196)0x41220781bc20:[0x418024c65fb2]L2EchoSendPkt@com.vmware.net.healthchk#1.0.0.0+0x85 stack: 0x4100000
    cpu4:8196)0x41220781bcf0:[0x418024c6648e]L2EchoSendPort@com.vmware.net.healthchk#1.0.0.0+0x4b1 stack: 0x0
    cpu4:8196)0x41220781bfa0:[0x418024c685d9]L2EchoRxWorldFn@com.vmware.net.healthchk#1.0.0.0+0x7f8 stack: 0x4122
    cpu4:8196)0x41220781bff0:[0x4180246b6c8f]vmkWorldFunc@vmkernel#nover+0x52 stack: 0x0


    Ce problème est résolu dans cette version.
  • VMXNET3 se réinitialise souvent lorsque la Mise à l'échelle côté réception (RSS) est activée sur une machine virtuelle
    Lorsque la Mise à l'échelle côté réception (RSS) est activée sur une machine virtuelle, le pilote réseau VMXNET3 se réinitialise souvent, ce qui signifie que la machine virtuelle perd la connexion réseau pendant un bref instant.

    Ce problème est résolu dans cette version. Le pilote réseau VMXNET3 est mis à jour 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 vers la bibliothèque libxml2 corrige 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 des composants X.Org
    La bibliothèque client du système ESXi X Window est mise à jour.

Configuration des serveurs

  • NetApp a demandé une mise à jour à la règle de réclamation SATP qui empêche iSCSI de cesser de répondreNetApp 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.
  • Lorsque vous démarrez à partir d'un réseau SAN (Storage Area Network), 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 réseau SAN, le processus de découverte du périphérique de démarrage peut être plus long. 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.
  • Les tentatives d'application d'un profil d'hôte peuvent échouer lors de la suppression de plusieurs banques de données NFS
    Lorsque vous tentez de supprimer plusieurs banques de données NFS à l'aide de l'option Profil d'hôte, une erreur se produit car une banque de données a peut-être déjà été supprimée.

    Ce problème est résolu dans cette version.
  • Les paramètres Retour arrière et Ordre de basculement de vSwitch ne sont pas copiés sur l'hôte lorsque vous appliquez l'hôte
    Lorsque vous attachez un profil d'hôte à un hôte, les propriétés de vSwitch, telles que Retour arrière et Ordre de basculement, extraites d'un hôte de référence ne sont pas appliquées à l'hôte.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi signale une heure de connexion incorrecte pour ha-eventmgr dans le fichier hostd.log
    L'hôte ESXi peut afficher par erreur l'heure de la dernière connexion pour la racine comme étant 1970 ; ces informations s'affichent pour ha-eventmgrsur le client Web des hôtes ESXi. Dans cette version, l'heure de connexion est calculée en fonction de l'heure système, ce qui résout le problème.

    Ce problème est résolu dans cette version.
  • Impossible de trouver le fichier de sauvegarde state.tgz sur le périphérique de démarrage lors de la tentative de mise à niveau d'un hôte ESXi
    Si vous essayez de mettre à niveau un hôte ESXi à l'aide d'une image ISO, vous ne pourrez peut-être pas trouver le fichier de sauvegarde state.tgz sur le périphérique de démarrage.

     

    Ce problème survient si le fichier de sauvegarde state.tgz n'est pas mis à jour parce que vous n'avez pas arrêté correctement votre machine avant de procéder à la mise à niveau. L'erreur d'exception No such a file s'affiche donc lors de la réinitialisation de la licence ESX.

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

  • Un hôte ESXi échoue avec une erreur de profil d'hôte lors du changement du paramètre de basculement réseau en sondage de balise
    Lors de l'application du profil d'hôte à un hôte ESX, si vous tentez de changer la détection de basculement en sondage de balise, l'hôte ESXi échoue avec un message d'erreur semblable au message suivant :
    Le profil d'hôte associé contient des paramètres de critères de défaillance de carte réseau qui ne peuvent pas être appliqués à l'hôte

    Ce problème est résolu dans cette version.
  • La mise en cache sans état ne met pas à jour un profil d'hôte mis en cache localement
    Si la mise en cache sans état est activée sur l'hôte ESXi 5.1 et que le profil d'hôte est à nouveau appliqué sur l'image mise en cache après avoir apporté des modifications à la configuration, les nouvelles configurations de profil d'hôte ne sont alors pas appliquées.

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

  • Lorsque vous mettez à niveau Esxi 5.0.x vers Esxi 5.1.x, l'hôte perd les banques de données NAS et d'autres configurations
    Lorsque vous mettez à niveau ESX 5.0.x vers ESX 5.1.x à l'aide de vCenter Update Manager, l'hôte ESX perd les entrées de banque de données NAS contenant la chaîne Symantec. Dans cette version, le script est modifié pour supprimer les entrées inutiles des fichiers de configuration pendant la mise à niveau, ce qui résout ce problème.

    Ce problème est résolu dans cette version.
  • L'option bandwidthCap d'un hôte ESXi peut ne pas fonctionner sur le système d'exploitation invité
    Sur un hôte ESXi lorsque la limite de bande passante et la limite de débit sont définies en même temps, il se peut que l'option de régularisation d'E/S ne fonctionne pas sur les machines virtuelles. Cela se produit en raison d'une comparaison logique incorrecte lors de la définition de l'option de régularisation dans le planificateur scsi.

    Ce problème est résolu dans cette version.
  • Lorsque vous interrogez l'hôte ESXi via SNMP, l'hôte signale une valeur moyenne de charge de CPU incorrecte
    Lorsque vous effectuez une interrogation SNMP sur l'hôte ESXi pour obtenir la charge moyenne de la CPU, au lieu de calculer la valeur hrProcessorLoad de la dernière minute, hrProcessorLoad calcule la charge de la CPU de toute la durée de vie. L'hôte signale par conséquent une valeur moyenne de charge de CPU incorrecte.
    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 tentez de récupérer la valeur des compteurs système resourceCpuAllocMax et resourceMemAllocMax sur le système hôte, l'hôte ESXi renvoie des valeurs incorrectes. Ce problème se produit sur un client vSphere connecté à un système serveur vCenter.

    Ce problème est résolu dans cette version.
  • Le profil de l'hôte ESXi signale une défaillance de conformité avec le message d'erreur L'option Annotations.WelcomeMessage ne correspond pas aux critères x
    Chaque fois que vous ajoutez du texte dans Annotations.WelcomeMessage, créez un profil d'hôte ESXi et appliquez le même profil d'hôte à d'autres hôtes, l'autre hôte génère un message d'erreur semblable au message suivant :
    L'option Annotations.WelcomeMessage ne correspond pas aux critères spécifiés
    Ce problème est résolu dans cette version.
  • L'option bandwidthCap d'un hôte ESXi peut ne pas fonctionner sur le système d'exploitation invité
    Sur un hôte ESXi, lorsque la limite de bande passante et la limite de débit sont définies en même temps, il se peut que l'option de régularisation d'E/S ne fonctionne pas sur les machines virtuelles. Cela se produit en raison d'une comparaison logique incorrecte lors de la définition de l'option de régularisation dans le planificateur scsi.

    Ce problème est résolu dans cette version.
  • Plusieurs hôtes ESXi peuvent cesser de répondre lors de l'ajout d'un serveur ESXi à vCenter Server
    Lorsque vous tentez d'ajouter un serveur ESXi à 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.

  • Le décodage de l'état MC5 par l'hôte ESX peut être incorrect
    Des messages d'erreur de contrôleur mémoire peuvent être signalés de manière incorrecte en tant qu'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 mémoire peuvent être signalés de manière incorrecte en tant que messages d'erreur TLB (Translation Look-aside Buffer), erreurs TLB de niveau 2.

    Ce problème est résolu dans cette version.
  • Impossible d'ajouter des autorisations à partir de VI Client à des utilisateurs ou des groupes Active Directory sur un hôte ESXi joint à un domaine Active Directory
    Il se peut que vous ne puissiez pas ajouter d'autorisations à des utilisateurs ou des groupes AD car le nom de domaine n'est pas disponible pour sélection dans le menu déroulant Domaine.


    Ce problème est résolu dans cette version.
  • Interruptions SNMP non reçues sur les hôtes sur lesquels SNMP est activé et lorsque des fournisseurs CIM tiers sont installés sur le serveur
    Lorsque l'état du matériel surveillé change dans un hôte ESXi sur lequel SNMP est activé et que des fournisseurs CIM tiers sont installés sur le serveur, il se peut que vous ne receviez pas d'interruptions SNMP. Des messages semblables aux messages suivant sont consignés dans syslog :

    2013-07-11T05:24:39Z snmpd: to_sr_type: unable to convert varbind type '71'
    2013-07-11T05:24:39Z snmpd: convert_value: unknown SR type value 0
    2013-07-11T05:24:39Z snmpd: parse_varbind: invalid varbind with type 0 and value: '2'
    2013-07-11T05:24:39Z snmpd: forward_notifications: parse file '/var/spool/snmp/1373520279_6_1_3582.trp' failed, ignored

    Ce problème est résolu dans cette version.
  • Lorsque vCenter Server effectue une nouvelle analyse du stockage à l'échelle du cluster, les hôtes ESXi et les machines virtuelles ne répondent plus
    Lorsque vous effectuez certaines opérations qui impliquent directement ou indirectement le système de fichiers de machines virtuelles (VMFS), généralement dans un environnement de clusters ESXi partageant un grand nombre de banques de données VMFS, vous pouvez rencontrer les problèmes suivants :
    • L'hôte ESXi cess de répondre de façon intermittente
    • L'host ESXi est déconnecté de vCenter Server
    • La machine virtuelle cesse de répondre de façon intermittente
    • Les machines virtuelles faisant partie du Service de cluster Microsoft (MSCS) cessent de répondre, ce qui provoque un basculement
    • Des erreurs de communication d'hôte se produisent pendant les tests de récupération de données et de basculement de Site Recovery Manager (SRM)

  • Ce problème est résolu dans cette version.
  • Impossible d'obtenir les données du capteur IPMI
    Lorsque vous exécutez périodiquement la commande run exscli hardware ipmi sdr list, le référentiel de données IPMI peut cesser de répondre.

     

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

  • La journalisation TCP, SSL à distance ne redémarre pas automatiquement après une interruption du réseau
    Un hôte VMware ESXi 5.x configuré avec un journal syslog TCP/SSL distant cesse d'envoyer des journaux syslog au serveur de journaux distant lorsque la connexion réseau au serveur de journaux distant est interrompue, puis restaurée.

    Ce problème est résolu en ajoutant un délai d'expiration de nouvelle tentative réseau par défautet les entrées d'hôte à envoyer à syslog après le délai d'expiration de nouvelle tentative réseau par défaut. La valeur par défaut de Délai de nouvelle tentative réseau par défautest de 180 secondes. La commande esxcli system syslog config set --default-timeout=peut être utilisée pour changer la valeur par défaut.

    Ce problème est résolu dans cette version.
  • Impossible d'accéder à la banque de données VMFS ou à certains fichiers
    Il se peut que vous notiez l'absence de la banque de données du système de fichiers de machine virtuelle (VMFS) dans l'onglet des banques de données de vCenter Server ou un événement semblable à l'événement suivant affiché dans l'onglet Événements :
    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX or At least one corrupt on-disk lock was detected on volume [[Image:prio1.png]] ({2}). Other regions of the volume might be damaged too.

    Le message suivant est consigné dans vmkernel.log:

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") might be damaged on the disk. Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$
    You might also see the following message logged in the vmkernel.log:
    2013-07-24T05:00:43.171Z cpu13:11547)WARNING: Vol3: ValidateFS:2267: XXXXXX/51c27b20-4974c2d8-edad-b8ac6f8710c7: Non-zero generation of VMFS3 volume: 1


    Ce problème est résolu dans cette version.
  • L'hôte ESXi ne répond plus et obtient un écran de diagnostic violet avec l'erreur « PCPU XX n'a pas eu de signal de pulsations »
    L'hôte ESXi peut cesser de répondre au cours de l'opération VMotion avec la trace présentée ci-dessous :
     
    2013-07-18T17:55:06.693Z cpu24:694725)0x4122e7147330:[0x418039b5d12e]Migrate_NiceAllocPage@esx#nover+0x75 stack: 0x4122e7147350
    2013-07-18T17:55:06.694Z cpu24:694725)0x4122e71473d0:[0x418039b5f673]Migrate_HeapCreate@esx#nover+0x1ba stack: 0x4122e714742c
    2013-07-18T17:55:06.694Z cpu24:694725)0x4122e7147460:[0x418039b5a7ef]MigrateInfo_Alloc@esx#nover+0x156 stack: 0x4122e71474f0
    2013-07-18T17:55:06.695Z cpu24:694725)0x4122e7147560:[0x418039b5df17]Migrate_InitMigration@esx#nover+0x1c2 stack: 0xe845962100000001
    ...
    2013-07-18T17:55:07.714Z cpu25:694288)WARNING: Heartbeat: 646: PCPU 27 didn't have a heartbeat for 7 seconds; *may* be locked up.
    2013-07-18T17:55:07.714Z cpu27:694729)ALERT: NMI: 1944: NMI IPI reçu. Was eip(base):ebp:cs


    Cela se produit lors de l'exécution de vMotion sur un hôte présentant une surcharge mémoire.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi échoue avec un écran de diagnostic violet lorsque fdshandle est défini sur null dans la fonction DevFSFileClose
    Lorsque fdshandle est défini sur null alors que les fonctions DevFSFileCloseet DevFSFileResetCommandtentent de changer la valeur de fdshandle en même temps, l'hôte ESXi peut échouer avec un écran de diagnostic violet.

    Ce problème est résolu dans cette version.
  • Le serveur ESXi ne peut pas démarrer lorsque vous activez la fonction TXT en mode BIOS UEFI
    Si vous activez TPM/TXT dans le BIOS système (version 1.41) d'un hôte ESXi, Tboot et l'hôte ESXi risquent de ne pas pouvoir démarrer. Ce problème se produit sur un serveur IBM 3650 M4.

    Ce problème est résolu dans cette version.
  • Un hôte ESXi échoue avec un écran de diagnostic violet lors du traitement de ScsiMidlayerFrame dans SCSIPathTimeoutHandlerFn
    Si vous définissez le temporisateur avant d'initialiser ScsiMidlayerFrameavec l'option vmkCmddans la fonction SCSI, l'hôte ESXi peut échouer avec un écran de diagnostic violet, et un message d'erreur semblable au message suivant peut s'afficher :
    PF14 in world 3045899:PathTaskmgmt IP 0x418003489e86 addr 0x48

    Ce problème est résolu dans cette version.
  • 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
    L'hôte ESXi ne parvient pas à signaler les problèmes de configuration si la partition de vidage mémoire et les services Core Dump ne sont pas configurés. Ce problème de configuration peut être supprimé dans VI Client lorsque vous définissez l'option de configuration avancée UserVars.SuppressCoredumpWarningfollowingsur 1.

    Ce problème est résolu dans cette version.
  • L'application du profil d'hôte avec des paramètres de chemin préféré échoue sur l'hôte de destination avec l'erreur Valeur de chemin non valide
    Configurez Hôte1 avec PSP, définissez-le comme fixe et configurez un chemin préféré, puis extrayez le profil d'Hôte1 et appliquez-le à Hôte2. Pendant la vérification initiale du profil d'Hôte2, le module du plug-in de profil d'hôte peut rencontrer une erreur Valeur de chemin non valide et signaler la valeur du chemin non valide.

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

Stockage

  • La commande Request Sense envoyée à partir d'un système d'exploitation invité ne renvoie pas de données
    Lorsqu'une commande SCSI Request Senseest envoyée à RDM (Raw Device Mapping) en mode physique à partir d'un système d'exploitation invité, les données de détection renvoyées sont parfois NULL (mises à zéro). Le problème ne se produit pas lorsque la commande est envoyée à partir de l'hôte ESXi.

    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 faux messages d'état Device Busy (D:0x8) peuvent être inclus dans les 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 inclus dans les 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.
  • 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 partitions.
  • Valeur de l'espace provisionné pour la banque de données NFS incorrectement calculée générant de fausses alarmes
    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 fausses alarmes peuvent donc être générées.

    Ce problème est résolu dans cette version.
  • Impossible de remettre en ligne les banques de données après la perte permanente d'un périphérique
    Après la perte permanente d'un périphérique (PDL), les banques de données ne peuvent pas être remises en ligne en raison de la présence de descripteurs de fichiers ouverts sur le volume.

    Ce problème est résolu dans cette version.
  • Le chargement du module nfsclient pendant le processus de démarrage d'ESXi provoque l'échec du chargement d'autres modules
    Pendant le processus de démarrage d'ESXi, le chargement du module nfsclient peut maintenir un verrouillage sur le fichier esx.conf pendant une période prolongée en présence d'un retard dans la résolution du nom d'hôte pour des points de montage d'un système de fichiers réseau (NFS). Cela peut causer l'échec d'autres chargements de modules tels que migrate, ipmi, etc.

    Ce problème est résolu dans cette version.
  • Impossible d'accéder à la banque de données VMFS ou à certains fichiers
    Vous pouvez constater l'absence de la banque de données du système de fichiers de machine virtuelle (VMFS) dans l'onglet de banque de données de vCenter Server ou un événement similaire à l'événement suivant affiché dans l'onglet des événements :

    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX or At least one corrupt on-disk lock was detected on volume {1} ({2}). Other regions of the volume might be damaged too.

    Le message de journal suivant figure dans le journal vmkernel :

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") might be damaged on the disk. Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$

    Le message suivant peut également être consigné dans le fichier vmkernel.log :

    2013-07-24T05:00:43.171Z cpu13:11547)WARNING: Vol3: ValidateFS:2267: XXXXXX/51c27b20-4974c2d8-edad-b8ac6f8710c7: Non-zero generation of VMFS3 volume: 1

    Ce problème est résolu dans cette version.
  • Les hôtes ESXi 5.1 peuvent échouer avec un écran de diagnostic violet et des messages d'erreur associés à la fonction DevFSFileClose
    Lorsque plusieurs threads tentent de fermer le même périphérique en même temps, les hôtes ESXi 5.1 peuvent échouer avec un écran de diagnostic violet et une trace de débogage similaire à la trace suivante :
    cpu1:16423)@BlueScreen: #PF Exception 14 in world 16423:helper1-0 IP 0x41801ac50e3e addr 0x18PTEs:0x0;
    cpu1:16423)Code start: 0x41801aa00000 VMK uptime: 0:09:28:51.434
    cpu1:16423)0x4122009dbd70:[0x41801ac50e3e]FDS_CloseDevice@vmkernel#nover+0x9 stack: 0x4122009dbdd0
    cpu1:16423)0x4122009dbdd0:[0x41801ac497b4]DevFSFileClose@vmkernel#nover+0xf7 stack: 0x41000ff3ca98
    cpu1:16423)0x4122009dbe20:[0x41801ac2f701]FSS2CloseFile@vmkernel#nover+0x130 stack: 0x4122009dbe80
    cpu1:16423)0x4122009dbe50:[0x41801ac2f829]FSS2_CloseFile@vmkernel#nover+0xe0 stack: 0x41000fe9a5f0
    cpu1:16423)0x4122009dbe80:[0x41801ac2f89e]FSS_CloseFile@vmkernel#nover+0x31 stack: 0x1
    cpu1:16423)0x4122009dbec0:[0x41801b22d148]CBT_RemoveDev@ # +0x83 stack: 0x41000ff3ca60
    cpu1:16423)0x4122009dbef0:[0x41801ac51a24]FDS_RemoveDev@vmkernel#nover+0xdb stack: 0x4122009dbf60
    cpu1:16423)0x4122009dbf40:[0x41801ac4a188]DevFSUnlinkObj@vmkernel#nover+0xdf stack: 0x0
    cpu1:16423)0x4122009dbf60:[0x41801ac4a2ee]DevFSHelperUnlink@vmkernel#nover+0x51 stack: 0xfffffffffffffff1
    cpu1:16423)0x4122009dbff0:[0x41801aa48418]helpFunc@vmkernel#nover+0x517 stack: 0x0
    cpu1:16423)0x4122009dbff8:[0x0] stack: 0x0
    cpu1:16423)base fs=0x0 gs=0x418040400000 Kgs=0x0
    cpu1:16423)vmkernel 0x0 .data 0x0 .bss 0x0
    cpu1:16423)chardevs 0x41801ae70000 .data 0x417fc0000000 .bss 0x417fc00008a0

    This issue is resolved in this release.
  • La réinitialisation du numéro d'unité logique (LUN) échoue dans la fonction fc_fcp_resp lors du traitement de FCP_RSP_INFO
    Dans un test LUN RESET avec des cibles NetApp, LUN RESET échoue. fc_fcp_resp() n'achève pas la tâche LUN RESET car fc_fcp_resp part du principe que FCP_RSP_INFO compte 8 octets avec le champ réservé de 4 octets ; cependant, dans le cas des cibles NetApp, le FCP_RSP vers LUN RESET dispose uniquement des 4 octets de FCP_RSP_INFO. Cela entraîne l'erreur fc_fcp_resp sans achèvement de la tâche, provoquant éventuellement l'échec de LUN RESET.

    Ce problème est résolu dans cette version.
  • L'utilisateur d'ESXi ne peut pas désactiver Fibre Channel sur Ethernet qui n'a pas de périphérique de démarrage
    Dans un hôte ESX, lorsque vous démarrez à partir d'un réseau SAN Fibre Channel sur Ethernet, l'utilisateur risque de ne pouvoir désactiver FCoE sur aucun port.

    Ce problème est résolu dans cette version.
  • Les modifications apportées au paramètre iSCSI logiciel ne sont pas enregistrées dans le fichier syslog.log
    À partir de cette version, les modifications apportées à la session iSCSI logiciel et les paramètres de connexion sont à présent consignés dans le fichier syslog.log, qui contient également les anciennes et nouvelles valeurs de paramètres.
  • Les tentatives de captures instantanées de machines virtuelles dotées de disques virtuels partagés peuvent échouer lorsqu'Oracle Clusterware est utilisé
    Lorsque l'option de multi-écriture est utilisée sur des disques virtuels partagés avec l'option Oracle Real Application Cluster (RAC) du logiciel Oracle Clusterware, les tentatives de captures instantanées des machines virtuelles risquent d'échouer et les machines virtuelles peuvent s'arrêter. Les fichiers journaux peuvent contenir des entrées similaires aux suivantes :

    Resuming virtual disk scsi1:5 failed. The disk has been modified since a snapshot was taken or the virtual machine was suspended.

    Ce problème peut également se produire avec d'autres logiciels de gestion de cluster.

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

Mise à niveau et installation

  • Échec de la correction des hôtes sur les 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 parvient ni à mettre hors tension ni à suspendre les machines virtuelles 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.

vCenter Server, vSphere Client et vSphere Web Client

  • Un diagramme de performances personnalisé n'offre pas la possibilité d'afficher les statistiques agrégées de disques virtuels pour des objets de machines virtuelles
    Lorsque vous utilisez la mesure de disque virtuel pour afficher des 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.
  • L'onglet Résumé peut afficher des valeurs incorrectes pour l'espace provisionné pour les hôtes avec VAAI NAS*
    Lorsqu'un disque virtuel avec le format Provisionnement statique mis à zéro en différé est créé sur un hôte ESXi avec VAAI NAS, dans la vue Banques de données et clusters de banques de données, l'espace provisionné s'affiche sur l'onglet Résumé peut être le double du stockage provisionné prévu pour le disque virtuel.
    Par exemple, si le stockage provisionné est de 75 Go, l'espace provisionné affiché peut atteindre environ 150 Go.

    Ce problème est résolu dans cette version.
  • L'onglet Résumé peut afficher des valeurs incorrectes pour l'espace provisionné pour les hôtes avec VAAI NAS*
    Lorsqu'un disque virtuel avec le format Provisionnement statique mis à zéro en différé est créé sur un hôte ESXi avec VAAI NAS, dans la vue Banques de données et clusters de banques de données, l'espace provisionné s'affiche sur l'onglet Résumé peut être le double du stockage provisionné prévu pour le disque virtuel.
    Par exemple, si le stockage provisionné est de 75 Go, l'espace provisionné affiché peut atteindre environ 150 Go.

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

Gestion des machines virtuelles

  • Dans une machine virtuelle, l'application WPF affiche certains éléments de manière incorrecte lorsque l'option de rendu logiciel 3D est activée
    Lorsque vous installez une application Windows Presentation Foundation (WPF) sur une machine virtuelle et activez l'option de rendu logiciel 3D, l'application WPF peut afficher certaines images de façon incohérente.

    Ce problème est résolu dans cette version.
  • Le système d'exploitation invité échoue avec le code de vérification de bogue PAGE_FAULT_IN_NONPAGED_AREA pendant l'installation de win2000 Server avec 8 CPU virtuelles ou plus
    Lorsque vous effectuez une installation de Windows 2000 Server sur une machine virtuelle, le système d'exploitation invité échoue avec un écran de diagnostic bleu et le message d'erreur PAGE_FAULT_IN_NONPAGED_AREA. Ce problème est constaté sur une machine virtuelle Windows 2000 disposant de huit CPU virtuelles ou plus.

    Ce problème est résolu dans cette version.
  • La suppression à chaud d'une tâche de disque non permanent partagé prend beaucoup de temps en raison d'une contention de verrouillage du verrou d'écriture sur le disque partagé
    Lorsque vous ajoutez des disques non permanents partagés en lecture seule à une machine virtuelle à l'aide d'API Unidesk, la machine virtuelle peut cesser de répondre. Cela se produit car la machine virtuelle ouvre les disques en lecture seule en mode exclusif.
    Ce problème est résolu dans cette version.

vMotion et Storage vMotion

  • Une sauvegarde incrémentielle peut échouer avec une erreur FileFault pour QueryChangedDiskAreas après le déplacement d'un VMDK dans un autre volume à l'aide de vMotion pour une machine virtuelle compatible sur laquelle CBT est activé
    Sur une machine virtuelle CBT (Changed Block Tracking), lorsque vous exécutez QueryChangedDiskAreas après avoir déplacé un disque de machine virtuelle
    (VMDK) vers un autre volume à l'aide de Storage vMotion, étant donné que les informations CBT sont réinitialisées sans ignorer toutes les références ChangeID, cela peut entraîner 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 = <unset>,
    --> faultCause = (vmodl.MethodFault) null, file =
    --> "/vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> msg = "Error caused by file
    /vmfs/volumes/4ff2b68a-8b657a8e-a151-3cd92b04ecdc/VM/VM.vmdk",
    --> }

    Pour résoudre ce problème, le suivi CBT est désactivé puis réactivé après le déplacement d'un disque de machine virtuelle (VMDK) vers une autre banque de données à l'aide de Storage vMotion, il doit ignorer toutes les références ChangeID et réaliser une sauvegarde complète pour utiliser CBT pour d'autres sauvegardes incrémentielles.

    Ce problème se produit lorsqu'une fonction de bibliothèque réinitialise par erreur la fonction de suivi de changement de disque.

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

VMware HA et Fault Tolerance

  • Impossible d'activer un cluster High Availability après la mise en mode de maintenance d'un hôte spécifique
    Il se peut que vous ne puissiez pas activer un cluster High Availability (HA) après la mise en mode de maintenance d'un hôte du même cluster HA. Ce problème se produit lorsque la valeur du numéro de descripteur inode n'est pas correctement définie dans le système de fichiers root d'ESX (VisorFS) ; par conséquent, les appels de statistiques sur ces inodes échouent.

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

VMware Tools

  • Le programme d'installation de VMware Tools n'installe pas le module vmhgfs lorsque vmci et vsock sont transférés en amont après l'activation de l'installation de vmhgfs
    Si vous tentez d'installer VMware Tools lorsque vmci and vsock sont transférés en amont, le programme d'installation peut ne pas installer le module vmhgfs si vous avez déjà activé son installation ; ce problème se produit sur un système d'exploitation Linux disposant du noyau de version 3.9 ou version ultérieure.

    Ce problème est résolu dans cette version.
  • L'interface de contrôle de machine virtuelle ne parvient pas à se charger sur un noyau Linux 3.9 lorsque VMCI et VSOCK sont transférés en amont
    Si vous exécutez la commande /etc/vmware-tools/service.sh restartpour vérifier des services lorsque vmci et vsock sont transférés en amont et que VMware Tools est installé, l'état de l'interface de communication de machines virtuelles peut indiquer un échec. Ce problème se produit sur un système d'exploitation Linux disposant d'un noyau de version 3.9 ou version ultérieure.

    Ce problème est résolu dans cette version.
  • Des machines virtuelles disposant du système d'exploitation Windows peuvent afficher des messages d'avertissement lorsque vous effectuez une mise à niveau de VMware Tools
    Sur un hôte ESXi 5.1, lorsque vous mettez à niveau VMware Tools vers la version 9.0, les machines virtuelles disposant d'un système d'exploitation Windows peuvent afficher un message d'avertissement semblable au message suivant :

    Impossible d'enregistrer une application de type 2 (signaux) à partir du plug-in unity

    Ce problème est résolu dans cette version.
  • open-vm-tools est désinstallé par le programme d'installation de Linux Tools
    Lorsqu'un utilisateur exécute le programme d'installation de VMware sur vSphere dans un système d'exploitation qui inclut open-vm-tools, open-vm-tools est automatiquement désinstallé et VMware Tools est installé.

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

  • Une machine virtuelle disposant du système d'exploitation Solaris 10 ne répond plus lorsque vous installez VMware Tools à partir d'ESXi 5.1
    Si vous installez VMware à partir d'ESXi 5.1 sur une machine virtuelle disposant du système d'exploitation Solaris 10, la machine virtuelle peut cesser de répondre et afficher un message d'erreur semblable au message suivant :
    Attente du bureau CDE pour démarrer

    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 panne 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 c
    00030: 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 à la règle de filtre. Ce problème est résolu dans cette version.
  • VMware Tools est mis à jour pour fournir des modules préconstruits pour SUSE Linux Enterprise 11 SP3, Oracle Linux 5.x avec les noyaux 2.6.39-200/300/400
     et Oracle Linux 6.x avec les noyaux 2.6.39-200/300/400
  • L'agent de protection de vCenter affiche un message d'avertissement Annulation de l'enregistrement du pilote VSS 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 VMware Workstation, l'agent de protection de vCenter affiche un message d'avertissement Unregistering VSS driverindiquant l'utilisation d'un exécutable non signé. L'inclusion de l'exécutable dans la liste des fichiers copiés dans le dossier d'installation résout ce problème.

    Ce problème est résolu dans cette version.
  • Inclure le pilote de noyau vnetflt.sys et les fichiers associés à vShield MSM pour les outils
    Inclure le pilote de noyau vnetflt.sys et les fichiers associés à vShield MSM pour les outils. Cette inclusion simplifie la modification de plusieurs API du programme d'installation de machine virtuelle en ajoutant des arguments par défaut supplémentaires, lesquels peuvent servir à créer des balises à utiliser pour l'ordonnancement du lancement des services au sein d'un groupe.

    Ce problème est résolu dans cette version.
  • VMware Tools ne parvient pas à démarrer si les pilotes vmci et vsock sont installés avec l'option clobber
    Si vous installez VMware Tools avec l'option --clobber-kernel-modules=vmci,vsock, le service VMware Tools ne parvient pas à démarrer et un message d'erreur semblable au message suivant s'affiche :

    Creating a new initrd boot image for the kernel.
    update-initramfs: Generating /boot/initrd.img-3.9.0-rc2-custom
    vmware-tools-thinprint start/running
    initctl: Job failed to start
    Unable to start services for VMware Tools

    Execution aborted.


    Ce problème est résolu dans cette version. Vous ne pouvez plus installer les pilotes vmci et vsock une fois qu'ils ont été transférés en amont avec des versions du noyau Linux supérieures à la version 3.9.
  • Désinstallation de VMwareTools sur Window Server 2003
    Si vous essayez de désinstaller VMTools sur Windows Server 2003, la machine virtuelle ne parvient pas à désinstaller VMTools et affiche un message d'erreur.

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

Problèmes connus

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

Problèmes de mise à niveau et d'installation

  • Il se peut que des objets d'inventaire ne soient pas visibles après la mise à niveau d'un vCenter Server Appliance configuré avec une base de données Postgres
    Lorsqu'un vCenter Server Appliance configuré avec une base de données Postgres est mis à niveau de la version 5.0 Update 2 vers la version 5.1 Update 1, il est possible que des objets d'inventaire qui existaient avant la mise à niveau, tels que des centres de données, des vDS, etc., ne soient pas visibles. Ce problème se produit lorsque vous utilisez vSphere Web Client pour vous connecter à vCenter Server Appliance.

    Solution : Redémarrez Inventory Service après la mise à niveau de vCenter Server Appliance.

  • Pour l'installation avec état d'Auto Deploy, vous ne pouvez pas utiliser l'argument firstdisk d'ESX sur les systèmes où ESX/ESXi est déjà installé sur le périphérique USB
    Vous configurez le profile d'hôte pour un hôte que vous souhaitez mettre en place pour les installations avec état avec Auto Deploy. Lors de la configuration, vous sélectionnez USB comme type de disque et vous spécifiez esx comme premier argument. ESX/ESXi est actuellement installé sur un périphérique USB de l'hôte. Au lieu d'installer ESXi sur le périphérique USB, Auto Deploy installe ESXi sur le disque local.

    Solution : Aucune.

  • Les cmdlets Copy-DeployRule et Set-DeployRule d'Auto Deploy PowerCLI nécessitent un objet comme entrée
    Lorsque vous exécutez la cmdlet Copy-DeployRuleou Set-DeployRuleet que transmettez un profil d'image ou un nom de profil d'hôte, une erreur se produit.

    Solution : Transmettez l'objet du profil d'image ou du profil d'hôte.

  • L'application d'un profil d'hôte qui est configuré pour utiliser Auto Deploy avec mise en cache sans état échoue si ESX est installé sur le disque sélectionné
    Vous utilisez des profils d'hôte pour configurer Auto Deploy avec la mise en cache sans état activée. Dans le profil d'hôte, vous sélectionnez un disque sur lequel une version d'ESX (pas ESXi) est installée. Lorsque vous appliquez le profil d'hôte, une erreur se produit et le texte suivant apparaît.
    Expecting 2 bootbanks, found 0

    Solution : Supprimez le logiciel ESX du disque, ou sélectionnez un autre disque pour la mise en cache sans état.

  • vSphere Auto Deploy ne fonctionne plus après avoir modifié l'adresse IP de la machine qui héberge le serveur Auto Deploy
    Vous installez Auto Deploy sur une machine différente de vCenter Server et vous modifiez l'adresse IP de la machine qui héberge le serveur Auto Deploy. Les commandes Auto Deploy ne fonctionnent plus après la modification.

    Solution : Redémarrez le service du serveur Auto Deploy.
    net start vmware-autodeploy-waiter
    Si le redémarrage du service ne résout pas le problème, vous devrez peut-être réenregistrer le serveur Auto Deploy. Exécutez la commande suivante en spécifiant toutes les options.
    autodeploy-register.exe -R -a vCenter-IP -p vCenter-Port -u user_name -w password -s setup-file-path

  • Sur HP DL980 G7, les hôtes ESXi ne démarrent pas via Auto Deploy lorsque des NIC intégrées sont utilisées
    Vous ne pouvez pas démarrer un système HP DL980 G7 avec Auto Deploy si le système utilise les NIC intégrés (LOM Netxen) pour le démarrage PXE.

    Solution : Installez une NIC additionnelle approuvée par HP sur l'hôte, par exemple un HP NC3 60T, et utilisez cette NIC pour le démarrage PXE.

  • Une mise à jour en direct avec esxcli échoue avec une erreur VibDownloadError
    Un utilisateur effectue deux mises à jour en séquence, comme suit.

    1. Une mise à jour en direct avec la commande de mise à jour du profil du logiciel esxcli ou de mise à jour de vib esxcli.
    2. Un redémarrage a nécessité une mise à jour.

    La deuxième transaction échoue. La vérification de la signature, qui peut être effectuée uniquement après que le VIB a été téléchargé, constitue un échec courant.

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

    1. Redémarrez l'hôte ESXi pour remettre son état au propre.
    2. Recommencez l'installation en direct.

     

  • L'installation scriptée d'ESXi ne parvient pas à trouver le fichier kickstart (ks) sur un lecteur de CD-ROM lorsqu'aucune NIC n'est connectée à la machine
    Si le fichier kickstart se trouve sur lecteur de CD-ROM dans un système auquel aucune NIC n'est connectée, le programme d'installation affiche ce message d'erreur : Impossible de trouver le fichier kickstart sur le cd-rom avec le chemin d'accès < path_to_ks_file>.

    Solution : Reconnectez les NIC pour établir une connexion réseau, puis relancez l'installation.

  • L'installation scriptée échoue sur le LUN SWFCoE
    Lorsque le programme d'installation d'ESXi appelle l'installation avec le fichier kickstart (ks), tous les LUN FCoE n'ont pas encore été analysés et peuplés au moment où l'installation commence. Cette opération fait échouer l'installation scriptée sur les LUN. Cet échec se produit lorsque le protocole https, httpou ftpest utilisé pour accéder au fichier kickstart.

    Solution : Dans la section %predu fichier kickstart, incluez une veille de deux minutes :
    %pre --interpreter=busybox
    sleep 120

  • Problèmes potentiels lors d'une mise à niveau de vCenter Server sans effectuer de mise à niveau du serveur Auto Deploy
    Lorsque vous mettez vCenter Server à niveau, celui-ci remplace l'agent vSphere HA 5.0 (vmware-fdm) par un nouvel agent sur chaque hôte ESXi. Ce remplacement se produit chaque fois qu'un hôte ESXi redémarre. Si vCenter Server n'est pas disponible, l'hôte ESXi ne peut pas rejoindre de cluster.

    Solution : Si possible, effectuez une mise à niveau du serveur Auto Deploy.
    Si vous ne pouvez pas effectuer de mise à niveau du serveur Auto Deploy, vous pouvez utiliser les cmdlets d'Image Builder PowerCLI inclus dans vSphere PowerCLI pour créer un profil d'image ESXi 5.0 qui inclut le nouveau VIB vmware-fdm. Vous pouvez provisionner vos hôtes avec ce profil d'image.

    1. Ajoutez le dépôt logiciel ESXi 5.0 ainsi que le dépôt logiciel qui contient le nouveau VIB vmware-fdm.
      Add-EsxSoftwareDepot C:\ Path\VMware-Esxi-5.0.0- buildnumber-depot.zip Add-EsxSoftwareDepot http:// vcenter server/vSphere-HA-depot
    2. Clonez le profil d'image existant et ajoutez le VIB vmware-fdm.
      New-EsxImageProfile -CloneProfile "ESXi-5.0.0- buildnumber-standard" -name " Imagename" Add-EsxSoftwarePackage -ImageProfile " ImageName" -SoftwarePackage vmware-fdm
    3. Créez une nouvelle règle qui attribue le nouveau profil d'image à vos hôtes et ajoutez la règle à l'ensemble de règles.
      New-DeployRule -Name " Rule Name" -Item " Image Name" -Pattern " my host pattern" Add-DeployRule -DeployRule " Rule Name"
    4. Effectuez une opération de test et de réparation de conformité pour les hôtes.
      Test-DeployRuleSetCompliance Host_list

     

  • Si la mise en cache sans état est activée et que le serveur Auto Deploy n'est plus disponible, il est possible que l'hôte ne démarre pas automatiquement avec l'image stockée
    Dans certains cas, un hôte configuré pour une mise en cache sans état avec Auto Deploy ne démarre pas automatiquement depuis le disque qui contient l'image stockée si le serveur Auto Deploy n'est plus disponible. Ce problème peut se produire même si le périphérique de démarrage souhaité est le suivant dans l'ordre de démarrage logique. Les conséquences précises dépendent des paramètres du BIOS du fournisseur.

    Solution : Sélectionnez manuellement le disque qui contient l'image en cache comme périphérique de démarrage.

  • Lors de la mise à niveau des hôtes ESXi 5.0 vers ESXi 5.1 avec ESXCLI, les paramètres de journalisation de vMotion et Fault Tolerance (FT) sont perdus
    Sur un hôte ESXi 5.0, vous activez vMotion et FT pour un groupe de ports. Vous mettez à niveau l'hôte en exécutant la commande esxcli software profile update. Pour que la mise à niveau puisse réussir, les paramètres vMotion et les paramètres de connexion pour Fault Tolerance sont remis à leur valeur par défaut, c'est à dire désactivés.

    Solution : Utilisez vSphere Update Manager pour mettre à niveau les hôtes ou remettez manuellement dans vMotion et Fault Tolerance les paramètres appliqués avant la mise à niveau.

Problèmes de mise en réseau
  • Sur un hôte ESXi sur lequel SR-IOV est activé, les machines virtuelles associées aux fonctions virtuelles peuvent ne pas démarrer
    Lorsque SR-IOV est activé sur les hôtes ESXi 5.1 avec les cartes réseau Intel ixgbe et si plusieurs fonctions virtuelles sont activées dans cet environnement, certaines machines virtuelles peuvent ne pas démarrer.
    Des messages semblables à celui-ci s'affichent dans le fichier vmware.log :
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] We will respond on the basis of your support entitlement.

    Solution : Réduisez le nombre de fonctions virtuelles associées à la machine virtuelle affectée et démarrez-la.

  • Le système cesse de répondre pendant le transfert TFTP/HTTP lorsque vous provisionnez ESXi 5.1 ou 5.0 U1 avec Auto Deploy
    Lorsque vous provisionnez ESXi 5.1 ou 5.0 U1 avec Auto Deploy sur Emulex 10GbE NC553i FlexFabric 2 Ports en utilisant le dernier gPXE open-source, le système cesse de répondre pendant le transfert TFTP/HTTP.

    Les contrôleurs Emulex 10GbE PCI-E sont des contrôleurs mappés en mémoire. La pile PXE/UNDI exécutée sur ce contrôleur doit passer du mode réel au mode « big real » pendant le transfert PXE TFTP/HTTP pour programmer les registres spécifiques au périphérique au-dessus de 1 Mo de manière à envoyer et recevoir des paquets sur le réseau. Pendant ce processus, les interruptions de CPU sont activées par erreur, le système cesse alors de répondre lorsque d'autres interruptions de périphériques sont générées pendant le changement de mode du CPU.

    Solution : Mettez à niveau le microprogramme NIC dans la version 4.1.450.7 ou ultérieure.

  • Les changements de nombre de ports d'un commutateur virtuel standard ne prennent pas effet tant que l'hôte n'a pas redémarré
    Lorsque vous modifiez le nombre de ports d'un commutateur virtuel standard, les changements ne prennent pas effet tant que vous n'avez pas redémarré l'hôte. Ceci diffère du fonctionnement d'un commutateur virtuel distribué pour lequel les modifications du nombre de ports prennent effet immédiatement.

    Lorsque vous modifiez le nombre de ports sur un commutateur virtuel standard, assurez-vous que le nombre total de ports sur l'hôte, qu'il s'agisse d'un commutateur standard ou distribué, n'excède pas 4096.

    Solution : Aucune.

  •  

  • L'état d'administration d'une NIC physique n'est pas signalé correctement comme étant désactivé
    Le paramétrage administratif d'une NIC physique en état désactivé n'est pas conforme aux normes IEEE. Lorsqu'une NIC physique est configurée comme étant désactivée avec la commande du commutateur distribué, deux problèmes connus se produisent :

    • ESXi connaît une augmentation du trafic qu'il n'est pas en mesure de gérer et qui gaspille des ressources réseau sur le commutateur physique devant ESXi et dans les ressources d'ESXi même.

    • La NIC se comporte de façon inattendue. Les opérateurs s'attendent à voir la NIC désactivée, mais la NIC est affichée comme étant encore active.

    VMware recommande d'utiliser la commande ESXCLI -n vmnicN de réseau désactivé avec les mises en garde suivantes :
    • Cette commande désactive uniquement le pilote. Elle ne met pas la NIC hors tension. Lorsque la carte réseau physique d'ESXi est vue depuis l'interface de gestion du commutateur physique devant le système ESXi, la liaison montante du commutateur standard semble toujours être active.

    • L'état d'administration d'une NIC n'est pas visible dans ESXCLI ou UI. Lors d'un débogage, vous devez penser à vérifier l'état en examinant /etc/vmware/esx.conf.

    • L'agent SNMP signale l'état d'administration, mais il le signale de façon incorrecte si la NIC a été configurée sur Désactivée si l'état opérationnel a été configuré sur Désactivé auparavant. Il signale correctement l'état d'administration si la NIC a été configurée sur Désactivée lorsque l'état opérationnel était activé.

     

    Solution : Configurez l'état d'administration du commutateur physique devant le système ESXi sur désactivé au lieu d'utiliser la commande du commutateur distribué.

  • Modifications de la prise en charge du pilote Linux
    Les pilotes de périphérique pour les NIC virtuelles VMXNET2 ou VMXNET (flexible) ne sont pas disponibles pour les machines virtuelles qui exécutent la version 3.3 du noyau Linux ou une version ultérieure.

    Solution : Utilisez une NIC virtuelle VMXNET3 ou e1000 pour les machines virtuelles qui exécutent la version 3.3 du noyau Linux ou une version ultérieure.

  • L'allocation de bande passante de vSphere 5.0 Network I/O Control n'est pas distribuée équitablement sur plusieurs liaisons montantes
    Dans vSphere 5.0, si la limite de bande passante réseau est configurée sur un pool de ressources tout en utilisant le contrôle d'E/S réseau, cette limite est appliquée dans les liaisons montantes associées au niveau de l'hôte. Ce plafonnement de la bande passante est mis en œuvre par un algorithme de distribution de jetons qui n'est pas conçu pour distribuer équitablement la bande passante entre plusieurs liaisons montantes.

    Solution : Les limites de vSphere 5.1 Network I/O Control ont été réduites à une base par liaison montante.

  • Le paramètre Longueur du paquet en miroir peut empêcher une session de source de mise en miroir distante de fonctionner
    Lorsque vous configurez une session de source de mise en miroir distante en ayant défini l'option Longueur du paquet en miroir, la destination ne reçoit pas certains paquets en miroir. Cependant, si vous désactivez cette option, les paquets sont à nouveau reçus.
    Si l'option Longueur du paquet en miroir est définie, les paquets dont la taille est supérieure à la longueur spécifiée sont tronqués et les paquets sont rejetés. Un code couche inférieur n'effectue pas de fragmentation et recalcule le total de contrôle des paquets rejetés. Les paquets peuvent être rejetés pour deux raisons :

    • La longueur du paquet en miroir est supérieure à l'unité de transmission maximale (MTU)
      Si le TSO est activé dans votre environnement, les paquets d'origine peuvent être très grands. Après avoir été tronqués par la Longueur du paquet en miroir, ils restent plus grands que la MTU et sont par conséquents rejetés par la NIC physique.

    • Les commutateurs intermédiaires effectuent une vérification L3
      Certains paquets rejetés peuvent avoir une longueur de paquet et un total de contrôle incorrects. Certains commutateurs physiques avancés vérifient les informations L3 et rejettent les paquets non valides. La destination ne reçoit pas les paquets.

    Solution :

    • Si le Déchargement de segmentation TCP (TSO) est activé, désactivez l'option Longueur du paquet en miroir.

    • Vous pouvez activer ou désactiver la vérification L3 sur certains commutateurs, par exemple sur la série de commutateurs 4500 de Cisco. Si ces commutateurs sont utilisés, désactivez la vérification L3. Désactivez l'option Longueur du paquet en miroir pour les commutateurs qui ne peuvent pas être configurés.
  • L'activation de plus de 16 cartes réseau VMkernel provoque un échec de vMotion
    vSphere 5.x a une limite de 16 cartes réseau VMkernel pouvant être activées pour vMotion par hôte. Si vous activez plus de 16 cartes réseau VMkernel pour vMotion sur un hôte donné, les migrations vMotion vers ou depuis cet hôte peuvent échouer. Un message d'erreur dans les journaux de VMkernel indique Refusing request to initialize 17 stream ip entries, le nombre correspondant au nombre de cartes réseau VMkernel que vous avez activées pour vMotion.

    Solution : Désactivez les cartes réseau vMotion VMkernel jusqu'à ce qu'il ne reste que 16 cartes réseau activées pour vMotion.

  • Le vidage de mémoire réseau de vSphere ne fonctionne pas lors de l'utilisation d'un pilote nx_nic dans un environnement VLAN
    Lorsque le vidage de mémoire réseau est configuré sur un hôte qui fait partie d'un VLAN, le vidage de mémoire réseau échoue si la NIC utilise un pilote d'adaptateur Ethernet QLogic Intelligent (nx_nic). Les paquets de vidage de mémoire réseau reçus ne sont pas balisés avec la balise VLAN correcte si l'adaptateur de liaison montante utilise nx_nic.

    Solution : Utilisez un autre adaptateur de liaison montante avec un pilote différent lors de la configuration du vidage de mémoire réseau dans un VLAN.

  • Si le fichier kickstart d'une installation scriptée appelle une NIC qui est déjà utilisée, l'installation échoue
    Si vous utilisez un fichier kickstart pour configurer un réseau de gestion après l'installation, et que vous appelez depuis le fichier kickstart une NIC qui est déjà utilisé, le message d'erreur suivant apparaît : Une erreur sysinfo lors de l'opération a retourné l'état : Occupé. Veuillez consulter le journal de VMkernel pour obtenir des informations détaillées sur cette erreur.

    Cette erreur se produit lorsque vous lancez une installation scriptée sur un système qui comporte deux NIC : une NIC configurée pour SWFCoE/SWiSCSI, et une NIC configurée pour la mise en réseau. Si vous utilisez la NIC réseau pour lancer l'installation scriptée en indiquant netdevice=<nic> ou BOOTIF=<MAC of the NIC> dans les options de démarrage, le fichier kickstart utilise l'autre NIC, netdevice=<nic configured for SWFCoE / SWiSCSI>, dans la ligne de réseau pour configurer le réseau de gestion.

    L'installation (le partitionnement des disques) réussit, mais lorsque le programme d'installation essaye de configurer le réseau de gestion pour l'hôte avec les paramètres réseau fournis dans le fichier kickstart, il échoue car la NIC était déjà utilisée par SWFCoE/SWiSCSI.

    Solution : Utilisez une NIC disponible dans le fichier kickstart pour configurer un réseau de gestion après l'installation.

  • Les machines virtuelles qui exécutent ESX et utilisent également VMXNET3 comme pNIC sont susceptibles de se bloquer
    Les machines virtuelles qui exécutent ESX comme client et utilisent également VMXNET3 comme pNIC sont susceptibles de se bloquer du fait de la prise en charge expérimentale de VMXNET3. La NIC par défaut d'une machine virtuelle ESX est e1000, ce problème survient donc uniquement lorsque vous remplacez la NIC par défaut et que vous sélectionnez VMXNET3 à la place.

    Solution : Utilisez e1000 ou e1000e comme pNIC pour la machine virtuelle ESX.

  • Un message d'erreur apparaît lorsqu'un grand nombre de dvPorts est utilisé
    Lorsque vous mettez la machine virtuelle sous tension avec dvPort sur un hôte ayant un grand nombre de dvPorts en cours d'utilisation, une erreur Out of memoryou Out of resourcesapparaît. Ceci peut également se produire lorsque vous énumérez les commutateurs sur un hôte utilisant une commande esxcli.

    Solution : Augmentez la taille de dvsLargeHeap.

    1. Modifiez l'option de configuration avancée de l'hôte :
      • commande esxcli : esxcfg-advcfg -s /Net/DVSLargeHeapMaxSize 100
      • Centre virtuel : Accédez à la configuration de l'hôte -> panneau Logiciel -> Paramètres avancés -> sous « Net », changez la valeur de DVSLargeHeapMaxSize de 80 à 100.
      • vSphere 5.1 Web Client : Accédez à Gérer les hôtes-> Paramètres -> Paramètres système avancés -> Filtre. Changez la valeur DVSLargeHeapMaxSize de 80 à 100.
    2. Capturez un profil d'hôte depuis l'hôte. Associez le profil à l'hôte et actualisez le fichier de réponses.
    3. Redémarrez l'hôte pour confirmer que la valeur a bien été appliquée.

    Remarque : La valeur maximale pour /Net/DVSLargeHeapMaxSize est 128.

    Veuillez contacter le support VMware si vous rencontrez des problèmes pendant un déploiement important après avoir modifié /Net/DVSLargeHeapMaxSize à 128 et que les journaux système affichent l'un des messages d'erreur suivants :

    Unable to Add Port; Status(bad0006)= Limit exceeded

    Failed to get DVS state from vmkernel Status (bad0014)= Out of memory

  • ESXi échoue avec les NIC BladeEngine-3 10G Emulex (pilote be2net)
    ESXi risque d'échouer sur les systèmes dotés des NIC BladeEngine-3 10G Emulex lorsqu'un pool de réseau associé à vCDNI est configuré avec VMware vCloud Director. Vous devez obtenir d'Emulex un pilote du périphérique à jour lorsque vous configurez un pool de réseau avec ce dispositif.

    Solution : Aucune.

Problèmes de stockage

  • Les LUN RDM se détachent des machines virtuelles qui migrent de la banque de données VMFS vers la banque de données NFS
    Si vous utilisez vSphere Web Client pour migrer les machines virtuelles avec les LUN RDM de la banque de données VMFS vers la banque de données NFS, l'opération de migration se termine sans erreur ou message d'avertissement, mais les LUN RDM se détachent de la machine virtuelle après la migration. Toutefois, l'opération de migration crée un fichier VMDK dont la taille est la même que celle du LUN RDM sur la banque de données NFS, pour remplacer le LUN RDM.
    Si vous utilisez vSphere Client, un message d'erreur approprié s'affiche dans la section compatibilité de l'assistant de migration.

    Solution : Aucune
  • La création d'une banque de données VMFS5 peut échouer lorsque vous utilisez une baie de stockage VMAX/VMAXe EMC Symmetrix
    Si votre hôte est connecté à une baie VMAX/VMAXe, il est possible que vous ne parveniez pas à créer une banque de données VMFS5 sur un LUN présenté par la baie. Si tel est le cas, l'erreur suivante apparaît : Une erreur est survenue pendant la configuration de l'hôte. Cette erreur est due à la portion ATS (VAAI) du microcode Symmetrix Enginuity (VMAX 5875.x) qui fait obstacle à une nouvelle banque de données sur un LUN qui n'a fait l'objet d'aucune écriture jusque là.

    Solution :

    1. Désactivez le blocage de l'accélération matérielle sur l'hôte ESXi.
    2. Créez une banque de données VMFS5.
    3. Réactivez le blocage de l'accélération matérielle sur l'hôte.

    Utilisez les tâches suivantes pour désactiver et réactiver le paramètre de blocage de l'accélération matérielle.

    Dans vSphere Web Client

    1. Accédez à l'hôte dans le navigateur de vSphere Web Client.
    2. Cliquez sur l’onglet Gérer, puis cliquez sur Paramètres.
    3. Dans Système, cliquez sur Paramètres système avancés.
    4. Sélectionnez VMFS3.HardwareAcceleratedLocking et cliquez sur l'icône Modifier.
    5. Modifiez la valeur du paramètre VMFS3.HardwareAcceleratedLocking :
      • 0 désactivé
      • 1 activé

    Dans vSphere Client

    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. Modifiez la valeur du paramètre VMFS3.HardwareAcceleratedLocking :
      • 0 désactivé
      • 1 activé

     

  • Les tentatives de création d'une partition GPT sur un disque vide peuvent échouer lors de l'utilisation de Storagesystem::updateDiskPartitions()
    Vous pouvez utiliser l'API Storagesystem::computeDiskPartitionInfopour récupérer la spécification du disque, puis utiliser la spécification du disque pour nommer le disque et créer une partition avec Storagesystem::updateDiskPartitions(). Toutefois, si le disque est initialement vide et que le format du disque cible est GPT, vos tentatives de création de la partition peuvent échouer.

    Solution : Utilisez alors DatastoreSystem::createVmfsDatastorepour nommer et partitionner un disque vide et créer une banque de données VMFS5.

  •  

  • Les tentatives de création d'une partition de diagnostic sur un disque GPT peuvent échouer
    Si un disque GPT n'a pas de partitions, ou que la portion de fin du disque est vide, il est possible que vous ne parveniez pas à créer une partition de diagnostic sur le disque.

    Solution : Évitez d'utiliser des disques formatés au format GPT pour les partitions de diagnostic. Si vous devez utiliser un disque vide existant au format GPT pour la partition de diagnostic, convertissez ce disque au format MBR.

    1. Créez une banque de données VMFS3 sur le disque.
    2. Supprimer la banque de données.

    Le disque passe du format GPT au format MBR.

     

  • ESXi ne parvient pas à démarrer depuis un LUN FCoE dont la taille est supérieure à 2 To et auquel il est accédé depuis une NIC Intel FCoE
    Lorsque vous installez ESXi sur un LUN de démarrage FCoE dont la taille est supérieure à 2 To et auquel il est accédé depuis une NIC Intel FCoE, l'installation peut réussir. Cependant, lorsque vous essayez de démarrer l'hôte ESXi, le démarrage échoue. Les messages d'erreur suivants apparaissent : ERREUR : Aucune géométrie appropriée pour cette capacité de disque !et ERREUR : Échec de la connexion à un disque configuré !à l'heure du BIOS.

    Solution : N'installez pas ESXi sur un LUN FCoE dont la taille est supérieure à 2 To s'il est connecté à une NIC Intel FCoE configuré pour un démarrage FCoE. Installez ESXi sur un LUN FCoE dont la taille est inférieure à 2 To.

Problèmes de configuration de serveur

 

  • L'application de profils d'hôtes peut échouer lors de l'accès aux dossiers VMFS par l'intermédiaire de la console
    Si un utilisateur accède au dossier de banque de données VMFS avec la console au moment où un profil d'hôte est appliqué à l'hôte, la tâche de correction ou d'application peut échouer. Cet échec peut se produire lorsque la mise en cache sans état est activée sur le profil d'hôte ou si une installation auto deploy a été effectuée.

    Solution : N'accédez pas à la banque de données VMFS par l'intermédiaire de la console lors de la correction du profil d'hôte.

  • Un espace de début blanc dans la bannière de connexion provoque une défaillance de conformité du profil d'hôte
    Lorsque vous modifiez un profil d'hôte et que vous modifiez le texte de l'option de la bannière de connexion (message du jour), mais que vous ajoutez un espace de début blanc dans le texte de la bannière, une erreur de conformité se produit lorsque le profil est appliqué. L'erreur de conformité La bannière de connexion a été modifiéeapparaît.

    Solution : Modifiez le profil d'hôte et supprimez l'espace de début blanc de l'option de règle Bannière de connexion.

  • Le profil d'hôte extrait de l'hôte ESXi 5.0 n'est pas appliqué à l'hôte ESX 5.1 lorsque Active Directory est activé
    Lors de l'application d'un profil d'hôte alors qu'Active Directory est activé, profil extrait d'un hôte ESXi 5.0 vers un hôte ESX 5.1, l'application échoue. Il est possible que la définition de la taille de mémoire maximale pour le pool de ressources système likewise provoque une erreur. Lorsque Active Directory est activé, les services du pool de ressources système likewise consomment davantage de mémoire que la limite de mémoire maximale par défaut pour ESXi 5.0 capturé dans un profil d'hôte ESXi 5.0. Par conséquent, l'application d'un profil d'hôte ESXi 5.0 échoue lors des tentatives de définition de la limite de mémoire maximale vers les niveaux ESXi 5.0.

    Solution : Procédez au choix comme suit :

    • Modifiez manuellement le profil d'hôte pour augmenter la limite de mémoire maximale pour le groupe likewise.
      1. Depuis l'éditeur de profil d'hôte, accédez au dossier du Pool de ressources et affichez host/vim/vmvisor/plugins/likewise.
      2. Modifiez le paramètre Mémoire maximale (Mo) de 20 (ESXi 5.0 par défaut) à 25 (ESXi 5.1 par défaut).
    • Désactivez le sous-profil du groupe likewise. Effectuez l'une des opérations suivantes :
      • Dans vSphere Web Client, modifiez le profil d'hôte et décochez la case du dossier Pool de ressources. Cette action désactive toute gestion du pool de ressources. Vous pouvez la désactiver spécifiquement pour l'élément host/vim/vmvisor/plugins/likewise sous le dossier Pool de ressources.
      • Dans vSphere Client, cliquez avec le bouton droit sur le profil d'hôte et sélectionnez Activer/désactiver une configuration de profil... dans le menu.

     

  • La passerelle de l'hôte est supprimée et des défaillances de conformité se produisent lorsque le profil d'hôte ESXi 5.0.x est réappliqué à l'hôte ESXi 5.1 sans état
    Lorsqu'un profil d'hôte ESXi 5.0.x est appliqué à un hôte ESXi 5.1 nouvellement installé, l'état de conformité du profil est non conforme. Après avoir réappliqué le même profil, il supprime l'IP de la passerelle de l'hôte et l'état de conformité continue à apparaître comme non conforme avec le message d'état IP route configuration doesn't match the specification.

    Solution : Procédez au choix comme suit :

    • Connectez-vous à l'hôte par l'intermédiaire de DCUI et ajoutez manuellement la passerelle par défaut avec la commande esxclisuivante :
      esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network yy.yy.yy.yy
    • Extrayez un nouveau profil d'hôte de l'hôte ESX 5.1 après avoir appliqué une fois le profil d'hôte ESX 5.0. Migrez l'hôte ESX 5.1 vers le nouveau profil d'hôte basé sur ESX 5.1.

     

  • Des erreurs de conformité peuvent se produire après que la mise en cache sans état a été activé sur un disque USB
    Lorsque la mise en cache sans état est activée sur des disques USB sur un profil d'hôte, des erreurs de conformité peuvent se produire après la récupération. Après avoir redémarré l'hôte pour que les modifications corrigées soient appliquées, la mise en cache sans état réussit, mais les défaillances de conformité se poursuivent.

    Solution : Aucune solution de rechange n'est disponible.

  • Les hôtes qui comportent un grand nombre de banques de données expirent lors de l'application d'un profil d'hôte avec la mise en cache sans état activée
    Un hôte qui comporte un grand nombre de banques de données expire lors de l'application d'un profil d'hôte avec la mise en cache sans état activée.

    Solution : Utilisez vSphere Client pour augmenter le délai :

    1. Sélectionnez Administrateur > Paramètres de vCenter Server.
    2. Sélectionnez Paramètres de délai d'expiration.
    3. Définir les valeurs pour Opérations normales et Opérations longues sur 3 600 secondes.

       

  • Impossible d'extraire le profil d'hôte de l'hôte lorsque IPv4 est désactivé sur vmknics
    Si vous supprimez toutes les adresses IPv4 de tous les vmknics, vous ne pouvez pas extraire de profil d'hôte de cet hôte. Cette action affecte surtout les hôtes provisionnés avec auto-deploy, car les profils d'hôte constituent la seule façon d'enregistrer la configuration de l'hôte dans cet environnement.

    Solution : Assignez au moins un vmknic à une adresse IPv4.

  • L'application d'un profil d'hôte échoue lors de l'application d'un profil d'hôte extrait d'un hôte ESXi 4.1 sur un hôte ESXi 5.1
    Si vous avez défini un hôte avec ESXi 4.1, extrayez un profil d'hôte de cet hôte (avec vCenter Server), puis essayez d'attacher le profil à un hôte ESXi 5.1. L'opération échoue lorsque vous tentez d'appliquer le profil. Le message d'erreur suivant peut s'afficher : NTP service turned off.

    Le service NTPD pourrait être actif (en état) même sans fournir de serveur NTP dans /etc/ntp.confpour ESXi 4.1. ESXi 5.1 a besoin d'un serveur NTP explicite pour que le service soit actif.

    Solution : Activez le service NTP en ajoutant un serveur NTP valide dans /etc/ntp.conf, puis redémarrez le démon NTP sur l'hôte 5.1. Confirmez que le service persiste après le redémarrage. Cette action garantit que le service NTP est synchronisé pour l'hôte et le profil qui lui est appliqué.

  • Le profil d'hôte affiche non conforme après que l'application du profil a réussi
    Ce problème se produit lors de l'extraction d'un profil d'hôte depuis un hôte ESXi 5.0 et son application à un hôte ESXi 5.1 qui contient un périphérique SAS local. Même si la correction du profil d'hôte a réussi, la conformité du profil d'hôte affiche qu'il est non conforme.

    Vous pourriez recevoir des messages d'erreur similaires aux suivants :

    • Specification state absent from host: device naa.500000e014ab4f70 Path Selection Policy needs to be set to VMW_PSP_FIXED
    • Specification state absent from host: device naa.500000e014ab4f70 parameters needs to be set to State = on" Queue Full Sample Size = "0" Queue Full Threshold = "0"

     

    Le plugin de stockage du profil d'hôte d'ESXi 5.1 élimine les périphériques SAS locaux pour la configuration des périphériques PSA et NMP, alors qu'ESXi 5.0 contient ces configurations de périphériques. De ce fait, un périphérique manque lors de l'application de l'ancien profil d'hôte sur un hôte plus récent.

    Solution : Modifiez manuellement le profil d'hôte et supprimez les entrées de la configuration des périphériques PSA et NMP pour tous les périphériques SAS locaux. Vous pouvez déterminer si un périphérique est un SAS local en entrant la commande esxcli suivante :
    esxcli storage core device list

    Si la ligne suivante est renvoyée, le périphérique est un SAS local :
    Is Local SAS Device

  • Les services système par défaut démarrent toujours sur les hôtes ESXi provisionnés avec Auto Deploy
    Avec les hôtes provisionnés avec Auto Deploy, la stratégie de démarrage des services dans la section Configuration des services du profil d'hôte associé n'est pas totalement honorée. En particulier, si la valeur de la stratégie de démarrage de l'un des services qui est activé par défaut est off, ce service continue à démarrer au moment du démarrage sur l'hôte ESXi provisionné avec Auto Deploy.

    Solution : Arrêtez manuellement le service après avoir redémarré l'hôte ESXi.

  • La récupération d'informations de VMWARE-VMINFO-MIB ne se déroule pas correctement après un redémarrage de snmpd
    Il est possible que certaines informations de VMWARE-VMINFO-MIB manquent pendant SNMPWalk lorsque vous avez redémarré le démon snmpd avec /etc/init.d/snmpd restartdepuis ESXi Shell.

    Solution : N'utilisez pas /etc/init.d/snmpd restart. Vous devez utiliser la commande esxcli system snmp set --enablepour démarrer ou arrêter le démon SNMP. Si vous avez utilisé /etc/init.d/snmpd restartpour redémarrer snmpd depuis ESXi Shell, redémarrez Hostd, soit depuis DCUI ou avec /etc/init.d/hostd restartdepuis ESXi Shell.

Problèmes vCenter Server et vSphere Client
  • L'activation ou la désactivation de View Storage Accelerator risque de provoquer la perte de connectivité entre les hôtes ESXi et vCenter Server
    Si VMware View est déployé avec vSphere 5.1 et qu'un administrateur View active ou désactive View Storage Accelerator dans un pool de poste de travaille, les hôtes ESXi 5.1 risquent de perdre leur connectivité avec vCenter Server 5.1.

    La fonction View Storage Accelerator est également appelée Content Based Read Caching (cache de lecture basé sur le contenu). Dans la console View 5.1 View Administrator, cette fonction est appelée Host caching (Cache de l'hôte).

    Solution : N'activez ou ne désactivez pas View Storage Accelerator dans les environnements View déployés avec vSphere 5.1.

Problèmes de gestion des machines virtuelles
  • La mise à niveau de la compatibilité de machine virtuelle depuis ESX 3.x et ultérieure (VM version 4) configure de manière incorrecte la carte Flexible de machine virtuelle Windows sur le pilote par défaut du système Windows
    Si vous avez un système d'exploitation client Windows avec une carte réseau Flexible configurée pour le pilote d'adaptateur VMware Accelerated AMD PCnet, lorsque vous mettez à niveau la compatibilité de machine virtuelle depuis ESX 3.x et ultérieure (VM version 4) dans un paramètre de compatibilité ultérieur, par exemple ESXi 4.x et ultérieure (VM version 7),Windows configure la carte flexible sur le pilote par défaut de l'adaptateur Windows AMD PCNET Family PCI Ethernet.
    Cette mauvaise configuration se produit parce que les pilotes VMware Tools ne sont pas signés et Windows sélectionne le pilote Windows signé par défaut. Les paramètres réseau de la carte Flexible qui existaient avant la mise à niveau de la compatibilité sont perdus et la vitesse réseau du NIC passe de 1Gbps à 10Mbps.

    Solution : Configurez les cartes réseau Flexible pour utiliser le pilote VMXNET à partir du système d'exploitation client Windows après avoir mis à niveau la compatibilité de la machine virtuelle. Si votre client est mis à jour avec ESXi5.1 VMware Tools, le pilote VMXNET est installé à l'endroit suivant : C:\Program Files\Common Files\VMware\Drivers\vmxnet\.

  • Lorsque vous installez VMware Tools sur une machine virtuelle et que vous redémarrez, le réseau devient inutilisable
    Sur les machines virtuelles avec le système d'exploitation CentOS 6.3 ou Oracle Linux 6.3, le réseau devient inutilisable après une installation réussie de VMware Tools et le redémarrage de la machine virtuelle. Lorsque vous essayez d'obtenir manuellement l'adresse IP d'un serveur DHCP ou de définir une adresse IP statique depuis la ligne de commande, l'erreur Cannot allocate memoryapparaît.
    Le problème est que la carte réseau Flexible qui est utilisée par défaut n'est pas un bon choix pour ces systèmes d'exploitation.

    Solution : Remplacez la carte réseau Flexible par une carte E1000 ou VMXNET 3 de la manière suivante :

    1. Exécutez la commande vmware-uninstall-tools.plpour désinstaller VMware Tools.
    2. Mettez la machine virtuelle hors tension.
    3. Dans vSphere Web Client, cliquez avec le bouton droit sur la machine virtuelle et sélectionnez Modifier les paramètres.
    4. Cliquez sur Matériel virtuel, puis supprimez la carte réseau actuelle en cliquant sur l'icône Supprimer.
    5. Ajoutez une nouvelle carte réseau, et choisissez une carte de type E1000 ou VMXNET 3.
    6. Mettez la machine virtuelle sous tension.
    7. Réinstallez VMware Tools.

     

  • Les opérations de clonage ou de migration qui impliquent des disques virtuels non VMFS sur ESXi échouent avec une erreur
    Que vous utilisiez la commande vmkfstools ou le client pour effectuer un clonage, une copie ou une migration sur les disques virtuels des formats hébergés, l'opération échoue avec le message d'erreur suivant : The system cannot find the file specified.

    Solution : Pour effectuer un clonage, une copie ou une migration sur les disques virtuels des formats hébergés, vous devez charger le module VMkernel multiextent dans ESXi.

    1. Connectez-vous à ESXi Shell et chargez le module multiextent.
      # vmkload_mod multiextent
    2. Vérifiez si les disques de votre machine virtuelle sont d'un type hébergé. Les disques hébergés se terminent par l'extension -s00x.vmdk.
    3. Convertissez les disques virtuels au format hébergé dans l'un des formats VMFS.
      1. Clonez le disque hébergé source test1.vmdk vers test2.vmdk.
        # vmkfstools -i test1.vmdk test2.vmdk -d zeroedthick|eagerzereodthick|thin
      2. Supprimez le disque hébergé test1.vmdk lorsque le clonage a réussi.
        # vmkfstools -U test1.vmdk
      3. Renommez le disque au format vmfs cloné test2.vmdk en test1.vmdk.
        # vmkfstools -E test2.vmdk test1.vmdk
    4. Déchargez le module multiextent.
      #vmkload_mod -u multiextent

     

  • Une machine virtuelle n'a pas d'adresse IP assignée et ne semble pas opérationnelle
    Ce problème vient d'une requête de réinitialisation LUN exécutée depuis un système d'exploitation client. Ce problème est spécifique de la baie Fibre Channel de l'IBM XIV avec le logiciel FCoE configuré en hôtes ESXi. Les machines virtuelles qui résident sur le LUN ont les problèmes suivants :

    • Aucune adresse IP n'est affectée aux machines virtuelles.
    • Vous ne pouvez mettre les machines virtuelles sous tension ni hors tension.
    • Le curseur de la souris n'est pas visible dans la console. Par conséquent, il n'y a aucun moyen de contrôler ou d'interagir avec la machine virtuelle affectée dans le système d'exploitation client.

     

    Solution : À partir de votre hôte ESXi, réinitialisez le LUN où résident les machines virtuelles posant problème.

    1. Exécutez la commande qui suit pour obtenir les informations du LUN :
      # vmkfstools -P /vmfs/volumes/ DATASTORE_NAME
    2. Recherchez la ligne suivante en sortie afin d'obtenir l'UID du LUN :
      Partitions spanned (on 'lvm'): eui.001738004XXXXXX:1
      eui.001738004XXXXXXest l'UID du périphérique.
    3. Exécutez la commande qui suit pour réinitialiser le LUN :
      # vmkfstools -L lunreset /vmfs/devices/disks/eui.001738004XXXXXX
    4. Si une machine virtuelle ne répondant pas réside sur une banque de données avec des LUN multiples associés, par exemple des extensions ajoutées, réinitialisez le LUN pour toutes les extensions de banque de données.

     

Problèmes de migration
  • Toute tentative d'utilisation de Storage vMotion pour migrer plusieurs machines virtuelles de clones liés échouera
    Cet échec concerne généralement les machines virtuelles de clones liés. Cet échec se produit lorsque la taille des disques delta est de 1 Mo et que la fonction Content Based Read Cache (CBRC) a été activée sur les hôtes ESXi. Le message d'erreur suivant apparaît : La source a détecté que la destination n'a pas pu reprendre ses opérations.

    Solution : Utilisez l'une des méthodes suivantes pour éviter les échecs de Storage vMotion :

    • Utilisez la taille de disque delta 4 Ko.

    • Plutôt que d'utiliser Storage vMotion, migrez les machines virtuelles hors tension vers une nouvelle banque de données.

Problèmes VMware HA et Fault Tolerance
  • Les machines virtuelles tolérantes aux pannes se bloquent lorsqu'elles sont définies pour enregistrer des informations statistiques sur une version beta de vCenter Server
    La fonctionnalité vmx*3 permet aux utilisateurs d'exécuter les statistiques vmx afin de recueillir des statistiques de performances pour le débogage des problèmes de prise en charge. Les statistiques vmx ne sont pas compatibles lorsque Fault Tolerance est activé sur une version beta de vCenter Server.

    Solution : Lors de l'activation de Fault Tolerance, assurez-vous que la machine virtuelle n'est pas configurée pour enregistrer les statistiques sur une version beta de vCenter Server.

Problèmes de matériel supporté
  • L'état PCI Unknown Unknowns'affiche dans vCenter Server sur le serveur Apple Mac Pro
    L'onglet de l'état du matériel dans vSphere 5.1 affiche Unknown Unknownpour certains périphériques PCI sur l'Apple Mac Pro. Cette erreur se produit car les descriptions de matériel de ces périphériques PCI manquent sur l'Apple Mac Pro. L'erreur qui s'affiche dans l'onglet de l'état du matériel n'empêche pas ces périphériques PCI de fonctionner.

    Solution : Aucune.

  • L'état PCI Unknown Unknowns'affiche dans vCenter Server sur le PileDriver AMD
    L'onglet de l'état du matériel dans vSphere 5.1 affiche Unknown Unknownpour certains périphériques PCI sur le PileDriver AMD. Cette erreur se produit car les descriptions de matériel de ces périphériques PCI manquent sur le PileDriver AMD. L'erreur qui s'affiche dans l'onglet de l'état du matériel n'empêche pas ces périphériques PCI de fonctionner.

    Solution : Aucune.

  • DPM n'est pas pris en charge sur le serveur Apple Mac Pro
    La fonction de gestion de l'alimentation distribuée (DPM) de vSphere 5.1 n'est pas prise en charge sur l'Apple Mac Pro. N'ajoutez pas l'Apple Mac Pro à un cluster sur lequel la DPM est activée. Si l'hôte entre en état « Standby », il ne parvient pas à quitter l'état Standby lorsque la commande de mise sous tension est donnée et affiche une erreur operation timed out. L'Apple Mac Pro ne peut pas se réveiller de la commande logicielle de mise hors tension qu'utilise vSphere lors de la mise en état standby d'un hôte.

    Solution : Si l'hôte Apple Mac Pro entre en « Standby », vous devez mettre l'hôte sous tension en appuyant physiquement sur le bouton d'alimentation.

  • IPMI n'est pas pris en charge sur le serveur Apple Mac Pro
    L'onglet de l'état du matériel dans vSphere 5.1 n'affiche pas les données correctes ou il manque les données de certains composants matériels sur l'Apple Mac Pro. Ce problème est lié au fait que l'IPMI n'est pas pris en charge sur l'Apple Mac Pro.

    Solution : Aucune.

Problèmes divers
  • Après une interruption du réseau ou du stockage, syslog over TCP, syslog over SSL et la journalisation du stockage ne redémarrent pas automatiquement
    Après une interruption du réseau ou du stockage, le service syslog ne redémarre pas automatiquement dans certaines configurations. Ces configurations incluent l'interruption de syslog over TCP, de syslog over SSL et de la journalisation du stockage.

    Solution : Redémarrez explicitement syslog en exécutant la commande suivante :
    esxcli system syslog reloadVous pouvez également configurer syslog over UDP, qui redémarre automatiquement.

  • Le Clustering avec basculement de Windows Server 2012 n'est pas pris en charge
    Si vous essayez de créer un cluster pour le Clustering avec basculement dans Windows Server 2012, et que vous choisissez d'effectuer des tests de validation, l'assistant termine les tests de validation avec des avertissements, puis il recommence les tests de validation. L'assistant du système d'exploitation client Windows Server 2012 ne continue pas vers l'étape de création de cluster.

    Solution : Aucune.