VMware ESXi™ 5.5 Update 3a | 6 octobre 2015 | Build 3116895

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 :

  • Activation de la rotation des journaux : la rotation des journaux des fichiers vmx permet de réduire la taille du fichier journal en spécifiant la taille de chaque journal et le nombre de journaux précédents à conserver.


  • Certification de l'adaptateur PVSCSI : L'adaptateur Paravirtual SCSI (PVSCSI) est certifié pour l'utilisation avec Microsoft Cluster Server (MSCS), la mise en cluster de noyaux et des applications, dont SQL et Exchange. Cela permet d'accroître les performances lors du déplacement d'une logique LSI SAS vers PVSCSI.


  • Prise en charge des processeurs de nouvelle génération : nous poursuivons dans cette version la prise en charge des processeurs Intel et AMD de nouvelle génération. Pour obtenir plus d'informations, veuillez consulter le Guide de compatibilité VMware.


  • Authentification ESXi pour Active Directory : ESXi est modifié pour prendre en charge uniquement le chiffrement AES256-CTS/AES128-CTS/RC4-HMAC des communications Kerberos entre ESXi et Active Directory.


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

Versions antérieures d'ESXi 5.5

Les fonctions et problèmes connus d'ESXi 5.5 sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures à ESXi 5.5 :

Internationalisation

VMware vSphere 5.5 Update 3a est disponible dans les langues suivantes :

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

Compatibilité et installation

Compatibilité des versions ESXi, vCenter Server et vSphere Web Client

La page Matrice d'interopérabilité des produits VMware fournit des informations sur la compatibilité des versions actuelles et précédentes des composants VMware vSphere, notamment ESXi, VMware vCenter Server, vSphere Web Client et les produits VMware en option. Pour plus d'informations sur les agents de gestion et de sauvegarde pris en charge, consultez également la Matrice d'interopérabilité des produits VMware avant d'installer ESXi ou vCenter Server.

vSphere Client et vSphere Web Client sont empaquetés dans vCenter Server ISO. Vous pouvez installer un client ou les deux à l'aide de l'assistant d'installation de VMware vCenter™.

Compatibilité ESXi, vCenter Server et VDDK

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

Compatibilité entre ESXi et Virtual SAN

Virtual SAN ne prend pas en charge les clusters configurés avec des hôtes ESXi antérieurs à la version 5.5 Update 1. Vérifiez que tous les hôtes du cluster Virtual SAN sont mis à niveau vers ESXi 5.5 Update 1 ou version ultérieure avant d'activer Virtual SAN. vCenter Server doit également être mis à niveau vers la version 5.5 Update 1 ou ultérieure.

Compatibilité matérielle pour ESXi

Pour afficher la liste des processeurs, des périphériques de stockage, des baies SAN et des périphériques E/S compatibles avec vSphere 5.5 Update 3, consultez les informations relatives à ESXi 5.5 Update 3 dans le Guide de compatibilité VMware.

Compatibilité des périphériques pour ESXi

Pour déterminer les périphériques compatibles avec ESXi 5.5 Update 3a, consultez les informations relatives à ESXi 5.5 Update 3 dans le Guide de compatibilité VMware.

Certains périphériques sont déconseillés, car ils ne sont plus pris en charge par ESXi 5.5 et versions ultérieures. Pendant le processus de mise à niveau, le pilote de périphérique est installé sur l'hôte ESXi 5.5.x. Si ce périphérique peut encore fonctionner sur ESXi 5.5.x, ce dernier ne le prend pas en charge. Pour obtenir la liste des périphériques déconseillés qui ne sont plus pris en charge par ESXi 5.5.x, consultez l'article de la base de connaissances VMware Périphériques déconseillés et avertissements pendant le processus de mise à niveau vers ESXi 5.5.

Compatibilité des systèmes d'exploitation invités pour ESXi

Pour déterminer quels systèmes d'exploitation invités sont compatibles avec vSphere 5.5 Update 3a, consultez les informations sur ESXi 5.5 Update 3 dans le Guide de compatibilité VMware.

Compatibilité des machines virtuelles pour ESXi

Les machines virtuelles compatibles avec ESX 3.x et versions ultérieures (version matérielle 4) sont prises en charge par ESXi 5.5 Update 3. Les machines virtuelles compatibles avec ESX 2.x et versions ultérieures (version 3 du matériel) ne sont pas prises en charge. Pour utiliser ces machines virtuelles sur ESXi 5.5 Update 3, effectuez une mise à niveau de la compatibilité de la machine virtuelle. Reportez-vous à la documentation Mise à niveau vSphere.

Connexions de vSphere Client aux environnements en Linked Mode avec vCenter Server 5.x

vCenter Server 5.5 ne peut exister en Linked Mode qu'avec d'autres instances de vCenter Server 5.5.

Notes d'installation de cette version

Lisez la documentation Installation et configuration de vSphere qui présente des instructions sur 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 la documentation suivante :

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.1 et ESXi 5.5 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 de votre hôte avec des personnalisations tierces, reportez-vous à 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.5 prend uniquement en charge les CPU avec les jeux d'instructions LAHF et SAHF. Durant une installation ou une mise à niveau, le programme d'installation vérifie la compatibilité du CPU hôte avec vSphere 5.5.x. Si votre matériel hôte n'est pas compatible, un message d'incompatibilité s'affiche sur un écran violet. L'installation ou la mise à niveau vers vSphere 5.5.x est impossible.

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.

Chemins de mise à niveau pris en charge pour la mise à niveau vers ESXi 5.5 Update 3a :

Produits livrables de mise à niveau

Outils de mise à niveau pris en charge

Chemins de mise à niveau pris en charge vers ESXi 5.5 Update 3a

ESX/ESXi 4.0 :
Inclut
ESX/ESXi 4.0 Update 1
ESX/ESXi 4.0 Update 2

ESX/ESXi 4.0 Update 3
ESX/ESXi 4.0 Update 4

ESX/ESXi 4.1 :
Inclut
ESX/ESXi 4.1 Update 1
ESX/ESXi 4.1 Update 2

ESX/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
ESXi 5.1 Update 2

ESXi 5.5
Inclut
ESXi 5.5 Update 1
ESXi 5.5 Update 2

VMware-VMvisor-Installer-5.5.0.update03-3116895.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Oui

ESXi550-201510001.zip
  • VMware vSphere Update Manager
  • ESXCLI
  • VMware vSphere CLI

Non

Non

Yes*

Yes*

Oui

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

Non

Non

Non

Non

Oui


* Remarque : La mise à niveau d'ESXi 5.0.x ou d'ESXi 5.1.x vers ESXi 5.5 Update 3a avec - ESXi550-201510001.zip est prise en charge uniquement avec ESXCLI. Vous devez exécuter la commande esxcli software profile update --depot=<depot_location> --profile=<profile_name> pour effectuer la mise à niveau. Pour plus d'informations, reportez-vous à la rubrique Option de mise à niveau d'ESXi 5.5.x du Guide de mise à niveau vSphere Upgrade.

Composants en libre accès pour VMware vSphere 5.5 Update 3

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

Remarques relatives à la prise en charge du produit

  • vSphere Web Client. Dans la mesure où les plates-formes Linux ne sont plus prises en charge par Adobe Flash, vSphere Web Client n'est pas pris en charge par le système d'exploitation Linux. Les navigateurs tiers qui ajoutent la compatibilité avec Adobe Flash au système d'exploitation de bureau Linux peuvent continuer à fonctionner.

    VMware vCenter Server Appliance. Dans vSphere 5.5, VMware vCenter Server Appliance répond à la réglementation en matière de conformité en appliquant les directives STIG (Security Technical Information Guidelines) établies par l'organisme gouvernemental américain DISA (Defense Information Systems Agency). Avant de déployer VMware vCenter Server Appliance, consultez le guide des opérations sécurisées des dispositifs virtuels VMware, intitulé VMware Hardened Virtual Appliance Operations Guide pour en savoir plus sur les nouvelles normes de sécurité en matière de déploiement et vous assurer de la réussite des opérations.

  • Base de données vCenter Server. vSphere 5.5 supprime la prise en charge d'IBM DB2 comme base de données vCenter Server.

  • VMware Tools. À partir de la version 5.5 de vSphere, toutes les informations sur les procédures d'installation et de configuration de VMware Tools dans vSphere sont fusionnées avec la documentation vSphere existante. Pour plus d'informations sur l'utilisation de VMware Tools dans vSphere, reportez-vous à la documentation vSphere. Le Guide d'installation et de configuration de VMware Tools n'est pas approprié à vSphere 5.5 et versions ultérieures.

  • VMware Tools. À partir de vSphere 5.5, VMware Tools ne fournit pas les fonctionnalités ThinPrint.

  • vSphere Data Protection. vSphere Data Protection 5.1 n'est pas compatible avec vSphere 5.5 en raison d'une modification du fonctionnement de vSphere Web Client. Les utilisateurs de vSphere Data Protection 5.1 qui effectuent une mise à niveau vers vSphere 5.5 doivent également mettre à niveau vSphere Data Protection s'ils prévoient de l'utiliser.

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 ESXi550-Update03 contient les bulletins suivants :

ESXi550-201510401-BG : met à jour le fichier vib esx-base d'ESXi 5.5.

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

ESXi-5.5.0-20151004001-standard
ESXi-5.5.0-20151004001-no-tools

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

Problèmes résolus

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

Problèmes de sauvegarde

  • Les tentatives de restauration d'une machine virtuelle peuvent échouer avec une erreur
    Les tentatives de restauration d'une machine virtuelle sur un hôte ESXi utilisant vSphere Data Protection peuvent échouer et afficher un message d'erreur similaire au suivant :

    Exception inattendue lors de la reconfiguration

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

Problèmes de CIM et d'API

  • Engorgement dans Syslog lorsque le journal des événements système est plein et que des abonnements d'indication existent
    Syslog est engorgé lorsque le journal des événements système (SEL, System Event Log) a atteint sa capacité maximum et que des abonnements d'indication existent. Les journaux suivants sont journalisés rapidement :

    sfcb-vmware_raw[xxxxxxxxxx]: Impossible d'obtenir la classe d'indication des alertes. Utiliser le réglage par défaut
    sfcb-vmware_raw[xxxxxxxxxx]: Impossible d'obtenir la classe d'indication des alertes. Utiliser le réglage par défaut
    sfcb-vmware_raw[xxxxxxxxxx]: Impossible d'obtenir la classe d'indication des alertes. Utiliser le réglage par défaut

    Ce problème est résolu dans cette version.
  • Les indications CIM peuvent échouer lorsque vous utilisez Auto Deploy pour redémarrer les hôtes ESXi
    Si le service sfcbd s'arrête, les indications Common Information Model (CIM) du profil de l'hôte ne peuvent pas être appliquées correctement.

    Ce problème est résolu dans cette version en assurant que les indications CIM ne reposent pas sur le statut du service sfcbd lors de l'application du profil de l'hôte.
  • Les statuts de certains disques peuvent être affichés comme UNCONFIGURED GOOD au lieu de ONLINE
    Sur un hôte ESXi 5.5, les statuts de certains disques peuvent être affichés comme UNCONFIGURED GOOD au lieu de ONLINE. Ce problème se produit pour le contrôleur LSI qui utilise le fournisseur CIM LSI.

    Ce problème est résolu dans cette version.
  • Le chargement du module noyau peut échouer via l'interface CIM
    La commande LoadModule peut échouer lors de l'utilisation de l'interface client CIM pour charger le module noyau. Un message d'erreur semblable au message suivant s'affiche :

    Accès refusé par la règle de contrôle d'accès vmkernel.

    Ce problème est résolu dans cette version.
  • La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand
    La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand. Un message d'erreur similaire au suivant peut être rapporté dans le fichier syslog.log :

    Failed to map segment from shared object: No space left on device

    Ce problème est résolu dans cette version.
  • L'interrogation de l'état du matériel sur l'instance vSphere Client peut échouer avec une erreur
    Les tentatives d'interrogation de l'état du matériel sur vSphere Client peuvent échouer. Un message d'erreur similaire au suivant s'affiche dans le fichier /var/log/syslog.log sur l'hôte ESXi:

    TIMEOUT DOING SHARED SOCKET RECV RESULT (1138472) Dépassement du temps d'attente (ou autre erreur de socket) lors de l'attente de la réponse du fournisseur d'Header Id (16040) La demande au fournisseur 111 du processus 4 a échoué. Error:Timeout (or other socket error) waiting for response from provider Dropped response operation details -- nameSpace: root/cimv2, className: OMC_RawIpmiSensor, Type : 0

    Ce problème est résolu dans cette version.
  • La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand
    La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand. Un message d'erreur similaire au suivant peut être rapporté dans le fichier syslog.log :

    Failed to map segment from shared object: No space left on device

    Ce problème est résolu dans cette version.
  • Le service sfcbd peut cesser de répondre avec un message d'erreur
    Le service sfcbd peut cesser de répondre et le message d'erreur suivant peut s'afficher dans le fichier Syslog :

    spSendReq/spSendMsg failed to send on 7 (-1)
    Error getting provider context from provider manager: 11

    Ce problème se produit en cas de contention pour un sémaphore entre le serveur CIM et les fournisseurs.

    Ce problème est résolu dans cette version.
  • De fausses alarmes s'affichent dans l'onglet État du matériel de vSphere Client
    Après la mise à niveau du microprogramme Integrated Lights Out (iLO) sur HP DL980 G7, de fausses alarmes apparaissent dans l'onglet État du matériel de l'instance de vSphere Client. Des messages d'erreur similaires au message suivant peuvent être consignés dans le fichier /var/log/syslog.log :

    sfcb-vmware_raw[nnnnn]: IpmiIfruInfoAreaLength : Reading FRU for 0x0 at 0x8 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruChassis : Reading FRU Chassis Info Area length for 0x0 FAILED
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruBoard : Reading FRU Board Info details for 0x0 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfruInfoAreaLength : Reading FRU for 0x0 at 0x70 FAILED cc=0xffffffff
    sfcb-vmware_raw[nnnnn]: IpmiIfcFruProduct : Reading FRU product Info Area length for 0x0 FAILED
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : data length mismatch req=19,resp=3
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : EntryId mismatch req=0001,resp=0002
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : EntryId mismatch req=0002,resp=0003
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : EntryId mismatch req=0003,resp=0004
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : EntryId mismatch req=0004,resp=0005
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry: EntryId mismatch req=0005,resp=0006
    sfcb-vmware_raw[nnnnn]: IpmiIfcSelReadEntry : EntryId mismatch req=0006,resp=0007

    Ce problème est résolu dans cette version.
  • ESXi peut envoyer des événements en double au logiciel de gestion
    ESXi peut envoyer des événements en double au logiciel de gestion quand un événement de capteur IPMI (Intelligent Platform Management Interface) est déclenché sur l'hôte ESXi.

    Ce problème est résolu dans cette version.
  • Impossible de surveiller l'état du matériel après la suppression de l'abonnement d'indication CIM
    Si le client CIM envoie deux requêtes Supprimer l'instance au même abonnement d'indication CIM, le service sfcb-vmware_int peut cesser de répondre en raison d'une contention de mémoire. Vous risquez de ne pas pouvoir surveiller l'état du matériel avec l'instance de vCenter Server et ESXi.

    Ce problème est résolu dans cette version.
  • La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand
    La surveillance d'un hôte ESXi 5.5 avec Dell OpenManage peut échouer à cause d'une erreur openwsmand. Un message d'erreur semblable au suivant peut être signalé :

    Failed to map segment from shared object: No space left on device

    Ce problème est résolu dans cette version.
  • Le client CIM peut afficher une erreur en raison d'énumérations multiples
    Lorsque vous exécutez plusieurs requêtes d'énumération sur une classe de port VMware Ethernet en utilisant la méthode CBEnumInstances, les serveurs s'exécutant sur ESXi 5.5 peuvent remarquer un message d'erreur similaire au suivant :

    CIM error: enumInstances Class not found

    Ce problème se produit lorsque le logiciel de gestion ne parvient pas à récupérer les informations fournies par VMware_EthernetPort()class. Lorsque ce problème se produit, la requête sur memstats peut afficher le message d'erreur suivant :

    MemStatsTraverseGroups: VSI_GetInstanceListAlloc failure: Not found.

    Ce problème est résolu dans cette version.
  • Impossible de surveiller l'état du matériel sur un hôte ESXi
    Un hôte ESXi peut signaler une erreur dans l'onglet État du matériel en raison de l'absence de réponse du service de surveillance du matériel (sfcbd). Une erreur similaire à la suivante est consignée dans syslog.log :

    sfcb-hhrc[5149608]: spGetMsg receiving from 65 5149608-11 Resource temporarily unavailable
    sfcb-hhrc[5149608]: rcvMsg receiving from 65 5149608-11 Resource temporarily unavailable
    sfcb-hhrc[5149608]: Timeout or other socket error
    sfcb-LSIESG_SMIS13_HHR[6064161]: spGetMsg receiving from 51 6064161-11 Resource temporarily unavailable
    sfcb-LSIESG_SMIS13_HHR[6064161]: rcvMsg receiving from 51 6064161-11 Resource temporarily unavailable
    sfcb-LSIESG_SMIS13_HHR[6064161]: Timeout or other socket error
    sfcb-kmoduleprovider[6064189]: spGetMsg receiving from 57 6064189-11 Resource temporarily unavailable
    sfcb-kmoduleprovider[6064189]: rcvMsg receiving from 57 6064189-11 Resource temporarily unavailable
    sfcb-kmoduleprovider[6064189]: Timeout or other socket error

    Le Syslog ci-dessous au niveau de débogage indique que les données non valides 0x3c sont envoyées par IPMI, au lieu des données attendues 0x01.

    sfcb-vmware_raw[35704]: IpmiIfcRhFruInv: fru.header.version: 0x3c

    Ce problème se produit lorsque le fournisseur sfcb-vmware_raw reçoit des données non valides de l'outil IPMI tout en lisant les données d'inventaire d'unités remplaçables sur site (FRU, Field Replaceable Unit).

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

Problèmes divers

  • Le clonage de modèles de machines virtuelles sur lesquelles CBT est activé à partir d'hôtes ESXi peut échouer
    Les tentatives de clonage simultané de machines virtuelles sur lesquelles le suivi de modification des blocs (CBT, Changed Block Tracking) est activé à partir de deux hôtes ESXi 5.5 distincts peuvent échouer. Un message d'erreur semblable au message suivant s'affiche :

    Impossible d'ouvrir VM_template.vmdk' : Ne peut pas ouvrir/créer le fichier de suivi des modifications (2108).

    Ce problème est résolu dans cette version.
  • Impossible de se connecter à l'hôte ESXi avec les informations d'identification d'Active Directory
    Les tentatives de connexion à un hôte ESXi peuvent échouer après que l'hôte a joint une instance d'Active Directory. Ce problème se produit lorsqu'un utilisateur d'un domaine tente de joindre un autre domaine approuvé, absent du site client ESXi. Une erreur similaire à la suivante est consignée dans le fichier sys.log/netlogon.log :

    netlogond[17229]: [LWNetDnsQueryWithBuffer() /build/mts/release/bora-1028347/likewise/esxi-esxi/src/linux/netlogon/utils/lwnet-dns.c:1185] DNS lookup for '_ldap._tcp.<domain details>' failed with errno 0, h_errno = 1

    Ce problème est résolu dans cette version.
  • Mise à jour vers la bibliothèque cURL
    cURL ne parvient pas à résoudre le nom d'hôte localhost lorsque l'adresse IPv6 est désactivée. Un message d'erreur semblable au message suivant s'affiche :

    erreur : échec de l'initialisation enumInstances

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

Problèmes de mise en réseau

  • Les hôtes ESXi dont les machines virtuelles ont un pilote de vNIC e1000 ou e1000e peuvent échouer et afficher un écran violet
    Lorsque vous activez le déchargement de segmentation TCP (TSO, TCP segmentation Offload), les hôtes ESXi dont les machines virtuelles ont un pilote de vNIC e1000 ou e1000e peuvent échouer et afficher un écran violet. Des messages d'erreur similaires au suivant peuvent être consignés dans les fichiers journaux :

    cpu7:nnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 9:21:12:17.991
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000TxTSOSend@vmkernel#nover+0x65b stack: 0xnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000PollTxRing@vmkernel#nover+0x18ab stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]E1000DevAsyncTx@vmkernel#nover+0xa2 stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetWorldletPerVMCB@vmkernel#nover+0xae stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]WorldletProcessQueue@vmkernel#nover+0x488 stack: 0xnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]WorldletBHHandler@vmkernel#nover+0x60 stack: 0xnnnnnnnnnnnnnnn
    cpu7:nnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]BH_Check@vmkernel#nover+0x185 stack: 0xnnnnnnnnnnnn

    Ce problème est résolu dans cette version.
  • ESXi répond à un type de requête Internet Control Message Protocol inutile
    Il est possible que l'hôte ESXi réponde à des types de requêtes Internet Control Message Protocol (ICMP) inutiles.

    Ce problème est résolu dans cette version.
  • Les hôtes ESXi peuvent échouer lors de l'exécution d'opérations de réanalyse du périphérique de stockage
    L'hôte peut ne pas parvenir à réanalyser le périphérique de stockage lorsque plusieurs threads tentent de modifier le même objet. Des messages d'erreur similaires au suivant s'affichent dans le fichier vmkwarning.log :

    cpu43:nnnnnnn)ALERT: hostd detected to be non-responsive
    cpu20:nnnnnnn)ALERT: hostd detected to be non-responsive

    Ce problème est résolu dans cette version.
  • L'ajout d'un hôte ESXi dans vCenter Server provoque un engorgement
    Lorsque vous ajoutez un hôte ESXi dans vCenter Server et que vous créez une interface VMkernel pour vMotion, le message suivant s'affiche en succession rapide dans le fichier hostd.log :

    Failed to find vds Id for portset vSwitch0

    Ce problème est résolu dans cette version.
  • Les services de déploiement Microsoft Windows (WDS) peuvent ne pas parvenir à démarrer par PXE les machines virtuelles qui utilisent l'adaptateur réseau VMXNET3
    Les tentatives de démarrage par PXE de machines virtuelles qui utilisent l'adaptateur réseau VMXNET3, à l'aide des services de déploiement Microsoft Windows (WDS), peuvent échouer et afficher des messages similaires au suivant :

    Échec du démarrage de Windows. Une modification matérielle ou logicielle récente peut en être la cause. Pour résoudre ce problème :
    1. insérez votre disque d'installation de Windows et redémarrez votre ordinateur.
    2. Choisissez les paramètres linguistiques, puis cliquez sur Suivant.
    3. Cliquez sur Réparer votre ordinateur.
    Si vous ne possédez pas le disque, contactez votre administrateur système ou le fabricant de votre ordinateur pour obtenir de l'aide.

    Statut : 0xc0000001

    Information : La sélection de démarrage a échoué car un périphérique nécessaire est inaccessible.

    Ce problème est résolu dans cette version.
  • Activer la configuration de Rx Ring#2 pour résoudre les problèmes d'insuffisance de mémoire de Rx Ring#2 et les abandons de paquets côté récepteur
    Une machine virtuelle Linux pour laquelle la fonctionnalité Large Receive Offload (LRO) est activée sur un périphérique VMXNET3 peut rencontrer des problèmes d'abandons de paquets côté récepteur. Ce problème se produit lorsque l'instance de Rx Ring#2 atteint un niveau de mémoire insuffisant étant donné que la taille de Rx Ring#2 ne peut être configurée initialement.

    Ce problème est résolu dans cette version.
  • Un écran de diagnostic violet peut s'afficher lors de l'utilisation de DvFilter avec une liaison montante NetQueue prise en charge
    Un serveur ESXi peut afficher un écran de diagnostic violet lors de l'utilisation de DvFilter avec une liaison montante NetQueue prise en charge et connectée à une instance de vSwitch ou à un vSphere Distributed Switch (VDS). L'hôte ESXi peut rapporter un suivi arrière similaire au suivant :

    pcpu:22 world:4118 name:"idle22" (IS)
    pcpu:23 world:2592367 name:"vmm1:S10274-AAG" (V)
    @BlueScreen: Spin count exceeded (^P) - possible deadlock
    Code start: 0xnnnnnnnnnnnn VMK uptime: 57:09:18:15.770
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic@vmkernel#nover+0xnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SP_WaitLock@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetSchedFIFOInput@vmkernel#nover+0xnnn stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]NetSchedInput@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]IOChain_Resume@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PortOutput@vmkernel#nover+0xnn stack: 0xnn

    Ce problème est résolu dans cette version.
  • Échec de l'hôte ESXi avec affichage d'un écran de diagnostic violet lorsque la fonctionnalité Netflow est désactivée
    Un hôte ESXi peut échouer et afficher un écran de diagnostic violet avec une erreur PF exception 14 lorsque la fonctionnalité Netflow de l'instance de vSphere Distributed Switch est désactivée. Ce problème se produit en raison d'une erreur de synchronisation du temporisateur.

    Ce problème est résolu dans cette version.
  • Le remplacement du planificateur de réseau par SFQ lors d'un trafic E/S intense peut provoquer une transmission irrécupérable
    Lorsque de lourdes charges d'E/S sont en cours d'exécution, le planificateur de réseau SFQ peut réinitialiser la NIC physique lors de la commutation des planificateurs de réseau. Ce problème peut entraîner une transmission irrécupérable lors de laquelle aucun paquet n'est transmis au pilote.

    Ce problème est résolu dans cette version.
  • La commande vmkping avec les trames Jumbo peut échouer
    La commande vmkping avec les trames Jumbo peut échouer après la modification d'une Maximum Transmission Unit (MTU) vmkping parmi de nombreuses autres dans le même commutateur. Un message d'erreur semblable au message suivant s'affiche :

    sendto() a échoué (Message trop long)

    Ce problème est résolu dans cette version.
  • Le pare-feu ESXi peut refuser les services qui utilisent le port 0-65535 comme port de service
    Le Virtual Serial Port Concentrator (vSPC) ou le service du client NFS peut ne pas fonctionner sur la plate-forme ESXi. Ce problème se produit lorsque l'ordre de l'ensemble de règles diffère, ce qui autorise le port 0-65535, suite à une séquence d'activation. Par conséquent, les paquets associés au vSPC ou au client NFS sont abandonnés de manière inattendue, même si l'adresse IP autorisée sur l'ensemble de règles correspondant est spécifiée.

    Ce problème est résolu dans cette version.
  • Les annonces du routeur IPv6 ne fonctionnent pas comme prévu lors du balisage de 802.1q avec les adaptateurs VMXNET3
    Les annonces du routeur (RA, Router Advertisement) IPv6 ne fonctionnent pas comme prévu lors du balisage de 802.1q avec les adaptateurs VMXNET3 sur une machine virtuelle Linux. Ce problème se produit car l'adresse des annonces du routeur IPv6 destinée à l'interface VLAN est fournie à l'interface de base.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi peut perdre de la connectivité réseau
    Un hôte ESXi peut perdre de la connectivité réseau et rencontrer des problèmes de stabilité lorsque plusieurs messages d'erreur similaires au suivant sont journalisés :

    WARNING: Heartbeat: 785 : PCPU 63 didn't have a heartbeat for 7 seconds; *may* be locked up.

    Ce problème est résolu dans cette version.
  • Connectivité réseau perdue lors de l'application d'un profil d'hôte pendant un déploiement automatique
    Lors de l'application d'un profil d'hôte pendant un déploiement automatique, vous pouvez perdre la connectivité réseau, car la carte réseau VTEP (VXLAN Tunnel Endpoint) devient marquée comme vmknic de gestion.

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

Problèmes de sécurité

  • Mise à jour de la bibliothèque libxml2
    La bibliothèque ESXi userworld libxml2 est mise à jour vers la version 2.9.2.
  • Mise à jour de la bibliothèque ESXi userworld OpenSSL
    La bibliothèque ESXi userworld OpenSSL est mise à jour vers la version 1:0.1m.
  • Mise à jour de la bibliothèque libPNG
    La bibliothèque libPNG est mise à jour vers la version libpng-1.6.16.

Problèmes de configuration de serveur

  • La redirection de console série sur LAN peut ne pas fonctionner correctement
    Une carte de redirection du port série PCIe peut ne pas fonctionner correctement lorsqu'elle est connectée à une Interrupt Request (IRQ) de l'Industry Standard Architecture (ISA) comportant de 0 à 15 décimales sur un Advanced Programmable Interrupt Controller (APIC), car le CPU ne peut pas recevoir ses interruptions. Pour que ces périphériques et d'autres périphériques Peripheral Component Interconnect (PCI) fonctionnent, VMkernel doit autoriser les interruptions à déclenchement par niveau sur les IRQ ISA.

    Ce problème est résolu dans cette version.
  • Esxtop peut afficher l'utilisation à 100 % du CPU de manière incorrecte
    L'utilitaire esxtop PCPU UTIL/CORE UTIL affiche une utilisation à 100 % du CPU erronée si le paramètre PcpuMigrateIdlePcpus est défini à 0.

    Ce problème est résolu dans cette version.
  • L'interrogation des adaptateurs de bus hôte Fibre Channel rapporte le statut Inconnu (1)
    Après avoir procédé à la mise à niveau de l'hôte ESXi de la version 5.1 vers la version 5.5 et après avoir importé le dernier module Management Information Base (MIB), le logiciel de surveillance tiers renvoie le statut Inconnu (1) lors de l'interrogation des adaptateurs de bus hôte (HBA, Host Bus Adapter) Fibre Channel (FC).

    Ce problème est résolu dans cette version.
  • La passerelle de l'hôte est supprimée et des défaillances de conformité peuvent se produire lorsque le profil d'hôte ESXi existant est réappliqué à l'hôte ESXi avec état
    Lorsqu'un profil d'hôte ESXi existant est appliqué à un hôte ESXi 5.5 récemment installé, l'état de conformité du profil est non conforme. Ce problème se produit lorsque le profil d'hôte est créé à partir d'hôtes dont l'interface VXLAN est configurée. Le test de conformité sur des hôtes possédant le profil d'hôte précédemment créé peut échouer. Un message d'erreur semblable au message suivant s'affiche :

    La configuration d'itinéraire IP ne correspond pas aux spécifications

    Ce problème est résolu dans cette version.
  • L'écran de diagnostic violet affiche une exception de défaut de page dans un environnement ESXi imbriqué
    Dans un environnement ESXi imbriqué, l'implémentation de CpuSchedAfterSwitch() provoque une condition de course dans le code du planificateur et l'écran de diagnostic violet qui s'affiche présente une exception de défaut de page.

    Ce problème est résolu dans cette version.
  • Le nom d'initiateur iSCSI est autorisé lors de l'activation du logiciel iSCSI via esxcli
    Vous pouvez désormais spécifier un nom d'initiateur iSCSI à la commande esxcli iscsi software set.
  • Une machine virtuelle peut ne pas afficher de message d'avertissement lorsque le CPU n'est pas entièrement réservé
    Lorsque vous créez une machine virtuelle en définissant le paramètre sched.cpu.latencySensitivity sur Élevé et que vous mettez sous tension, l'affinité exclusive des vCPU peut ne pas être activée si la machine virtuelle ne possède pas une réservation de CPU totale.

    Dans les versions précédentes, la machine virtuelle n'affichait pas de message d'avertissement lorsque le CPU n'était pas totalement réservé. Pour plus d'informations, reportez-vous à l'article 2087525 de la base de connaissances.

    Ce problème est résolu dans cette version.
  • Le SNMPD peut démarrer automatiquement après avoir effectué la mise à niveau de l'hôte ESXi
    Le SNMPD peut démarrer automatiquement après que vous avez procédé à la mise à niveau de l'hôte ESXi vers la version 5.5 Update 2.

    Ce problème est résolu dans cette version.
  • Les profils d'hôte deviennent non conformes avec un simple changement de syscontact ou de syslocation de SNMP
    Les profils d'hôte deviennent non conformes avec un simple changement de syscontact ou de syslocation de SNMP. Le problème se produit lorsque le plugin-in de profil d'hôte SNMP applique une valeur unique à tous les hôtes connectés au profil d'hôte. Un message d'erreur semblable au suivant peut s'afficher :

    La configuration de l'agent SNMP est différente

    Le problèmes est résolu dans cette version en autorisant les réglages de valeur pour chaque hôte pour certains paramètres tels que syslocation, syscontact, v3targets,v3users et engineid.
  • Les tentatives de création d'un PEPS et d'écriture des données sur celui-ci peuvent entraîner un écran de diagnostic violet
    Lorsque vous créez un FIFO et tentez d'écrire des données dans /tmp/dpafifo, un écran de diagnostic violet risque d'apparaître dans certaines conditions.

    Ce problème est résolu dans cette version.
  • Les tentatives de redémarrage de Windows 8 et Windows 2012 Server sur des machines virtuelles hôtes ESXi peuvent échouer
    Après un redémarrage, les machines virtuelles Windows 8 et Windows 2012 Server peuvent ne pas répondre lorsque l'écran de démarrage Microsoft Windows apparaît. Pour plus d'informations, reportez-vous à l'article 2092807 de la base de connaissances.

    Ce problème est résolu dans cette version.
  • La définition de limite de CPU pour une machine virtuelle à processeur unique affecte le fonctionnement du système ESXi.
    Lorsque vous définissez la limite de CPU d'une machine virtuelle à processeur unique, l'utilisation globale d'ESXi peut diminuer en raison d'un défaut dans le programmateur d'ESXi. Ce cas de figure se présente lorsque le programmateur d'ESXi considère les VM avec limite de CPU comme exécutables (lorsqu'elles n'étaient pas en cours d'exécution) lors des estimations de la charge de CPU, ce qui fausse les décisions en matière d'équilibrage de charge.

    Pour plus de détails, reportez-vous à l'article 2096897 de la base de connaissances.

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

Problèmes de matériel pris en charge

  • Les valeurs de la consommation et de la capacité d'alimentation ne figurent pas dans la commande esxtop
    Sur les systèmes Lenovo, les valeurs de la consommation et de la capacité d'alimentation ne sont pas disponibles dans la commande esxtop.

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

Problèmes de stockage

  • Lors d'un basculement de haute disponibilité ou d'une défaillance d'un hôte, les fichiers .vswp des machines virtuelles mises sous tension sur cet hôte peuvent être négligés dans le stockage
    Durant un basculement de haute disponibilité ou d'une défaillance d'un hôte, les fichiers .vswp des machines virtuelles mises sous tension sur cet hôte peuvent être négligés dans le stockage. Lorsque ces basculements ou défaillances surviennent en grand nombre, la capacité maximale de stockage peut être atteinte.

    Ce problème est résolu dans cette version.
  • Un faux message de changement de PE peut s'afficher dans le fichier journal VMkernel lors de la réanalyse d'une banque de donnée VMFS avec plusieurs extensions
    Lorsque vous procédez à la réanalyse d'une banque de données Virtual Machine File System (VMFS) avec plusieurs extensions, le message de journal suivant peut être consigné dans le journal VMkernel, même en l'absence de problème de connectivité de stockage :

    Nombre de PE pour le volume passé de 3 à 1. Une réanalyse de volume VMFS peut être nécessaire pour utiliser ce volume.

    Ce problème est résolu dans cette version.
  • Lors de conditions d'erreurs transitoires, les E/S d'un périphérique peuvent échouer de manière répétée et ne pas basculer vers un autre chemin actif
    Lors de conditions d'erreurs transitoires telles que BUS BUSY, QFULL, HOST ABORTS et HOST RETRY, les tentatives de commandes échouent de manière répétée sans pour autant basculer vers un autre chemin actif après une période donnée.

    Ce problème est résolu dans cette version. Lorsque ces erreurs surviennent, le chemin est déclaré MORT s'il est encore occupé après deux tentatives. Par conséquent, le basculement est déclenché et les E/S sont envoyées au périphérique via un autre chemin actif.
  • Lors d'un basculement de haute disponibilité ou d'une défaillance d'un hôte, les fichiers .vswp des machines virtuelles mises sous tension sur cet hôte peuvent être négligés dans le stockage
    Durant un basculement de haute disponibilité ou d'une défaillance d'un hôte, les fichiers .vswp des machines virtuelles mises sous tension sur cet hôte peuvent être négligés dans le stockage. Lorsque ces basculements ou défaillances surviennent en grand nombre, la capacité maximale de stockage peut être atteinte.

    Ce problème est résolu dans cette version.
  • Les tentatives d'obtention d'un bloc de mappage d'un stockage hors ligne peuvent provoquer la défaillance du service hostd
    Le service hostd peut échouer sur un hôte ESXi 5.x lors d'une tentative d'exécution de l'API acquireLeaseExt sur un disque de snapshot mis hors ligne. Ce disque peut résider sur une extension mise hors ligne. L'appelant de l'API peut être une solution de sauvegarde tierce. Un message d'erreur similaire au message suivant s'affiche dans vmkernel.log :

    cpu4:4739)LVM: 11729: Some trailing extents missing (498, 696).

    Ce problème est résolu dans cette version.
  • L'hôte ESXi 5.5 peut cesser de répondre et afficher un écran de diagnostic violet lors de la collecte de l'ensemble de journaux de support de la machine virtuelle
    Lorsqu'aucune interface SCSI spécifique au transport n'est définie pour les pilotes intégrés ou tiers, l'hôte ESXi peut cesser de répondre et afficher un écran de diagnostic violet. Ce problème se produit lors de la collecte de l'ensemble de journaux de support de la machine virtuelle ou lorsque vous exécutez les interfaces de ligne de commande d'IODM (I/O Device Management) telles que :

    • esxcli storage san sas list

    • esxcli storage san sas stats get


    Ce problème est résolu dans cette version.
  • Les tentatives d'expansion des volumes VMFS au-delà de 16 To peuvent échouer dans certains scénarios
    Un hôte ESXi peut ne pas parvenir à étendre une banque de données Virtual Machine File System (VMFS5) au-delà de 16 To. Des messages d'erreur similaires au suivant sont consignés dans le fichier vmkernel.log :

    cpu38:34276)LVM: 2907: [naa.600000e00d280000002800c000010000:1] Device expanded (actual size 61160331231 blocks, stored size 30580164575 blocks)
    cpu38:34276)LVM: 2907: [naa.600000e00d280000002800c000010000:1] Device expanded (actual size 61160331231 blocks, stored size 30580164575 blocks)
    cpu47:34276)LVM: 11172: LVM device naa.600000e00d280000002800c000010000:1 successfully expanded (new size: 31314089590272)
    cpu47:34276)Vol3: 661: Unable to register file system ds02 for APD timeout notifications: Already exists
    cpu47:34276)LVM: 7877: Using all available space (15657303277568).
    cpu7:34276)LVM: 7785: Error adding space (0) on device naa.600000e00d280000002800c000010000:1 to volume 52f05483-52ea4568-ce0e-901b0e0cd0f0: No space left on device
    cpu7:34276)LVM: 5424: PE grafting failed for dev naa.600000e00d280000002800c000010000:1 (opened: t), vol 52f05483-52ea4568-ce0e-901b0e0cd0f0: Limit exceeded
    cpu7:34276)LVM: 7133: Device scan failed for <naa.600000e00d280000002800c000010000:1>: Limit exceeded
    cpu7:34276)LVM: 7805: LVMProbeDevice failed for device naa.600000e00d280000002800c000010000:1: Limit exceeded
    cpu32:38063)<3>ata1.00: bad CDB len=16, scsi_op=0x9e, max=12
    cpu30:38063)LVM: 5424: PE grafting failed for dev naa.600000e00d280000002800c000010000:1 (opened: t), vol 52f05483-52ea4568-ce0e-901b0e0cd0f0: Limit exceeded
    cpu30:38063)LVM: 7133: Device scan failed for <naa.600000e00d280000002800c000010000:1>: Limit exceeded

    Ce problème est résolu dans cette version.
  • L'hôte ESXi peut échouer et afficher un écran de diagnostic violet lorsque plusieurs filtres vSCSI sont associés à un disque de VM
    Un hôte ESXi 5.5 peut échouer et afficher un écran de diagnostic violet similaire à l'écran suivant lorsque plusieurs filtres vSCSI sont associés à un disque de machine virtuelle :

    cpu24:103492 opID=nnnnnnnn)@BlueScreen: #PF Exception 14 in world 103492:hostd-worker IP 0xnnnnnnnnnnnn addr 0x30
    PTEs:0xnnnnnnnnnn;0xnnnnnnnnnn;0x0;
    cpu24:103492 opID=nnnnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 21:06:32:38.296
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_GetFilterPrivateData@vmkernel#nover+0x1 stack: 0x4136c7d
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_IssueInternalCommand@vmkernel#nover+0xc3 stack: 0x410961
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FileSyncRead@<None>#<None>+0xb1 stack: 0x0
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_DigestRecompute@<None>#<None>+0x291 stack: 0x1391
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FilterDigestRecompute@<None>#<None>+0x36 stack: 0x20
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x322 stack: 0x411424b18120
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@<None>#<None>+0xef stack: 0x41245111df10
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@<None>#<None>+0x243 stack: 0x41245111df20
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x275c3918
    cpu24:103492 opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry@vmkernel#nover+0x64 stack: 0x0

    Ce problème est résolu dans cette version.
  • L'hôte ESXi cesse de répondre et perd la connexion à vCenter Server lors d'incidents dans les banques de données VMFS non ATS
    Un hôte ESXi peut ne plus répondre et les machines virtuelles deviennent inaccessibles. De plus, l'hôte ESXi peut perdre la connexion à vCenter Server en raison d'un blocage lors d'incidents de stockage dans des banques de données VMFS non Atomic Test and Set (ATS).

    Ce problème est résolu dans cette version.
  • L'hôte ESXi s'enregistre avec un IQN incorrect sur un logiciel de gestion cible
    Le logiciel Unisphere Storage Management enregistre le nom donné IQN de l'initiateur lorsque l'iSCSI logiciel est d'abord activé. Lors d'un démarrage sans état, l'IQN enregistré n'est pas modifié avec le nom défini dans le profil d'hôte. Vous devez supprimer manuellement les initiateurs depuis la baie puis les ajouter à nouveau sous le nouvel IQN.

    Ce problème est résolu par l'ajout d'un nouveau paramètre à la commande d'activation iSCSI logicielle afin qu'Unisphere enregistre l'initiateur sous le nom défini dans le profil d'hôte. La ligne de commande pour définir l'IQN lors de l'activation iSCSI logicielle est :

    esxcli iscsi software set --enabled=true --name iqn.xyz
  • La synchronisation de vSphere Replication peut échouer en raison d'un changement de nom de la banque de données source
    Si vous renommez la banque de données sur laquelle les machines virtuelles de la source de réplication sont exécutées, les opérations de synchronisation de la réplication de ces machines échouent et affichent un message d'erreur similaire au suivant :

    Erreur d'exécution du serveur VRM. Pour obtenir des informations sur la résolution des problèmes, consultez la documentation.
    L'exception détaillée est la suivante : 'Invalid datastore format '<Datastore Name>'

    Ce problème est résolu dans cette version.
  • Les tentatives de démontage d'une banque de données NFS peuvent échouer
    Les tentatives de démontage d'une banque de données NFS peuvent échouer, car les E/S NFS peuvent être bloquées par des problèmes de connectivité lors d'erreurs VERROUILLAGE NFS PERDU. Un message d'erreur similaire au message suivant s'affiche :

    cpu23:xxxxx opID=xxxxxabf)AVERTISSEMENT : NFS : 1985: datastore1 comporte des fichiers ouverts, démontage impossible

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

Problèmes de mise à niveau et d'installation

  • Un message d'erreur s'affiche sur l'écran de démarrage lorsque l'hôte ESXi 5.5 démarre à partir de la mise en cache sans état de vSphere Auto Deploy
    Lorsque l'hôte ESXi 5.5 démarre à partir de la mise en cache sans état de vSphere Auto Deploy, un message d'erreur similaire au message suivant avec des retraçages s'affiche sur l'écran de démarrage. Cette erreur est due à un bref message inattendu de moins de quatre caractères dans le script Syslog network.py.

    IndexError: string index out of range

    Ce problème est résolu dans cette version.
  • Les tentatives d'installation ou de mise à niveau de VMware Tools sur une machine virtuelle Solaris 10 Update 3 peuvent échouer
    Les tentatives d'installation ou de mise à niveau de VMware Tools sur une machine virtuelle Solaris 10 Update 3 peuvent échouer et afficher le message d'erreur suivant :

    Detected X version 6.9
    Could not read /usr/lib/vmware-tools/configurator/XOrg/7.0/vmwlegacy_drv.so Execution aborted.

    Ce problème se produit lorsque le script vmware-config-tools.pl copie le fichier vmwlegacy_drv.so qui ne devrait pas être utilisé dans Xorg 6.9.
  • L'option de disposition du clavier pour l'interface DCUI et l'interface utilisateur du profil d'hôte peut s'afficher de manière incorrecte en tchécoslovaque
    L'option de disposition du clavier de l'interface utilisateur de la console directe (interface DCUI) et du profil d'hôte peut s'afficher de manière incorrecte en tchécoslovaque. Cette option s'affiche lors de l'installation d'ESXi et également dans l'interface DCUI après l'installation.

    Ce problème est résolu dans cette version en renommant l'option de disposition du clavier en tchèque.
  • L'option de conservation du fichier tools.conf est disponible par défaut
    Lorsque vous effectuez la mise à niveau de VMware Tools dans le système d'exploitation invité Windows de 64 bits, le fichier tools.conf est automatiquement supprimé. Le fichier tools.conf est désormais conservé par défaut à partir de la version ESXi 5.5 Update 3.
  • Le redémarrage du système d'exploitation invité peut échouer après une installation, une mise à niveau ou une désinstallation de VMware Tools
    Lorsque vous mettez hors tension une machine immédiatement après avoir procédé à une installation, une mise à niveau ou une désinstallation de VMware Tools dans un environnement Linux (RHEL ou Cent OS 6), le SE invité peut ne pas parvenir à redémarrer en raison d'un fichier image de disque virtuel RAMDISK corrompu. Le SE invité rapporte un message d'erreur similaire au suivant :

    RAMDISK: incomplete write (31522 != 32768)
    write error
    Kernel panic - not syncing : VFS: Unable to mount root fs on unknown-block(0,0)


    Ce problème est résolu dans cette version en permettant la création complète du fichier initramfs lors de l'installation, de la mise à niveau ou de la désinstallation de VMware Tools.

    Le SE invité qui contient le fichier image RAMDISK corrompu peut être sauvé afin de terminer l'état de démarrage. Pour plus d'informations, reportez-vous à l'article 2086520 de la base de connaissances.

    Ce problème est résolu dans cette version.
  • L'application d'un profil d'hôte avec une mise en cache sans état activée sur un hôte ESXi sans état peut être longue
    L'application d'un profil d'hôte sur un hôte ESXi sans état avec une importante quantité de Logical Unit Number (LUN) de stockage peut mettre du temps à redémarrer lorsque vous activez la mise en cache sans état avec esx comme argument du premier disque. Cela se produit lorsque vous appliquez manuellement un profil d'hôte ou durant le redémarrage de l'hôte.

    Ce problème est résolu dans cette version.
  • L'opération de transfert des VIB peut provoquer la perte de l'installation ou de la configuration des VIB après le redémarrage d'un hôte ESXi
    Lorsque des vSphere Installation Bundles (VIB) sont installés sur le système, esxupdate construit une nouvelle image dans /altbootbank et modifie l'état de démarrage /altbootbank boot.cfg à mettre à jour. Lorsqu'un VIB live installable est installé, le système enregistre la modification de configuration dans /altbootbank. Le séquencement supprime le contenu de /altbootbank sauf si vous exécutez une correction après le séquencement. L'installation du VIB peut être perdue si vous redémarrez l'hôte après un séquencement.

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

Problèmes de Virtual SAN

  • Le contrôle du cluster Virtual SAN peut échouer en raison d'un partitionnement réseau inattendu dans le cluster
    Le contrôle du cluster Virtual SAN peut échouer en raison d'un partitionnement réseau inattendu dans lequel la requête de la version 3 de l'Internet Group Management Protocol (IGMP) n'est pas rapportée si le système utilise la version 2.

    Ce problème est résolu dans cette version.
  • L'existence d'un Virtual SAN sur des disques à latence élevée peut provoquer le blocage des files d'attente Entrée/Sortie et du cluster
    Le Virtual SAN ne gère pas normalement les disques à latences extrêmement élevées sur le point de mourir. Ce type de disque mourant peut provoquer le blocage des files d'attente d'Entrée/Sortie et des nœuds de cluster de Virtual SAN dans l'instance de vCenter Server.

    Ce problème est résolu dans cette version grâce à l'ajout de la fonctionnalité Dying Disk Handling (DDH). Elle fournit une architecture de surveillance de la latence dans le noyau, un démon permettant de détecter des périodes de latence élevées et un mécanisme de démontage de chaque disque et groupe de disques.
  • Amélioration de l'opération de resynchronisation Virtual SAN
    Dans certaines situations, la resynchronisation du composant Virtual SAN peut se figer ou devenir très lente. Cette version introduit l'encombrement basé sur les composants pour améliorer l'opération de resynchronisation et la stabilité du cluster Virtual SAN.

Problèmes de vCenter Server et de vSphere Web Client

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

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

Problèmes de gestion des machines virtuelles

  • Les tentatives d'ajout d'un périphérique USB via vSphere Client ou l'instance de vSphere Web Client peuvent échouer
    Les tentatives d'ajout d'un ou de plusieurs périphériques USB via vSphere Client et vSphere Web Client peuvent échouer si le pilote Intel USB 3.0 est utilisé.

    Ce problème est résolu dans cette version.
  • La prise d'un snapshot suspendu d'une machine virtuelle peut provoquer la non-définition de la valeur MOB du champ currentSnapshot
    Après avoir créé un snapshot suspendu et avoir parcouru le Managed Object Browser (MOB) de la machine virtuelle, la valeur MOB du champ currentSnapshot apparaît comme étant non définie. Pour afficher le champ currentSnapshot, accédez à Contenu -> dossier racine -> centre de données -> vmFolder -> vmname -> snapshot -> currentSnaphot.

    Ce problème est résolu dans cette version.
  • Plusieurs messages de journal de balisage opID sont journalisés rapidement dans le journal VMkernel
    Le monde d'assistance du balisage opID génère une importante quantité de messages de journal qui sont rapidement journalisés dans le journal VMkernel jusqu'à le remplir. Des journaux similaires aux suivants sont journalisés dans le journal VMkernel :

    cpu16:nnnnn)World: nnnnn: VC opID hostd-60f4 maps to vmkernel opID nnnnnnnn cpu16:nnnnn)World: nnnnn: VC opID HB-host-nnn@nnn-nnnnnnn-nn maps to vmkernel opID nnnnnnnn cpu8:nnnnn)World: nnnnn: VC opID SWI-nnnnnnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu22:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu14:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn cpu4:nnnnn)World: nnnnn: VC opID hostd-nnnn maps to vmkernel opID nnnnnnnn

    Ce problème est résolu dans cette version.
  • Prise en charge d'USB 3.0
    La prise en charge d'USB 3.0 a été ajoutée dans cette version, actuellement uniquement pour Apple Mac Pro.

Problèmes de High Availability et Fault Tolerance

Problèmes de vMotion et Storage vMotion

  • Impossible d'exécuter une interruption-reprise rapide ou Storage vMotion sur des machines virtuelles préaffectées
    Lorsque vous exécutez une interruption-reprise rapide (FSR, Fast Suspend-Resume) ou Storage vMotion sur des machines préaffectées, l'opération peut échouer si la validation de la réservation échoue lors du transfert de réservation de la machine virtuelle source vers la machine virtuelle de destination.

    Ce problème est résolu dans cette version.
  • Échec de Storage vMotion sur une machine virtuelle
    L'exécution de Storage vMotion sur une machine virtuelle peut échouer si vous avez configuré l'échange d'hôte local et si vous avez défini la valeur de checkpoint.cptConfigName dans le fichier vmx. Un message d'erreur semblable au suivant peut s'afficher :

    xxxx-xx-xxT00:xx:xx.808Z| vmx| I120: VMXVmdbVmVmxMigrateGetParam: type: 2 srcIp=<127.0.0.1> dstIp=<127.0.0.1> mid=xxxxxxxxxxxxx uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx priority=none checksumMemory=no maxDowntime=0 encrypted=0 resumeDuringPageIn=no latencyAware=no diskOpFile=
    <snip>
    xxxx-xx-xxT00:xx:xx.812Z| vmx| I120: VMXVmdb_SetMigrationHostLogState: hostlog state transits to failure for migrate 'to' mid xxxxxxxxxxxxxxxx


    Ce problème est résolu dans cette version.
  • Changed Block Tracking (CBT) est réinitialisé pour les disques virtuels RDM lors d'une migration à froid
    La migration à froid de différentes banques de données ne prend pas en charge la réinitialisation CBT pour les disques virtuels de mappages de périphériques bruts (RDM).

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

Problèmes de VMware Tools

  • Les tentatives de mise à niveau de VMware Tools sur une machine virtuelle Windows 2000 peuvent échouer
    Les tentatives de mise à niveau de VMware Tools sur une machine virtuelle Windows 2000 peuvent échouer et afficher un message d'erreur similaire au suivant, consigné dans le fichier vmmsi.log :

    Invoking remote custom action. DLL: C:\WINNT\Installer\MSI12.tmp, Entrypoint: VMRun
    VM_CacheMod. Return value 3.
    PROPERTY CHANGE: Deleting RESUME property. Its current value is '1'.
    INSTALL. Return value 3.

    Ce problème est résolu dans cette version.
  • Certains pilotes peuvent ne pas fonctionner comme prévu sur une machine virtuelle Solaris 11
    Sur un hôte ESXi 5.5, certains des pilotes installés sur le système d'exploitation Solaris 11 invité peuvent provenir de Solaris 10. et ne pas fonctionner comme prévu.

    Ce problème est résolu dans cette version.
  • Les tentatives de configuration de VMware Tools avec un nouveau noyau peuvent tronquer la liste de pilotes dans une entrée add_drivers
    Lorsque vous tentez de configurer VMware Tools avec un nouveau noyau à l'aide du script /usr/bin/vmware-config-tools.pl -k <kernel version> après la mise à jour du noyau avec Dracut, la liste de pilotes dans l'entrée add_drivers du fichier /etc/dracut.conf.d/vmware-tools.conf est tronquée. Ce problème se produit lorsque VMware Tools est transféré en amont dans le noyau.

    Ce problème est résolu dans cette version.
  • Impossible d'ouvrir telnet sur le système d'exploitation invité Windows 8 ou Windows Server 2012 après l'installation de VMware Tools
    Après l'installation de VMware Tools sur le système d'exploitation invité Windows 8 ou Windows Server 2012, les tentatives d'ouverture de telnet à l'aide de la commande start telnet://xx.xx.xx.xx échouent et affichent le message d'erreur suivant :

    Assurez-vous que la configuration de la machine virtuelle permet à l'invité d'ouvrir des applications hôtes.

    Ce problème est résolu dans cette version.
  • L'Observateur d'événements du système d'exploitation invité affiche des messages d'avertissement après l'installation de VMware Tools
    Après avoir installé VMware Tools, si vous essayez d'ouvrir une session Bureau à distance sur une machine virtuelle Windows, certains plug-ins peuvent afficher un message d'avertissement dans un journal des événements Windows. Le message d'avertissement indique l'échec de l'envoi des appels de procédure distante à l'hôte.

    Ce problème est résolu dans cette version.
  • Le service VMware Tools peut échouer sur une machine virtuelle Linux lors de l'arrêt.
    Sur une machine virtuelle Linux, le service VMware Tools vmtoolsd peut échouer lorsque vous arrêtez le système d'exploitation invité.

    Ce problème est résolu dans cette version.
  • La mise à niveau automatique de VMware Tools peut échouer lorsque la machine virtuelle est mise sous tension pour la première fois
    Lorsqu'une machine virtuelle est déployée ou clonée avec la personnalisation d'invité et que la stratégie de mise à niveau de VMware Tools est définie de sorte que la machine virtuelle puisse mettre à niveau VMware Tools automatiquement lors de la prochaine mise sous tension, la mise à niveau automatique de VMware Tools peut échouer lorsque la machine virtuelle est mise sous tension pour la première fois.

    Ce problème est résolu dans cette version.
  • La mise au repos d'opérations peut entraîner la panique d'une machine virtuelle Windows
    Les tentatives d'exécution d'un snapshot mis au repos sur une machine virtuelle exécutant Microsoft Windows 2008 ou une version ultérieure peuvent échouer et la machine virtuelle peut paniquer en affichant un écran bleu et un message d'erreur similaire au suivant :

    A problem has been detected and Windows has been shut down to prevent damage to your computer. If this is the first time you've seen this Stop error screen restart your computer. If this screen appears again, follow these steps:

    Disable or uninstall any anti-virus, disk defragmentation or backup utilities. Check your hard drive configuration, and check for any updated drivers. Run CHKDSK /F to check for hard drive corruption, and then restart your computer. (Un problème a été détecté et Windows a été arrêté pour éviter d'endommager votre ordinateur. Si ce message d'arrêt s'affiche pour la première fois, redémarrez votre ordinateur. Si ce message apparaît de nouveau, procédez comme suit : désactivez ou désinstallez votre logiciel anti-virus ainsi que vos utilitaires de défragmentation de disque et de sauvegarde. Exécutez CHKDSK /F pour détecter un éventuel endommagement du disque dur, puis redémarrez votre ordinateur).


    Pour plus d'informations, reportez-vous à l'article 2115997 de la base de connaissances.

    Ce problème est résolu dans cette version.
  • Une machine virtuelle peut cesser de répondre après une opération de snapshot sur une machine virtuelle Linux
    Lorsque vous tentez de créer un snapshot mis au repos d'une machine virtuelle Linux, la machine virtuelle peut échouer après l'opération de snapshot et nécessiter un redémarrage. Des messages d'erreur similaires au message suivant sont écrits dans le fichier vmware.log :

    TZ| vmx| I120: SnapshotVMXTakeSnapshotComplete: done with snapshot 'smvi_UUID': 0
    TZ| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 a échoué : Échec de la suspension de la machine virtuelle (40).
    TZ| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
    TZ| vmx| I120: Vix: [18631 guestCommands.c:1926]: Error VIX_E_TOOLS_NOT_RUNNING in
    MAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest


    Pour plus de détails, voir l'article 2116120 de la base de connaissances

    Ce problème est résolu dans cette version.
  • Nouveau problèmeles tentatives de consolidation de snapshot peuvent échouer avec l'erreur suivante : Unexpected signal: 11
    La consolidation ou la suppression d'un snapshot entraîne l'échec des machines virtuelles fonctionnant sur des hôtes VMware ESXi 5.5 Update 3 avec l'erreur suivante : Signal imprévu : 11. Un message de journal similaire au message suivant est écrit dans le fichier vmware.log :

    [YYYY-MM-DD] <time>Z| vcpu-0| I120: SNAPSHOT: SnapshotDiskTreeFind: Detected node change from 'scsiX:X' to ''.

    Pour plus de détails, voir l'article 2133118 de la base de connaissances

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

Problèmes connus

Les problèmes connus d'ESXi 5.5 sont regroupés comme suit :

Les nouveaux problèmes connus traités dans cette version sont indiqués par la mentionNouveau problème .

Problèmes d'installation et de mise à niveau

  • Mise à jourLa mise à jour de VMware vCenter Server 5.5 vers la version 5.5 U2 ou une version ultérieure diminue la taille maximale de segment de mémoire JVM
    Les tentatives de mise à jour de VMware vCenter Server 5.5 vers la version 5.5 U2 ou une version ultérieure diminuent la taille maximale de segment de mémoire JVM en raison d'un correctif appliqué au fichier wrapper.conf qui remplace le fichier de VMware Inventory Service, VMware Profile-Driven Storage Service et VMware VirtualCenter Web Management par les valeurs par défaut. Pour de plus amples détails, consultez l'article 2114669 de la base de connaissances

    Solution : Pour résoudre ce problème, modifiez la taille maximale de segment de mémoire en fonction de la taille de l'inventaire de vCenter Server.

  • Nouveau problèmeLes processus utilisateur du service VMware Tools peuvent ne pas fonctionner sur le SE Linux après l'installation du dernier module de VMware Tools
    Sur le système d'exploitation Linux, vous pouvez rencontrer des problèmes d'installation ou de mise à niveau de VMware Tools. De plus, les processus utilisateur du service VMware Tools (vmtoolsd) peuvent ne pas fonctionner après l'installation du dernier package de VMware Tools. Le problème se produit si votre version de glibc est antérieure à la version 2.5, comme SLES10sp4.

    Solution : Mettez à niveau Linux glibc vers la version 2.5 ou une version ultérieure.

  • Les tentatives d'obtention de tous les profils d'image peuvent échouer lors de l'exécution de la commande Get-EsxImageProfile dans vSphere PowerCLI
    Lorsque vous exécutez la commande Get-EsxImageProfile à l'aide de vSphere PowerCLI afin d'obtenir tous les profils d'image, une erreur similaire à la suivante s'affiche :

    PowerCLI C:\Windows\system32> Get-EsxImageProfile
    Get-EsxImageProfile : Le paramètre « nom » ne peut pas être une chaîne vide.
    Nom du paramètre : name
    At line:1 char:20
    + Get-EsxImageProfile <<<<
    + CategoryInfo : NotSpecified: (:) [Get-EsxImageProfile], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,VMware.ImageBuilder.Commands.GetProfiles


    Solution : Exécutez la commande Get-EsxImageProfile -name "ESXi-5.x*", qui inclut l'option -name, puis affichez tous les profils d'image créés lors de la session PowerCLI.

    Par exemple, si vous exécutez la commande Get-EsxImageProfile -name "ESXi-5.5.*", tous les profils d'image 5.5 similaires au suivant s'affichent :

    PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-EsxmageProfile -name "ESXi-5.5.*"

    Name Vendor Last Modified Acceptance Level
    ---- ------ ------------- ----------------
    ESXi-5.5.0-20140701001s-no-... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140302001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140604001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140401020s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20131201001s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
  • L'option d'installation simple échoue sous Windows Server 2012
    L'option d'installation simple échoue sous Windows Server 2012 si le système d'exploitation est configuré pour utiliser une adresse IP DHCP

    Solution : Configurez Windows 2012 Server pour utiliser une adresse IP statique.

  • Si vous utilisez la conservation VMFS avec Auto Deploy pour la mise en cache sans état ou l'installation avec état, aucune partition de vidage de mémoire n'est créée
    Lorsque vous utilisez Auto Deploy pour la mise en cache sans état ou une installation avec état sur un disque vierge, une table de partition MSDOS est créée. En revanche, aucune partition de vidage de mémoire n'est créée.

    Solution : Lorsque vous activez l'option de profil d'hôte Mise en cache sans état ou Installation avec état, sélectionnez Écraser VMFS, même lorsque vous effectuez l'installation sur un disque vierge. Lorsque vous procédez de cette manière, une partition de vidage de mémoire de 2.5 Go est créée.

  • Au cours d'une installation scriptée, ESXi est installé sur un SSD, même si vous utilisez l'option --ignoressd avec la commande installorupgrade
    Dans ESXi 5.5, l'option --ignoressd n'est pas prise en charge avec la commande installorupgrade. Si vous utilisez l'option --ignoressd avec la commande installorupgrade, le programme d'installation affiche un avertissement indiquant que cette combinaison n'est pas valide. Le programme d'installation continue à installer ESXi sur le disque SSD au lieu d'arrêter l'installation et d'afficher un message d'erreur.

    Solution : Pour utiliser l'option --ignoressd dans une installation scriptée d'ESXi, utilisez la commande install à la place de la commande installorupgrade.

  • Le délai de la purge du cache d'Auto Deploy peut générer l'application d'un profil d'hôte qui a été supprimé
    Lorsque vous supprimez un profil d'hôte, celui-ci n'est pas immédiatement purgé d'Auto Deploy. Tant que le profil d'hôte demeure dans le cache, Auto Deploy continue de l'appliquer. Toutes les règles qui s'appliquent au profil échouent uniquement après que le profil a été purgé du cache.

    Solution : vous pouvez déterminer si des règles utilisent un profil d'hôte supprimé au moyen de l'applet de commande PowerCLI Get-DeployRuleSet. Cette applet de commande affiche la chaîne deleted dans la liste itemlist de la règle. Vous pouvez ensuite exécuter l'applet de commande Remove-DeployRule pour supprimer la règle.

  • 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.
    2 banques de démarrage attendues, 0 trouvée

    Solution : Sélectionnez un autre disque à utiliser pour la mise en cache sans état ou supprimez le logiciel ESX du disque. Si vous supprimez le logiciel ESX, celui-ci devient indisponible.

  • L'installation ou le démarrage d'ESXi version 5.5.0 échoue sur des serveurs de fournisseurs d'Oracle America (Sun)
    Lorsque vous effectuez une nouvelle installation d'ESXi version 5.5.0 ou démarrez une installation d'ESXi version 5.5.0 existante sur des serveurs de fournisseurs Oracle America (Sun), la console du serveur affiche un écran vide au cours du processus d'installation ou lors du démarrage des versions existantes d'ESXi 5.5.0. Cela se produit car les serveurs de fournisseurs Oracle America (Sun) ont un indicateur HEADLESS défini dans la table ACPI FADT, même si ce ne sont pas des plates-formes administrées à distance.

    Solution : Lors de l'installation ou du démarrage d'ESXi 5.5.0, transmettez l'option de démarrage ignoreHeadless="TRUE".

  • Si vous utilisez des commandes ESXCLI pour mettre à niveau un hôte ESXi disposant de moins de 4 Go de RAM physique, la mise à niveau réussit, mais lors du redémarrage certaines opérations ESXi échouent
    ESXi 5.5 nécessite au minimum 4 Go de RAM physique. L'interface de ligne de commande ESXCLI ne vérifie pas avant la mise à niveau si les 4 Go de mémoire requis sont présents. La mise à niveau d'un hôte ne disposant pas de suffisamment de mémoire réussit, mais lorsque vous démarrez l'hôte ESXi 5.5 mis à niveau avec une RAM d'une capacité inférieure à 4 Go, certaines opérations risquent d'échouer.

    Solution : aucune. Vérifiez que l'hôte ESXi dispose de plus de 4 Go de RAM physique avant la mise à niveau vers la version 5.5.

  • Suite à la mise à niveau de vCenter Server Appliance 5.0.x vers la version 5.5, le démarrage de vCenter Server échoue si une instance de vCenter Single Sign-On externe est utilisée
    Si l'utilisateur choisit d'utiliser une instance de vCenter Single Sign-On externe au cours de la mise à niveau de vCenter Server Appliance 5.0.x vers la version 5.5, le démarrage de vCenter Server échoue après la mise à niveau. Dans l'interface de gestion du dispositif, vCenter Single Sign-On est répertorié comme non configuré.

    Solution : Procédez comme suit :

    1. Dans un navigateur Web, ouvrez l'interface de gestion de vCenter Server Appliance (https://adresse-dispositif:5480).
    2. Sur la page vCenter Server/Résumé, cliquez sur le bouton Arrêter le serveur.
    3. Sur la page vCenter Server/SSO, remplissez le formulaire avec les paramètres appropriés, puis cliquez sur Enregistrer les paramètres.
    4. Retournez sur la page Résumé et cliquez sur Démarrer le serveur.

  • Lorsque vous utilisez ESXCLI pour mettre à niveau un hôte ESXi 4.x ou 5.0.x vers la version 5.1 ou 5.5, les paramètres vMotion et Journalisation FT (Fault Tolerance Logging) de tous les groupes de ports VMKernel sont perdus après la mise à niveau
    Si vous utilisez la commande esxcli software profile update <options> pour mettre à niveau un hôte ESXi 4.x ou 5.0.x vers la version 5.1 ou 5.5, la mise à niveau réussit, mais les paramètres vMotion et Journalisation FT de tous les groupes de ports VMkernel sont perdus. vMotion et Journalisation FT reprennent alors le paramètre par défaut, désactivé.

    Solution : Effectuez une mise à niveau interactive ou scriptée, ou utilisez vSphere Update Manager pour mettre à niveau les hôtes. Si vous utilisez la commande esxcli, appliquez manuellement les paramètres vMotion et Journalisation FT au groupe de ports VMkernel concerné après la mise à niveau.

  • Lorsque vous mettez à niveau vSphere 5.0.x ou une version antérieure vers la version 5.5, les valeurs d'allocation de ressources système qui ont été définies manuellement sont réinitialisées et prennent les valeurs par défaut
    Dans vSphere 5.0.x et versions antérieures, vous modifiez les paramètres dans l'interface utilisateur d'allocation des ressources système en tant que solution temporaire. Vous ne pouvez pas rétablir la valeur par défaut de ces paramètres sans réinstaller complètement ESXi. Dans vSphere 5.1 et versions ultérieures, le comportement du système change, de telle sorte que la conservation de paramètres personnalisés d'allocation de ressources système peut générer des valeurs dont l'emploi est risqué. La mise à niveau réinitialise toutes les valeurs de ce type.

    Solution : aucune.

  • Les paramètres IPv6 de la carte réseau virtuelle vmk0 ne sont pas conservés après une mise à niveau de ESX 4.x vers ESXi 5.5
    Lorsque vous mettez à niveau vers ESXi 5.5 un hôte ESX 4.x sur lequel IPv6 est activé à l'aide de l'option --forcemigrate, l'adresse IPv6 de la carte réseau virtuelle vmk0 n'est pas conservée après la mise à niveau.

    Solution : aucune.

Problèmes de mise en réseau

  • Impossible d'utiliser l'adaptateur réseau PCNet32 avec le réseau opaque NSX
    Lorsque l'adaptateur réseau flexible PCNet32 est configuré avec une sauvegarde de réseau opaque NSX, cet adaptateur se déconnecte lors de la mise sous tension de la machine virtuelle.
  • Solution : aucune.

  • La mise à niveau vers ESXi 5.5 peut modifier la configuration IGMP de la pile TCP/IP pour la gestion des groupes de multidiffusion
    La version d'IGMP par défaut des interfaces de gestion est passée de la deuxième version d'IGMP à la troisième pour les hôtes ESXi 5.5 afin de gérer les groupes de multidiffusion. Par conséquent, lors de la mise à niveau vers ESXi 5.5, il se peut que l'interface de gestion repasse de la troisième version d'IGMP à la deuxième si elle reçoit une requête IGMP provenant d'une version précédente. Dans ce cas, vous recevrez probablement des messages d'erreur de conflit de version d'IGMP.

    Solution : Modifiez la version d'IGMP par défaut en modifiant l'intervalle de jonction entre les protocoles TCP/IP et IGMP dans l'option Configuration avancée.
  • Les routes statiques associées aux interfaces vmknic et les adresses IP dynamiques risquent de ne pas s'afficher après un redémarrage
    Après le redémarrage de l'hôte, les routes statiques associées à l'interface réseau VMkernel (vmknic) et à l'adresse IP dynamique risquent de ne pas s'afficher.
    Ce problème est dû à une condition de concurrence entre le client DHCP et la commande de restauration de routes. Il se peut que le client DHCP n'ait pas encore obtenu d'adresse IP pour vmknics lorsque l'hôte tente de restaurer les routes personnalisées lors du processus de redémarrage. Il se peut donc que la passerelle ne soit pas configurée et que les routes ne soient pas restaurées.

    Solution : Exécutez la commande esxcfg-route –r pour restaurer les routes manuellement.
  • Un hôte ESXi cesse de répondre après avoir été ajouté à vCenter Server par son adresse IPv6
    Lorsque vous ajoutez un hôte ESXi à vCenter Server au moyen d'une adresse de lien local IPv6 sous la forme fe80::/64, dans les instants qui suivent le nom de l'hôte apparaît en grisé et cesse de répondre à vCenter Server.

    Solution : Utilisez une adresse IPv6 valide qui n'est pas une adresse de lien local.

  • vSphere Web Client vous permet de configurer un nombre de fonctions virtuelles supérieur au nombre pris en charge par la carte réseau physique et n'affiche pas de message d'erreur
    Dans les paramètres SR-IOV d'un adaptateur physique, vous pouvez configurer un nombre de fonctions virtuelles supérieur à celui pris en charge par l'adaptateur. Par exemple, vous pouvez configurer 100 fonctions virtuelles sur une carte réseau n'en prenant en charge que 23 et aucun message d'erreur ne s'affiche. Un message vous invite à redémarrer l'hôte afin d'appliquer les paramètres SR-IOV. Après le redémarrage de l'hôte, la carte réseau est configurée avec autant de fonctions virtuelles que l'adaptateur prend en charge, ou 23 dans cet exemple. Le message qui vous invite à redémarrer l'hôte persiste alors qu'il ne devrait pas s'afficher.

    Solution : aucune.

  • 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 un hôte ESXi 5.1 ou versions ultérieures disposant de cartes réseau Intel ixgbe et si plusieurs fonctions virtuelles sont activées dans l'environnement, certaines machines virtuelles peuvent ne pas démarrer.
    Le fichier vmware.log contient des messages similaires aux messages suivants :
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Erreur
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] Erreur irrécupérable VMware ESX : (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] Un fichier journal est disponible dans "/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] Vous pouvez demander une assistance.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ Pour collecter des données à soumettre au support technique VMware, exécutez vm-support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] Nous répondrons en fonction du support auquel vous avez droit.

    Solution : Réduisez le nombre de fonctions virtuelles associées à la machine virtuelle concernée avant de la démarrer.

  • Sur un adaptateur réseau physique Emulex BladeEngine 3, un adaptateur réseau de machine virtuelle soutenu par une fonction virtuelle ne peut pas atteindre un adaptateur VMkernel qui utilise la fonction physique en tant que liaison montante
    Le trafic ne circule pas entre une fonction virtuelle et sa fonction physique. Par exemple, sur un commutateur soutenu par la fonction physique, une machine virtuelle qui utilise une fonction virtuelle sur le même port ne peut pas contacter un adaptateur VMkernel sur le même commutateur. Ce problème des adaptateurs physiques Emulex BladeEngine 3 est connu. Pour obtenir plus d'informations, contactez Emulex.

    Solution : Désactivez le pilote natif des périphériques Emulex BladeEngine 3 sur l'hôte. Pour plus d'informations, reportez-vous à l'article VMware KB 2044993.

  • ESXi Dump Collector ne parvient pas à envoyer le fichier noyau d'ESXi au serveur distant
    ESXi Dump Collector ne parvient pas à envoyer le fichier noyau d'ESXi si l'adaptateur VMkernel qui gère le trafic de Dump Collector est configuré sur un groupe de ports distribués disposant d'un groupe d'agrégation de liens (LAG) défini comme étant la liaison montante active. Un canal de port LACP est configuré sur le commutateur physique.

    Solution : Utilisez l'une des solutions suivantes :

    • Utilisez un vSphere Standard Switch pour configurer l'adaptateur VMkernel qui gère le trafic d'ESXi Dump Collector échangé avec le serveur distant.
    • Utilisez des liaisons montantes autonomes pour gérer le trafic du groupe de ports distribués sur lequel l'adaptateur VMkernel est configuré.
  • Si vous changez le nombre de ports dont dispose un commutateur vSphere standard ou un vSphere Distributed Switch à l'aide de vSphere Client, la modification n'est pas enregistrée, même après un redémarrage
    Si vous changez le nombre de ports dont dispose un commutateur vSphere standard ou un vSphere Distributed Switch sur un hôte ESXi 5.5 à l'aide de vSphere Client, le nombre de ports ne change pas même après le redémarrage de l'hôte.

    Lorsqu'un hôte qui exécute ESXi 5.5 redémarre, il dimensionne dynamiquement à la hausse ou à la baisse le nombre de ports de commutateurs virtuels. Le nombre de ports est basé sur le nombre de machines virtuelles que l'hôte peut exécuter. Vous n'avez pas à configurer le nombre de ports de commutateur sur ce type d'hôte.

    Solution : Aucune dans vSphere Client.

Problèmes de configuration de serveur

  • Nouveau problèmeUn matériel de carte réseau peut cesser de répondre avec un message d'erreur de matériel
    Le matériel d'une carte réseau peut occasionnellement cesser de répondre sous certaines circonstances avec le message d'erreur suivant dans les journaux de pilote :

    Detected Hardware Unit Hang

    Ce problème est observé sur certains nouveaux périphériques e1000e tels que 82579, i217, i218 et i219.

    Solution : Le matériel de la carte réseau se réinitialise après le problème.

  • Un problème de navigation dans le menu se produit lors de l'accès à l'interface utilisateur de contrôle direct à partir d'une console série
    Lors d'un accès à l'interface utilisateur de contrôle direct à partir d'une console série, les flèches vers le haut et vers le bas ne fonctionnent pas dans le menu et l'utilisateur est déconnecté de force de l'écran de configuration DCUI.

    Solution : Arrêtez le processus DCUI. Le processus DCUI va redémarrer automatiquement.

  • Des profils d'hôtes peuvent s'afficher par erreur comme étant conformes après la mise à niveau d'hôtes ESXi vers la version 5.5 Update 2 suivie de modifications dans la configuration d'hôte
    Si un hôte ESXi conforme à un profil d'hôte est mis à jour vers ESXi 5.5 Update 2, que des modifications de configuration d'hôte sont ensuite effectuées et que vous revérifiez la conformité de l'hôte avec le profil d'hôte, le profil est par erreur signalé comme étant conforme.

    Solution :
    • Dans vSphere Client, accédez au profil d'hôte concerné et exécutez Update profile From Reference Host.
    • Dans vSphere Web Client, accédez au profil d'hôte concerné, cliquez sur Copier les paramètres depuis l'hôte, sélectionnez l'hôte à partir duquel vous souhaitez copier les paramètres de configuration, puis cliquez sur OK.
  • La correction d'un profil d'hôte échoue avec vSphere Distributed Switch
    Des erreurs de correction peuvent se produire lors de l'application d'un profil d'hôte avec un vSphere Distributed Switch et si une machine virtuelle disposant de la fonction Fault Tolerance est dans un état hors tension sur un hôte qui utilise le commutateur distribué dans ce profil d'hôte.

    Solution : Déplacez les machines virtuelles hors tension vers un autre hôte pour que le profil d'hôte réussisse.

  • Le profil d'hôte reçoit des erreurs de conformité des paramètres du pare-feu lorsque vous appliquez un profil ESX 4.0 ou ESX 4.1 à un hôte ESXi 5.5.x
    Si vous extrayez un profil d'hôte ESX 4.0 ou ESX 4.1 pour tenter de l'appliquer à un hôte ESXi 5.5.x, la correction du profil aboutit. La vérification de conformité reçoit des erreurs de paramètres de pare-feu qui incluent les messages suivants :

    Ruleset LDAP not found
    Ruleset LDAPS not found
    Ruleset TSM not found
    Ruleset VCB not found
    Ruleset activeDirectorKerberos not found

    Solution : Aucune solution n'est nécessaire. Cela est normal car les paramètres du pare-feu d'un hôte ESX 4.0 ou ESX 4.1 sont différents de ceux d'un hôte ESXi 5.5.x.

  • La modification des paramètres de périphérique du BIOS pour un hôte ESXi peut créer des noms de périphériques non valides
    La modification d'un paramètre de périphérique du BIOS sur un hôte ESXi peut créer des noms de périphériques non valides si la modification entraîne un décalage des valeurs <segment:bus:device:function> attribuées aux périphériques. Par exemple, l'activation d'une carte réseau intégrée précédemment désactivée peut déplacer les valeurs <segment:bus:device:function> attribuées à d'autres périphériques PCI, si bien qu'ESXi change les noms attribués à ces cartes réseau. Contrairement aux versions précédentes d'ESXi, ESXi 5.5 tente de conserver les noms de périphériques lors de modifications de <segment:bus:device:function> si le BIOS de l'hôte fournit des informations d'emplacements de périphériques spécifiques. En raison d'un bogue dans cette fonction, des noms non valides, tels que vmhba1 et vmnic32, sont parfois générés.

    Solution : Le redémarrage de l'hôte ESXi une ou deux foix peut supprimer les noms de périphériques non valides et restaurer les noms d'origine. N'utilisez pas un hôte ESXi comportant des noms de périphériques non valides en production.

Problèmes de stockage

  • Les hôtes ESXi disposant de pilotes HBA peuvent cesser de répondre lors de l'expiration des signaux de pulsation VMFS envoyés aux banques de données
    Il est possible que les hôtes ESXi disposant de pilotes HBA cessent de répondre lors de l'expiration des signaux de pulsation VMFS envoyés aux banques de données. Dans ce cas, des messages similaires au suivant s'affichent :

    mem>2014-05-12T13:34:00.639Z cpu8:1416436)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L10" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0.2014-05-12T13:34:05.637Z cpu0:33038)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L4" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

    Ce problème se produit avec le pilote HBA lorsque l'une des E/S de disque élevée de la banque de données est connectée à l'hôte ESXi et que la gestion multivoie est activée au niveau cible au lieu du niveau HBA.

    Solution : Remplacez le pilote HBA par le pilote HBA asynchrone le plus récent.
  • Des tentatives d'opérations Storage vMotion en direct sur des machines virtuelles dotées de disques RDM peuvent échouer
    Des opérations Storage vMotion sur des machines virtuelles disposant de disques RDM peuvent échouer et les machines virtuelles peuvent sembler être hors tension. Les tentatives de mise sous tension de la machine virtuelle échouent et le message d'erreur suivant s'affiche :

    Échec du verrouillage du fichier

    Solution : aucune.
  • Des balises renommées sont manquantes dans l'assistant Modifier la stratégie de stockage VM
    Une stratégie de stockage de machine virtuelle peut inclure des règles basées sur des balises de banque de données. Si vous renommez une balise, la stratégie de stockage qui fait référence à cette balise ne met pas automatiquement à jour la balise et l'affiche comme manquante.

    Solution : Supprimez la balise marquée comme manquante de la stratégie de stockage de la machine virtuelle, puis ajoutez la balise renommée. Appliquez de nouveau la stratégie de stockage à toutes les entités périmées.

  • Une machine virtuelle ne peut pas être mise sous tension lorsque la taille de bloc de Flash Read Cache est définie sur 16 Ko, 256 Ko, 512 Ko ou 1 024 Ko.
    Une machine virtuelle configurée avec Flash Read Cache et une taille de bloc de 16 Ko, 256 Ko, 512 Ko ou 1 024 Ko ne peut pas être mise sous tension. Flash Read Cache prend en charge une taille de cache minimale de 4 Mo et maximale de 200 Go, et une taille de bloc minimale de 4 Ko et maximale de 1 Mo. Lorsque vous mettez sous tension une machine virtuelle, l'opération échoue avec les messages suivants :

    Une erreur a été reçue de l'hôte ESX lors de la mise sous tension de la VM.

    Échec du démarrage de la machine virtuelle.

    Échec de la mise sous tension du module DiskEarly.

    Échec de la configuration du disque scsi0:0.

    La machine virtuelle ne peut pas être activée avec un disque non configuré. Impossible d'attacher le cache vFlash : msg.vflashcache.error.VFC_FAILURE

    Solution : Configurez la taille de Flash Read Cache de la machine virtuelle et la taille du bloc.

    1. Cliquez avec le bouton droit sur la machine virtuelle et sélectionnez Modifier les paramètres.
    2. Sous l'onglet Matériel virtuel, développez le disque dur pour afficher les options du disque.
    3. Cliquez sur Avancé en regard du champ Flash Read Cache virtuel.
    4. Augmentez la réservation de taille du cache ou diminuez la taille du bloc.
    5. Cliquez sur OK pour enregistrer vos modifications.
  • L'extension personnalisée d'un fichier d'arborescence de pools de ressources enregistré ne peut pas être chargée dans vSphere Web Client
    Un message d'erreur DRS s'affiche dans la page de résumé de l'hôte.

    Lorsque vous désactivez DRS dans vSphere Web Client, vous êtes invité à enregistrer la structure des pools de ressources de sorte qu'elle puisse être rechargée ultérieurement. L'extension par défaut de ce fichier est .snapshot, mais vous pouvez sélectionner une autre extension. Si le fichier dispose d'une extension personnalisée, il s'affiche comme étant désactivé lorsque vous tentez de le charger. Ce comportement est uniquement observé sous ​​OS X.

    Solution : Changez l'extension en .snapshot pour le charger dans vSphere Web Client sous OS X.

  • Un message d'erreur DRS s'affiche dans la page de résumé de l'hôte
    Le message d'erreur DRS suivant s'affiche dans la page de résumé de l'hôte :

    Impossible d'appliquer les paramètres des ressources DRS à l'hôte. L’opération n’est pas autorisée dans l'état actuel. L’efficacité du DRS peut s’en trouver significativement réduite.

    Dans certaines configurations, une condition de concurrence peut entraîner la création d'un message d'erreur dans le journal qui n'est pas significatif ou exécutable. Cette erreur peut se produire si l'enregistrement d'une machine virtuelle est annulé lors de l'application des paramètres des ressources DRS.

    Solution : Ignorez ce message d'erreur.

  • La configuration de Flash Read Cache virtuel pour les VMDK de plus de 16 To échoue
    Flash Read Cache virtuel ne prend pas en charge les disques de machine virtuelle de plus de 16 To. Les tentatives de configuration de ces disques échouent.

    Solution : aucune.

  • Les machines virtuelles peuvent se mettre hors tension lorsque la taille du cache est reconfigurée
    Si vous reconfigurez incorrectement Flash Read Cache virtuel sur une machine virtuelle, en attribuant une valeur non valide par exemple, il se peut que la machine virtuelle se mette hors tension.

    Solution : Suivez les recommandations concernant la taille de mémoire cache recommandée dans la documentation Stockage vSphere.

  • La reconfiguration d'une machine virtuelle sur laquelle Flash Read Cache virtuel est activé peut échouer avec l'erreur Opération expirée
    Les opérations de reconfiguration nécessitent une très grande bande passante en entrée et en sortie. Lorsque vous exécutez une charge importante, de telles opérations peuvent expirer avant de s'achever. Ce comportement peut se produire si certains LUN sur l'hôte sont dans un état​​ APD (tous chemins hors service).

    Solution : Corrigez tous les états APD des hôtes et recommencez l'opération avec une plus petite charge d'entrée/sortie sur le LUN et l'hôte.

  • DRS n'effectue pas des opérations vMotion sur les machines virtuelles sur lesquelles Flash Read Cache virtuel est activé à des fins d'équilibrage de charge
    DDRS n'effectue pas des opérations vMotion sur les machines virtuelles sur lesquelles Flash Read Cache virtuel est activé à des fins d'équilibrage de charge

    Solution : DRS ne recommande pas ces machines virtuelles pour vMotion, sauf dans les cas suivants :

    • Pour évacuer un hôte qu'un utilisateur souhaite faire passer en mode de maintenance ou en mode Veille.
    • Pour corriger les violations des règles de DRS.
    • Si l'état d'utilisation des ressources de l'hôte est dans le rouge.
    • Si un ou plusieurs hôtes sont trop sollicités et que l'exigence de la machine virtuelle n'est pas respectée.
      Remarque : Vous pouvez éventuellement définir DRS pour qu'il ignore ces cas-là.
  • Des hôtes sont mis en veille lorsque la mémoire active des machines virtuelles est faible, mais que la mémoire consommée est élevée
    ESXi 5.5 introduit un changement dans le comportement par défaut de DPM conçu pour rendre cette fonction moins problématique, ce qui permet d'éviter la dégradation des performances des machines virtuelles lorsque la mémoire active est faible, mais que la mémoire consommée est élevée. La métrique de DPM est X%*IdleConsumedMemory + active memory. La variable X% est réglable et définie sur 25 % par défaut.

    Solution : Vous pouvez rétablir le comportement agressif de DPM qui existait dans les versions antérieures d'ESXi en définissant PercentIdleMBInMemDemand=0 dans les options avancées.

  • Lorsque vMotion est lancé par DRS, il peut échouer
    Lorsque DRS recommande vMotion pour les machines virtuelles disposant d'une réservation de Flash Read Cache virtuel, vMotion peut échouer, car la mémoire (RAM) disponible sur l'hôte cible est insuffisante pour gérer la réservation de Flash Read Cache des machines virtuelles.

    Solution : Suivez les recommandations concernant la configuration de Flash Read Cache documentées dans Stockage vSphere.
    Si vMotion échoue, procédez comme suit :

    1. Reconfigurez les tailles de bloc des machines virtuelles sur l'hôte cible et les machines virtuelles entrantes afin de réduire l'utilisation cible globale de la mémoire VMkernel sur l'hôte cible.
    2. Déplacez manuellement la machine virtuelle vers l'hôte cible à l'aide de vMotion pour vous assurer que le problème est résolu.
  • Vous ne pouvez pas voir les problèmes qui se produisent lors de la configuration Virtual Flash de périphériques SSD individuels
    La configuration des ressources Virtual Flash est une tâche qui s'exécute sur une liste de périphériques SSD. Une fois la tâche terminée pour tous les objets, vSphere Web Client la signale comme ayant abouti et vous pouvez ne pas être informé des problèmes de configuration qui se sont produits dans les périphériques SSD individuels.

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

    • Dans le panneau Tâches récentes, double-cliquez sur la tâche terminée.
      Tous les échecs de configuration s'affichent dans la section Événements associés de la boîte de dialogue Informations de tâche.
    • Vous pouvez également procéder comme suit :
      1. Sélectionnez l'hôte dans l'inventaire.
      2. Cliquez sur l'onglet Surveiller puis sur Événements.
  • Impossible d'obtenir des informations SMART concernant les SSD PCIe Micron sur l'hôte ESXi
    Vos tentatives d'utilisation de la commande esxcli storage core device smart get &#45d pour afficher les statistiques du périphérique SSD PCIe Micron échouent. Le message d'erreur suivant s'affiche :
    Erreur lors de l'obtention des paramètres SMART : IMPOSSIBLE d'ouvrir le périphérique

    Solution : aucune. Dans cette version, la commande esxcli storage core device smart ne prend pas en charge les SSD PCIe Micron.

  • ESXi n'applique pas la limite de bande passante configurée pour un disque virtuel SCSI dans le fichier de configuration d'une machine virtuelle
    Vous configurez les limites de bande passante et de débit d'un disque virtuel SCSI à l'aide d'un ensemble de paramètres dans le fichier de configuration de la machine virtuelle (.vmx). Par exemple, le fichier de configuration peut contenir les limites suivantes pour un disque virtuel scsi0:0 :
    sched.scsi0:0.throughputCap = "80IOPS"
    sched.scsi0:0.bandwidthCap = "10MBps"
    sched.scsi0:0.shares = "normal"

    ESXi n'applique pas la limite sched.scsi0:0.bandwidthCap au disque virtuel scsi0:0.

    Solution : Revenez à une version antérieure du planificateur d'E/S de disque à l'aide de vSphere Web Client ou de la commande avancée des paramètres du système esxcli.

    • Dans vSphere Web Client, modifiez le paramètre Disk.SchedulerWithReservation dans la liste des paramètres système avancés de l'hôte.
      1. Accédez à l'hôte.
      2. Dans l'onglet Gérer, sélectionnez Paramètres et sélectionnez Paramètres système avancés.
      3. Recherchez le paramètre Disk.SchedulerWithReservation en utilisant, par exemple, les zones de texte Filtrer ou Rechercher.
      4. Cliquez sur Modifier et définissez le paramètre sur 0.
      5. Cliquez sur OK.
    • Dans le service ESXi Shell de l'hôte, exécutez la commande de console suivante :
      esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0
  • Une machine virtuelle configurée avec Flash Read Cache ne peut pas être migrée hors d'un hôte si une erreur se produit dans le cache
    Une machine virtuelle configurée avec Flash Read Cache peut subir une erreur de migration si le cache est dans un état d'erreur et, par conséquent, inutilisable. Cette erreur entraîne l'échec de la migration de la machine virtuelle.

    Solution :

    1. Reconfigurez la machine virtuelle et désactivez le cache.
    2. Effectuez la migration.
    3. Réactivez le cache après la migration de la machine virtuelle.

    Il peut éventuellement également s'avérer nécessaire de mettre la machine virtuelle hors tension, puis sous tension pour corriger l'erreur dans le cache.

  • Vous ne pouvez pas supprimer le volume VFFS après la mise à niveau d'un hôte à partir d'ESXi 5.5 Beta
    Vous ne pouvez pas supprimer le volume VFFS après la mise à niveau d'un hôte à partir d'ESXi 5.5 Beta.

    Solution : Ce problème se produit uniquement lorsque vous effectuez une mise à niveau d'ESXi 5.5 Beta vers ESXi 5.5. Pour l'éviter, installez ESXi 5.5 au lieu de procéder à une mise à niveau. Si vous effectuez une mise à niveau à partir d'ESXi 5.5 Beta, supprimez le volume VFFS avant la mise à niveau.

  • Les améliorations de latence d'exécution attendues ne sont pas obtenues lorsque Flash Read Cache virtuel est activé sur des machines virtuelles disposant d'anciens systèmes d'exploitation Windows et Linux
    Flash Read Cache virtuel fournit des performances optimales lorsqu'il est dimensionné pour correspondre à l'ensemble de travail cible, et lorsque les systèmes de fichiers invités sont alignés sur une limite d'au moins 4 Ko. Flash Read Cache exclut les blocs désalignés pour éviter la mise en cache de blocs partiels. Ce comportement est généralement observé lorsque Flash Read Cache virtuel est configuré pour des VMDK de machine virtuelle avec Windows XP et des distributions Linux antérieures à la version 2.6. Dans ces cas de figure, un faible taux de réussite du cache avec une faible occupation du cache est observé, ce qui implique un gaspillage de la réservation de cache pour ce type de VMDK. Ce comportement n'est pas observé sur les machines virtuelles exécutant Windows 7, Windows 2008 et Linux 2.6 et distributions ultérieures, qui alignent leurs systèmes de fichiers sur une limite de 4 Ko pour garantir des performances optimales.

    Solution : Pour améliorer le taux de réussite du cache et garantir une utilisation optimale de la réservation de cache pour chaque VMDK, assurez-vous que le système de fichiers du système d'exploitation invité installé sur le VMDK est aligné sur une limite d'au moins 4 Ko.

Virtual SAN

  • Nouveau problèmeDisques Virtual SAN démontés et groupes de disques affichés comme montés dans le champ Statut opérationnel de l'interface utilisateur vSphere Client
    Après le démontage de disques Virtual SAN ou de groupes de disques à l'aide de la commande esxcli vsan storage diskgroup unmount dans l'interface de ligne de commande ou bien de manière automatique avec le service Virtual SAN Device Monitor lorsque des disques affichent de hautes latences de façon persistante, l'interface utilisateur vSphere Client affiche de manière incorrecte le champ Statut opérationnel comme Monté.

    Solution : Vérifiez le champ Santé qui affiche une valeur non intègre au lieu du champ Statut opérationnel.
  • Un hôte ESXi comprenant plusieurs groupes de disques VSAN peut ne pas afficher les statistiques de disque magnétique lors de l'exécution de la commande vsan.disks_stats
    Il est possible qu'un hôte ESXi comprenant plusieurs groupes de disques VSAN n'affiche pas les statistiques de disque magnétique (MD) lors de l'exécution de la commande vsan.disks_stats dans Ruby vSphere Console (RVC). L'hôte affiche uniquement les informations Solid-State Drive (SSD).

    Solution : aucune.
  • Des répertoires de machines virtuelles contiennent des fichiers d'échange (.vswp) en double
    Ce problème peut se produire si des machines virtuelles s'exécutant sur Virtual SAN ne sont pas correctement arrêtées et si vous effectuez une nouvelle installation d'ESXi et de vCenter Server sans effacer les données des disques Virtual SAN. Par conséquent, d'anciens fichiers d'échange (.vswp) se trouvent dans les répertoires de machines virtuelles qui ne sont pas correctement mises à l'arrêt.

    Solution : aucune.

  • Les tentatives d'ajout de plus de sept disques magnétiques à un groupe de disques Virtual SAN peuvent échouer avec un message d'erreur incorrect
    Un groupe de disques Virtual SAN prend en charge au maximum un disque SSD et sept disques magnétiques (HDD). Les tentatives d'ajout de disques magnétiques supplémentaires peuvent échouer avec un message d'erreur incorrect semblable au message suivant :

    Le nombre de disques est insuffisant.

    Solution : aucune.
  • Échec de nouvelle analyse survenant lors de l'ajout d'un disque Virtual SAN
    Lorsque vous ajoutez un disque Virtual SAN, une nouvelle analyse échoue en raison d'un échec de contrôle d'un volume non-Virtual SAN qui entraîne l'échec de l'opération.

    Solution : Ignorez l'erreur, car tous les disques sont correctement enregistrés.
  • Un disque dur (HDD) supprimé après la suppression de son disque SSD associé peut toujours être répertorié comme disque de stockage réclamé par Virtual SAN
    Si un disque SSD et son disque HDD associé sont supprimés d'une banque de données Virtual SAN et que vous exécutez la commande esxcli vsan storage list, le disque HDD supprimé demeure répertorié comme disque de stockage réclamé par Virtual SAN. Si le disque HDD est réinséré dans un autre hôte, il peut sembler faire partie de deux hôtes différents.

    Solution : Par exemple, si un disque SSD et un disque HDD sont retirés d'ESXi x, puis insérés dans ESXi y, effectuez les étapes suivantes pour empêcher que le disque HDD ne s'affiche comme partie intégrante d'ESXi x et d'ESXi y :
    1. Insérez le disque SSD et le disque HDD supprimés d'ESXi x, dans ESXi y.
    2. Désaffectez le disque SSD d'ESXi x.
    3. Exécutez la commande esxcfg-rescan -A.
       Le disque HDD et le disque SSD ne seront plus répertoriés sur ESXi x.
  • La section Utilisation du réseau Virtual SAN de la documentation de vSphere Storage indique que le nombre maximal de disques HDD par groupe de disques est de six. Toutefois, le nombre maximal autorisé de disques HDD est de sept.
  • Après un échec dans un cluster Virtual SAN, vSphere HA peut signaler plusieurs événements, certains trompeurs, avant de redémarrer une machine virtuelle
    L'agent principal de vSphere HA effectue plusieurs tentatives de redémarrage d'une machine virtuelle s'exécutant sur Virtual SAN après le signalement de son échec. Si la machine virtuelle ne peut pas être redémarrée immédiatement, l'agent principal contrôle l'état du cluster et fait une autre tentative lorsque les conditions indiquent qu'un redémarrage pourrait fonctionner. Pour les machines virtuelles exécutées sur un réseau Virtual SAN, l'agent principal vSphere HA dispose d'une logique d'application spéciale visant à détecter le changement possible d'accessibilité des objets d'une machine virtuelle, et tente un redémarrage dès qu'un changement d'accessibilité est probable. L'agent principal fait une tentative après chaque possibilité de changement d'accessibilité, et s'il ne parvient pas à mettre sous tension la machine virtuelle, abandonne et attend la prochaine possibilité de changement d'accessibilité.

    Après chaque tentative infructueuse, vSphere HA signale un événement indiquant que le basculement est un échec, et au bout de cinq tentatives infructueuses, signale que vSphere HA a cessé d'essayer de redémarrer la machine virtuelle du fait que le nombre maximal de tentatives de basculement a été atteint. Même après avoir signalé que l'agent principal vSphere HA a interrompu ses tentatives, il essaie à nouveau dès qu'une possibilité de changement d'accessibilité se présente.

    Solution : aucune.

  • La mise hors tension d'un hôte de réseau Virtual SAN provoque une actualisation de la vue Fournisseurs de stockage dans vSphere Web Client plus longue que prévu
    Si vous mettez hors tension l'hôtel de réseau Virtual SAN, la vue Fournisseurs de stockage peut apparaître vide. Le bouton Actualiser continue de tourner même si aucune information ne s'affiche.

    Solution : patientez au moins 15 minutes que la vue Fournisseurs de stockage se remplisse à nouveau. La vue s'actualise également lorsque vous mettez l'hôte sous tension.

  • Le réseau Virtual SAN signale une tâche infructueuse comme terminée
    Le réseau Virtual SAN peut signaler certaines tâches comme terminée même si elles sont été infructueuses en interne.

    Voici les conditions et les raisons correspondant aux erreurs :

    • Condition : Les utilisateurs tentent de créer un nouveau groupe de disques ou d'ajouter un nouveau disque à un groupe de disques existant alors que la licence du réseau Virtual SAN a expiré.
      Pile d'erreurs : Une erreur système générale s'est produite : Impossible d'ajouter le disque : Le VSAN ne dispose pas de licence sur cet hôte.
    • Condition : Les utilisateurs tentent de créer un groupe de disques avec un nombre de disques supérieur à celui pris en charge. Ou bien ils essaient d'ajouter de nouveaux disques à un groupe de disques existant alors que cela entraîne un nombre de disques supérieur à celui pris en charge par groupe de disque.
      Pile d'erreurs : Une erreur système générale s'est produite : Trop de disques.
    • Condition : Les utilisateurs tentent d'ajouter un disque à un groupe de disques comportant des erreurs.
      Pile d'erreurs : Une erreur système générale s'est produite : Impossible de créer la table de partition.

    Solution : après avoir identifié la raison de l'échec, corrigez-la et exécutez à nouveau la tâche

  • Les banques de données de réseau Virtual SAN ne peuvent pas stocker les fichiers d'échange locaux de l'hôte et système
    En général, vous pouvez placer les fichiers d'échange système ou locaux de l'hôte dans une banque de données. Toutefois, la banque de données de réseau Virtual SAN ne prend pas en charge les fichiers d'échange système et locaux de l'hôte. En conséquence, l'option d'interface utilisateur vous permettant de sélectionner la banque de données de réseau Virtual SAN en tant qu'emplacement pour les fichiers d'échange système ou locaux de l'hôte n'est pas disponible.

    Solution : dans l'environnement de réseau Virtual SAN, utilisez d'autres options prises en charge pour placer les fichiers d'échange système et locaux de l'hôte.

  • Une machine virtuelle de réseau Virtual SAN dans un cluster vSphere HA est signalée comme protégée avec vSphere HA, bien qu'elle ait été mise hors tension
    Ceci peut se produire lorsque vous mettez hors tension une machine virtuelle dont l'objet de base réside dans une banque de données de réseau Virtual SAN, et que l'objet de base n'est pas accessible. Ce problème survient si le choix de l'agent principal HA a lieu après que l'objet est devenu inaccessible.

    Solution :

    1. assurez-vous que l'objet de base est à nouveau disponible en vérifiant que l'objet est conforme à la règle de stockage spécifiée.
    2. Mettez la machine virtuelle sous tension, puis à nouveau hors tension.

    L'état devrait passer à non protégé.

  • L'objet de la machine virtuelle conserve l'état Périmé même après que l'action Appliquer de nouveau est déclenchée et exécutée avec succès
    Si vous modifiez le profil d'une machine virtuelle existante en raison de nouvelles exigences en matière de stockage, les objets de la machine virtuelle associés, de base ou sur disque, peuvent passer à l'état Périmé. Ceci se produit lorsque votre environnement actuel ne peut pas prendre en charge la reconfiguration des objets de machine virtuelle. L'utilisation de l'action Appliquer de nouveau ne change pas l'état.

    Solution : ajoutez des ressources additionnelles, sur des hôtes ou sur disque, au cluster Virtual SAN et rappelez l'action Appliquer de nouveau.

  • Le réseau Virtual SAN réclamant un disque automatique ne fonctionne pas comme espéré si vous obtenez sa licence après l'avoir activé
    Si vous activez le réseau Virtual SAN au mode automatique et que vous attribuez une licence ensuite, le réseau Virtual SAN échoue à réclamer les disques.

    Solution : changez le mode à Manuel, puis revenez à Automatique. Le réseau Virtual SAN réclamera les disques comme il se doit.

  • vSphere High Availability (HA) échoue à redémarrer une machine virtuelle lorsque le réseau Virtual SAN est partitionné
    Ceci se produit lorsque le réseau Virtual SAN utilise des adaptateurs VMkernel pour la communication entre les nœuds qui se trouvent sur le même sous-réseau que les autres adaptateurs VMkernel d'un cluster. Ce type de configuration peut entraîner une panne réseau et perturber la communication entre les nœuds du réseau Virtual SAN, tandis que la communication entre les nœuds de vSphere HA reste inchangée.

    Dans cette situation, l'agent principal HA peut détecter la défaillance d'une machine virtuelle, mais est dans l'impossibilité de la redémarrer. Par exemple, cela peut se produire lorsque l'hôte sur lequel l'agent principal s'exécute n'a pas accès aux objets de la machine virtuelle.

    Solution : vérifiez que les adaptateurs VMkernel utilisés par le réseau Virtual SAN ne partagent pas de sous-réseau avec ceux utilisés à d'autres fins.

  • Des répertoires de machines virtuelles contiennent des fichiers d'échange (.vswp) en double   
    Ce problème peut se produire si des machines virtuelles s'exécutant sur Virtual SAN ne sont pas correctement arrêtées et si vous effectuez une nouvelle installation d'ESXi et de vCenter Server sans effacer les données des disques Virtual SAN. Par conséquent, d'anciens fichiers d'échange (.vswp) se trouvent dans les répertoires de machines virtuelles qui ne sont pas correctement mises à l'arrêt.

    Solution : aucune.

  • Des machines virtuelles peuvent devenir inaccessibles en raison d'une latence réseau élevée
    Dans une installation de cluster Virtual SAN, si la latence réseau est élevée, certaines machines virtuelles peuvent devenir inaccessibles sur vCenter Server et vous ne pourrez plus mettre la machine virtuelle sous tension ou y accéder.

    Solution : Exécutez la commande RVC vsan.check_state -e -r.
  • Des opérations de machine virtuelle peuvent expirer en raison d'une latence réseau élevée
    Lorsqu'un contrôleur de stockage avec des files d'attente de faible profondeur est utilisé, une latence de réseau élevée peut provoquer l'expiration des opérations de machine virtuelle.

    Solution : Essayez de nouveau les opérations lorsque la charge du réseau est plus faible.
  • Des machines virtuelles peuvent être renommées en adoptant une version tronquée de leur chemin de fichiers vmx
    Si le fichier vmx d'une machine virtuelle est temporairement inaccessible, les machines virtuelles sont renommées en adoptant une version tronquée de leur chemin de fichiers vmx. Par exemple, la machine virtuelle peut être renommée en /vmfs/volumes/vsan:52f1686bdcb477cd-8e97188e35b99d2e/236d5552-ad93. La troncation peut supprimer la moitié de l'UUID du répertoire de base de la machine virtuelle, ce qui rend difficile le mappage de la VM renommée avec la VM d'origine, à partir du nom de VM uniquement.

    Solution : Exécutez la commande RVC vsan.fix_renamed_vms.

vCenter Server et vSphere Web Client

  • Impossible d'ajouter un hôte ESXi à un domaine Active Directory
    Le nom de domaine Active Directory peut ne pas s'afficher dans la liste déroulante Domaine sous l'option Sélectionner les utilisateurs et les groupes lorsque vous tentez d'attribuer des autorisations. En outre, l'option Paramètres de services d'authentification risque de ne pas afficher de contrôleur de domaine approuvé même lorsque l'annuaire Active Directory inclut des domaines approuvés.

    Solution :
    1. Redémarrer netlogond, lwiod, puis les démons lsassd.
    2. Connectez-vous à l'hôte ESXi à l'aide de vSphere Client.
    3. Dans l'onglet Configuration, cliquez sur Paramètres de services d'authentification.
    4. Actualisez l'écran pour afficher les domaines approuvés.

Problèmes de gestion des machines virtuelles

  • Impossible d'exécuter une migration à froid et Storage vMotion d'une machine virtuelle si le nom de fichier VMDK commence par core
    Les tentatives d'exécution d'une migration à froid et de Storage vMotion d'une machine virtuelle peuvent échouer si le nom de fichier VMDK commence par core. Dans ce cas, un message d'erreur similaire au suivant peut s'afficher :

    Une erreur système générale s'est produite : Erreur en nommant ou renommant un fichier VM.

    Des messages d'erreur similaires au suivant peuvent être consignés dans le fichier vpxd.log :

    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'commonvpxLro' opID=8BA11741-0000095D-86-97] [VpxLRO] -- FINISH task-internal-2471 -- -- VmprovWorkflow --
    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'Default' opID=8BA11741-0000095D-86-97] [VpxLRO] -- ERROR task-internal-2471 -- -- VmprovWorkflow: vmodl.fault.SystemError:
    mem> --> Result:
    mem> --> (vmodl.fault.SystemError){
    mem> --> dynamicType = ,
    mem> --> faultCause = (vmodl.MethodFault) null,
    mem> --> reason = "Error naming or renaming a VM file.",
    mem> --> msg = "",
    mem> --> }

    Ce problème se produit lorsque l'hôte ESXi identifie les fichiers VMDK de façon incorrecte avec un nom de fichier de noyau commençant par « core » au lieu du type de disque attendu.

    Solution : Assurez-vous que le nom de fichier VMDK de la machine virtuelle ne commence pas par « core ». Utilisez également l'utilitaire vmkfstools pour renommer le fichier VMDK afin de s'assurer que le nom de fichier ne commence pas par le mot « core ».
  • Les machines virtuelles exécutant des systèmes d'exploitation invités Windows 7 Enterprise 64 bits en français rencontrent des problèmes lors des opérations de clonage.
    Si vous disposez d'une machine virtuelle clonée exécutant Windows 7 Enterprise 64 bits avec les paramètres régionaux définis sur le français, la machine virtuelle se déconnecte du réseau et la spécification de personnalisation n'est pas appliquée. Ce problème se produit lorsque la machine virtuelle s'exécute sur un hôte ESXi 5.1, que vous l'avez clonée dans ESXi 5.5 et que vous avez mis à niveau la version de VMware Tools à la version disponible la plus récente de l'hôte 5.5.

    Solution : Mettez à niveau la compatibilité de la machine virtuelle vers ESXi 5.5 ou une version ultérieure, puis mettez à niveau VMware Tools à la version disponible la plus récente.

  • Les tentatives d'augmentation de la taille d'un disque virtuel sur une machine virtuelle en cours d'exécution échouent et renvoient une erreur.
    Si vous augmentez la taille d'un disque virtuel lorsque la machine virtuelle est en cours d'exécution, l'opération peut échouer et renvoyer l'erreur suivante :

    L'opération n'est pas prise en charge sur ce type de périphérique.

    Le problème peut survenir si vous tentez d'étendre le disque jusqu'à 2 To ou une taille supérieure. L'opération d'étendue à chaud permet d'augmenter la taille jusqu'à un maximum de 2 To seulement. Les disques virtuels SATA ne prennent pas en charge l'étendue à chaud, quelle que soit leur taille.

    Solution : Mettez la machine virtuelle hors tension pour étendre le disque virtuel jusqu'à 2 To ou une taille supérieure.

Problèmes liés à VMware HA et Fault Tolerance
  • Nouveau problèmeFault Tolerance (FT) n'est pas pris en charge sur les plates-formes Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT et Broadwell-DE
    Fault Tolerance (FT) n'est pas pris en charge sur les plates-formes Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT et Broadwell-DE. Les tentatives de mise sous tension d'une machine virtuelle peuvent échouer après que vous avez activé Fault Tolerance à processeur simple.

    Solution : aucune.

  • Si vous sélectionnez un hôte ESX/ESXi 4.0 ou 4.1 dans un cluster vSphere HA pour le basculement sur une machine virtuelle, il est possible que la machine virtuelle ne redémarre pas comme prévu.
    Lorsque vSphere HA redémarre une machine virtuelle sur un hôte ESX/ESXi 4.0 ou 4.1 différent de l'hôte sur lequel la machine virtuelle était exécutée à l'origine, une requête envoyée n'obtient pas de réponse. La machine virtuelle ne sera pas mise sous tension sur le nouvel hôte tant que vous n'aurez pas répondu manuellement à la requête dans vSphere Client.

    Solution : Répondez à la requête dans vSphere Client. Vous pouvez également attendre la fin du délai d'attente (par défaut, 15 minutes). Après ce délai, vSphere HA tente de redémarrer la machine virtuelle sur un autre hôte. Si l'hôte exécute ESX/ESXi 5.0 ou une version ultérieure, la machine virtuelle redémarre.

  • Si une opération vMotion sans stockage partagé échoue dans un cluster vSphere HA, il est possible que la machine virtuelle de destination soit enregistrée sur un hôte qui n'est pas celui qui était prévu.
    Une migration vMotion sans stockage partagé peut échouer car la machine virtuelle de destination ne reçoit pas le message de négociation qui permet de gérer le transfert du contrôle entre les deux machines virtuelles. Le protocole vMotion met hors tension les deux machines virtuelles (source et destination). Si les hôtes source et de destination se trouvent dans le même cluster et que vSphere HA a été activé, il se peut que la machine virtuelle de destination soit réenregistrée par vSphere HA sur un hôte qui n'est pas celui qui a été choisi comme cible pour la migration vMotion.

    Solution : Si vous souhaitez conserver la machine virtuelle de destination et l'enregistrer sur un hôte spécifique, déplacez la machine virtuelle de destination vers l'hôte de destination, de préférence avant de mettre la machine virtuelle sous tension.

Problèmes de matériel pris en charge
  • Les valeurs des capteurs Ventilateur, Alimentation, Tension et Courant s'affichent sous le groupe Autre de l'onglet État du matériel de vCenter Server
    Certaines valeurs de capteurs sont répertoriées dans le groupe Autre et non dans le groupe de la catégorie respective.

    Solution : aucune.

  • Des erreurs de l'unité de gestion de mémoire E/S (IOMMU) peuvent s'afficher lorsque le mappeur de débogage d'accès mémoire direct (DMA) est activé
    Le mappeur de débogage place les périphériques dans des domaines IOMMU pour permettre d'intercepter des accès mémoire de périphériques à des adresses n'ayant pas été explicitement mappées. Sur certains systèmes HP disposant d'un ancien microprogramme, des erreurs IOMMU peuvent se produire.

    Solution : Téléchargez les mises à niveau du microprogramme sur le site Web HP et appliquez-les.

    • Mettez à niveau le microprogramme du contrôleur iLO2 HP.
      La version 2.07, publiée en août 2011, résout le problème.
    • Mettez à niveau le microprogramme de HP Smart Array.
      Pour HP Smart Array P410, la version 5.14, publiée en janvier 2012, résout le problème.

Problèmes de VMware Tools

  • Impossible d'installer VMware Tools sur les systèmes d'exploitation invités Linux via l'exécution de la commande vmware-install.pl -d si VMware Tools n'a pas été précédemment installé
    Si VMware Tools n'est pas installé sur votre système d'exploitation invité Linux, toute nouvelle tentative d'installation de VMware Tools via l'exécution de la commande vmware-install.pl -d peut échouer.
    Ce problème se produit dans les systèmes d'exploitation invités suivants :
    • RHEL 7 et versions ultérieures
    • CentOS 7 et versions ultérieures
    • Oracle Linux 7 et versions ultérieures
    • Fedora 19 et versions ultérieures
    • SLES 12 et versions ultérieures
    • SLED 12 et versions ultérieures
    • openSUSE 12.2 et versions ultérieures
    • Ubuntu 14.04 et versions ultérieures
    • Debian 7 et versions ultérieures

    Solution : Il n'existe aucune solution favorisant le travail de commutation -default (-d). Cependant, vous pouvez installer VMware Tools sans le commutateur - default.
    Choisissez Oui lorsque la question Voulez-vous toujours exécuter ce programme d'installation hérité ? s'affiche dans le programme d'installation.

    Remarque : Cette version introduit un nouveau commutateur --force-install’(-f) pour l'installation de VMware Tools.
  • Un fichier disparaît après la mise à niveau de VMware Tools
    Le fichier deployPkg.dll qui se trouve sous C:\Program Files\Vmware\Vmware Tools\, reste introuvable après la mise à niveau de VMware Tools. Ceci se produit lors de la mise à niveau de la version 5.1 Update 2 vers la version 5.5 Update 1 ou version ultérieure et de la version 5.5 à 5.5 Update 1 ou version ultérieure.

    Solution : aucune.
  • L'utilisateur est déconnecté de force lors de l'installation ou de la désinstallation de VMware Tools par OSP
    Lors de l'installation ou de la désinstallation de modules VMware Tools sur des machines virtuelles RHEL (Red Hat Enterprise Linux) et CentOS qui avaient été installées à l'aide de modules spécifiques au système d'exploitation (OSP), l'utilisateur actuel est déconnecté de force. Ce problème se produit dans les machines virtuelles RHEL 6.5 64 bits, RHEL 6.5 32 bits, CentOS 6.5 64 bits et CentOS 6.5 32 bits.

    Solution :
    • Utilisez un shell sécurisé (SSH) pour installer ou désinstaller VMware Tools
      ou
    • L'utilisateur doit se reconnecter pour installer ou désinstaller les modules VMware Tools

Problèmes divers

  • Une opération de test de récupération SRM peut échouer avec une erreur
    Les tentatives d'exécution d'un test de récupération Site Recovery Manager (SRM) peuvent échouer et afficher un message d'erreur similaire au suivant :
    'Error - A general system error occurred: VM not found'.
    Lors de l'exécution simultanée de plusieurs opérations de test de récupération, la probabilité de rencontrer des messages d'erreur augmente.

    Solution : aucune. Cependant, ce problème n'est pas récurrent et il peut être évité si l'opération de test de récupération SRM est de nouveau effectuée.
>
check-circle-line exclamation-circle-line close-line
Scroll to top icon