VMware ESXi™ 5.5 Update 1 | 11 mars 2014 | Build 1623387

Dernière mise à jour : 25 mars 2014

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

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

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

  • VMware Virtual SAN Virtual SAN 5.5 est un nouveau niveau de stockage convergé par hyperviseur qui étend vSphere Hypervisor afin de regrouper les disques magnétiques (disques durs, HDD) et les disques SSD (Solid-State Drive) côté serveur. En regroupant les disques durs côté serveur et les disques SSD, Virtual SAN crée une banque de données partagée distribuée, conçue et optimisée pour les environnements virtuels. Virtual SAN est un produit autonome vendu séparément de vSphere et qui nécessite sa propre clé de licence 

  • 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. Pour afficher les notes de mise à jour des versions précédentes d'ESXi 5.5, consultez les Notes de mise à jour de VMware vSphere 5.5.

Internationalisation

VMware vSphere 5.5 Update 1 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.1 ajoute la prise en charge des versions ESXi 5.5 Update 1 et vCenter Server 5.5 Update 1.
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 avant d'activer Virtual SAN. vCenter Server doit également être mis à niveau vers la version 5.5 Update 1.

Versions test de Virtual SAN
La mise à niveau du cluster Virtual SAN de Virtual SAN Beta vers Virtual SAN 5.5 n'est pas prise en charge.
Désactivez Virtual SAN Beta et effectuez une nouvelle installation de Virtual SAN 5.5 pour les hôtes ESXi 5.5 Update 1. Si vous testez des versions Bêta de Virtual SAN, VMware recommande de recréer les données que vous souhaitez conserver de ces configurations sur vSphere 5.5 Update 1. Pour plus d'informations, reportez-vous à Conservation de machines virtuelles d'un cluster Virtual SAN Beta lors d'une mise à niveau vers vSphere 5.5 Update 1 (KB 2074147).

Compatibilité matérielle pour ESXi

Pour afficher la liste des processeurs, périphériques de stockage, baies SAN et périphériques E/S compatibles avec vSphere 5.5 Update 1, consultez les informations relatives à ESXi 5.5 Update 1 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 1, consultez les informations relatives à ESXi 5.5 Update 1 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 clients pour ESXi

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

 

Compatibilité des machines virtuelles pour ESXi

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

Notice d'installation pour 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é de la CPU hôte avec vSphere 5.5.x. Si le matériel de votre hôte n'est pas compatible, un écran violet apparaît et affiche un message d'information mentionnant l'incompatibilité. 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 d'accès de mise à niveau pris en charge pour la mise à niveau vers ESXi 5.5 Update 1 :

Produits livrables de mise à niveau

Outils de mise à niveau pris en charge

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

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

VMware-VMvisor-Installer-5.5.0.update01-1623387.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Oui

update-from-esxi5.5-5.5_update01.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • Interface de ligne de commande VMware vSphere

Non

Non

Yes*

Yes*

Oui

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

Non

Non

Non

Non

Oui


* Remarque : La mise à niveau d'ESXi 5.0.x ou d'ESXi 5.1.x vers ESXi 5.5 Update 1 avec update-from-esxi5.5-5.5_update01.zipest 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 1

Les déclarations de copyright et les licences applicables aux composants de logiciels en libre accès distribués dans vSphere 5.5 Update 1 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 concernant l'assistance 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-Update01 contient les bulletins individuels suivants :

ESXi550-201403201-UG : met à jour le fichier vib esx-base d'ESXi 5.5
ESXi550-201403202-UG : met à jour le fichier vib tools-light d'ESXi 5.5
ESXi550-201403203-UG : met à jour le fichier vib rste d'ESXi 5.5
ESXi550-201403204-UG : met à jour le fichier vib net-e1000e d'ESXi 5.5
ESXi550-201403205-UG : met à jour le fichier vib scsi-mpt2sas d'ESXi 5.5
ESXi550-201403206-UG : met à jour le fichier vib lsi-msgpt3 d'ESXi 5.5
ESXi550-201403207-UG : met à jour le fichier vib mtip32xx-native d'ESXi 5.5
ESXi550-201403208-UG : met à jour le fichier vib sata-ahci d'ESXi 5.5
ESXi550-201403209-UG : met à jour le fichier vib scsi-megaraid-sas d'ESXi 5.5
ESXi550-201403210-UG : met à jour le fichier vib net-igb d'ESXi 5.5
ESXi550-201403211-UG : met à jour le fichier vib net-tg3 d'ESXi 5.5

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

ESXi550-201403101-SG : met à jour le fichier vib esx-base d'ESXi 5.5
ESXi550-201403102-SG : met à jour le fichier vib tools-light d'ESXi 5.5

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

ESXi-5.5.0-20140302001-standard
ESXi-5.5.0-20140302001-no-tools

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

ESXi-5.5.0-20140301001s-standard
ESXi-5.5.0-20140301001s-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 CIM et API

  • Impossible d'obtenir les données du capteur IPMI
    Lorsque vous exécutez la commande exscli hardware ipmi sdr list, il se peut qu'une erreur concernant les ressources épuisées similaire à l'erreur suivante s'affiche :
    Aucun enregistrement, version incompatible ou échec de la lecture

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

    Ce problème est résolu dans cette version.
  • Impossible de désactiver les chiffrements faibles sur le port CIM 5989
    Pour désactiver les algorithmes CBC (Cipher Block Chaining) pour la conformité PCI (Payment Card Industry), vous devrez peut-être désactiver les chiffrements faibles sur le port CIM 5989. Cela n'est pas autorisé. Vous pouvez mettre à jour la configuration dans le fichier sfcb.cfgpour désactiver les chiffrements faibles à l'aide des commandes suivantes :

    # vi /etc/sfcb/sfcb.cfg
    sslCipherList: HIGH:!DES-CBC3-SHA
    # /etc/init.d/sfcbd-watchdog restart

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

  • L'opération de requête échoue lorsque vous interrogez CIM_System à l'aide d'EMC PowerPath
    Lorsque PowerPath interroge CIM_System sous /VMware/esxv2/, l'opération échoue et une erreur est signalée à partir du serveur CIM. L'erreur est similaire à l'exemple suivant :

    ThreadPool --- Échec de la mise en file d'attente de la demande. Nombre de demandes déjà mises en file d'attente trop important : vmwaLINUX
    ThreadPool --- Échec de la mise en file d'attente de la demande. Nombre de demandes déjà mises en file d'attente trop important : vmware_base, actives 5, mises en file d'attente 11 .\TreeViewHostDiscovery.cpp 611

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

  • Des vidages de mémoire à partir du fournisseur Ethernet se produisent lors de la mise à jour des données du capteur
    Lors de la mise à jour des données du capteur dans l'onglet Statut du matériel sur un serveur IBM x3650M3, des vidages de mémoire SFCB (Small Footprint CIM Broker) en provenance du fournisseur Internet se produisent. L'onglet Statut du matériel n'affiche pas les données, même après plusieurs tentatives.

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

Problèmes divers

  • Le disque RAM des fichiers d'interruption SNMP n'est pas créé lors du redémarrage de l'hôte
    Le disque RAM des fichiers d'interruption SNMP n'est pas créé lors du redémarrage de l'hôte ou des agents de gestion d'un hôte ESXi à partir de l'interface DCUI. Lorsqu'un objet est créé dans /var/spool/snmp(répertoire, fichier, lien ou autre) sur l'hôte ESXi, le disque RAM des fichiers d'interruption SNMP n'est pas créé au démarrage du service SNMP.

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

  • Un message d'erreur indiquant que le processus VMX risque d'échouer s'affiche lors de la mise hors tension d'une machine virtuelle
    Le processus VMX risque d'échouer si vous tentez de mettre une machine virtuelle hors tension.
    Un message d'erreur similaire à l'exemple suivant peut être écrit dans le fichier vmware.log :

    Unexpected signal: 11

    Ce problème est résolu dans cette version.
  • Les éléments de l'application JavaFX ne s'affichent pas correctement dans une machine virtuelle sur laquelle la 3D est activée
    Lorsque la 3D est activée dans les paramètres de la machine virtuelle, les composants de l'interface utilisateur de l'application JavaFX ne s'affichent pas correctement.

    Ce problème est résolu dans cette version.
  • Plusieurs disques virtuels configurés dans l'adaptateur virtuel lsilogic peuvent cesser de répondre lorsque l'adaptateur attend la fin d'une E/S sur toutes les cibles disponibles
    Lorsque l'adaptateur virtuel lsilogic exécute une commande de réinitialisation de cibles SCSI, il attend la fin des E/S sur toutes les cibles disponibles de l'adaptateur virtuel. Dans ce cas, les machines virtuelles comportant plusieurs disques virtuels et configurées dans un adaptateur virtuel lsilogic risquent de cesser de répondre.

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

Problèmes de mise en réseau

  • L'adaptateur VMXNET3 se réinitialise dans Windows Server 2008 R2 lors de modifications fréquentes du RSS
    Lorsque la mise à l'échelle côté réception (RSS) est activée sur une machine virtuelle Windows disposant de plusieurs vCPU, des messages NetPort s'affichent concernant des adresses MAC répétées indiquant que les ports sont en cours de désactivation, puis réactivés. Dans le fichier journal vmkernel, des messages similaires aux messages suivants s'affichent :

    2013-07-08T06:11:58.158Z cpu4:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:11:58.177Z cpu4:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24
    2013-07-08T06:12:46.191Z cpu1:337203)NetPort: 1424: disabled port 0x1000020
    2013-07-08T06:12:46.211Z cpu7:337203)NetPort: 1237: enabled port 0x1000020 with mac 00:50:56:9e:50:24

    Le fichier journal vmware.logdes machines virtuelles qui utilisent ces adresses MAC contient les événements correspondants similaires à :

    2013-07-08T06:18:20.175Z| vcpu-1| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:20.199Z| vcpu-1| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212
    2013-07-08T06:18:36.165Z| vcpu-6| Ethernet4 MAC Address: 00:50:56:9e:50:24
    2013-07-08T06:18:36.187Z| vcpu-6| VMXNET3 user: Ethernet4 Driver Info: version = 833450 gosBits = 2 gosType = 2, gosVer = 24848, gosMisc = 212

    Ce problème est résolu dans cette version. Le pilote réseau VMXNET3 est mis à jour dans cette version.

  • Un hôte ESXi 5.x disposant de machines virtuelles utilisant un adaptateur virtuel e1000 ou e1000e échoue avec un écran de diagnostic violet
    Un hôte ESXi obtient un écran de diagnostic violet signalant des erreurs pour E1000PollRxRing et E1000DevRx lorsque le tampon rxRing est saturé et que l'anneau Rx maximal est défini sur une valeur supérieure à 2. Le paquet Rx suivant traité par le deuxième anneau est NULL, ce qui provoque une erreur de traitement.
    L'écran de diagnostic violet affiche des entrées similaires aux entrées suivantes :

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

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

  • L'adresse IP affichée sur DCUI change lors d'une réinitialisation lorsque le trafic de gestion est activé sur plusieurs ports VMkernel
    Lorsque vous réinitialisez un réseau de gestion dans lequel le trafic de gestion est activé sur plusieurs ports VMkernel, l'adresse IP affichée sur l'interface utilisateur de la console directe change.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi affiche un écran de diagnostic violet avec une erreur exception 14
    Les hôtes ESXi dotés du module DvFilter peuvent afficher un écran de diagnostic violet et une trace de débogage similaire à la trace suivante :

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

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

  • Des hôtes ESXi risquent d'échouer avec un écran violet en raison de conditions concurrentielles dans une pile TCP/IP ESXi
    Des hôtes ESXi peuvent échouer avec un écran violet et afficher des messages d'erreur de ce type :

    2013-02-22T15:33:14.296Z cpu8:4104)@BlueScreen: #PF Exception 14 in world 4104:idle8 IP 0x4180083e796b addr 0x1
    2013-02-22T15:33:14.296Z cpu8:4104)Code start: 0x418007c00000 VMK uptime: 58:11:48:48.394
    2013-02-22T15:33:14.298Z cpu8:4104)0x412200207778:[0x4180083e796b]ether_output@<None>#<None>+0x4e stack: 0x41000d44f360
    2013-02-22T15:33:14.299Z cpu8:4104)0x4122002078b8:[0x4180083f759d]arpintr@<None>#<None>+0xa9c stack: 0x4100241a4e00

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

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

  • Le pilote de l'interface réseau Intel e1000e peut cesser de répondre sur le trafic reçu (RX)
    Le pilote de l'interface réseau Intel e1000e peut cesser de répondre sur le trafic reçu (RX).

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

  • Des hôtes ESXi peuvent échouer avec un écran violet lorsque la fonctionnalité de vérification de l'intégrité du réseau est activée
    Lorsque la fonction de vérification de l'intégrité du réseau est activée et qu'elle traite de nombreux paquets de vérification de l'intégrité, la fonction L2Echo peut ne pas être en mesure de gérer un niveau élevé de trafic réseau et les hôtes ESXi peuvent échouer et afficher un écran de diagnostic violet similaire à celui-ci :

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


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

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

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

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

  • Le délestage de segmentation TCP (TSO) des cartes réseau tg3 peut provoquer l'échec des hôtes ESXi
    Lorsque la fonctionnalité TSO est activée dans le pilote tg3, les cartes réseau tg3 peuvent altérer les données qui y transitent.

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

    Ce problème est résolu dans cette version. Le pilote réseau VMXNET3 est mis à jour dans cette version.

Problèmes de sécurité

  • Mise à jour de libxslt
    Le module ESXi userworld libxslt est mis à jour.
  • Mise à jour du démon NTP
    Le démon NTPest mis à jour pour résoudre un problème de sécurité.
    Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué le nom CVE-2013-5211 à ce problème.
    Remarque : Une solution à ce problème est traitée dans l'article KB 2070193.
  • Mise à jour des modules glibc
    Le module ESXi glibc-2.5 a été mis à jour pour résoudre un problème de sécurité.
    Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué le nom CVE-2013-4332 à ce problème.

Problèmes de configuration de serveur

  • Utilisation incohérente de la CPU signalée par l'outil de ligne de commande esxtop
    Sur les ordinateurs sur lesquels l'hyperthreading est activé, le taux d'utilisation du cœur vSphere Client de la CPU représente le double de la valeur trouvée lors de l'utilisation du cœur esxtop. Ce problème est résolu dans cette version.

  • Unité incorrecte reçue à la commande esxcli network nic coalesce get
    L'unité reçue en entrant la commande esxcli network nic coalesce getcorrespond à des millisecondes. Les microsecondes représentent l'unité appropriée.

    Ce problème est résolu dans cette version.
  • Impossible d'accéder à la banque de données VMFS ou à certains fichiers
    Il se peut que vous notiez l'absence de la banque de données du système de fichiers de machine virtuelle (VMFS) dans l'onglet Banque de données de vCenter Server ou un événement similaire à l'événement suivant affiché dans l'onglet Événements :

    XXX esx.problem.vmfs.lock.corruptondisk.v2 XXX ou Au moins un verrouillage sur disque corrompu a été détecté sur le volume {1} ({2}). D’autres zones du volume peuvent également être endommagées.

    Le message suivant est consigné dans le fichier vmkernel.log :

    [lockAddr 36149248] Invalid state: Owner 00000000-00000000-0000-000000000000 mode 0 numHolders 0 gblNumHolders 4294967295ESC[7m2013-05-12T19:49:11.617Z cpu16:372715)WARNING: DLX: 908: Il se peut que le volume 4e15b3f1-d166c8f8-9bbd-14feb5c781cf ("XXXXXXXXX") soit endommagé sur le disque. Corrupt lock detected at offset 2279800: [type 10c00001 offset 36149248 v 6231, hb offset 372ESC[0$

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

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

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

  • Les disques ESXi locaux sont indisponibles après l'installation d'EMC PowerPath sur le serveur HP
    Après l'installation d'EMC PowerPath, les banques de données locales ne sont réclamées par aucun plug-in de chemins multiples (MPP). Lorsque les règles de réclamation sont exécutées, si un chemin correspond à une règle de réclamation, celui-ci est proposé au MPP. Dans vSphere 5.1, si le MPP renvoie un échec, ce chemin fera alors l'objet d'une correspondance avec d'autres règles de réclamation et s'il y a correspondance, le chemin sera proposé au MPP dans ces règles de réclamation. Si un chemin n'est réclamé par aucun MPP, il est proposé au NMP en raison de la règle passe-partout.

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

  • L'hôte ESXi affiche un écran de diagnostic violet avec une erreur
    Pendant un appel VSI (VMkernel System Information) du ps programme userworld, le VMkernel rencontre une erreur lorsque la liste d'instances envoyée au noyau est corrompue. Le problème survient si la valeur numParamsest trop élevée et que le noyau essaie d'accéder au tableau de cet index. Un écran de diagnostic violet avec un suivi arrière s'affiche, similaire à l'exemple suivant :

    2013-09-06T00:35:49.995Z cpu11:148536)@BlueScreen: #PF Exception 14 in world 148536:ps IP 0x418004b31a34 addr 0x410019463308

    PTEs:0x4064ffe023;0x2080001023;0x100065023;0x0;

    2013-09-06T00:35:49.996Z cpu11:148536)Code start: 0x418004800000 VMK uptime: 2:11:35:53.448
    2013-09-06T00:35:49.996Z cpu11:148536)0x412250e1bd80:[0x418004b31a34]VSIVerifyInstanceArgs@vmkernel#nover+0xf3 stack: 0x410009979570
    2013-09-06T00:35:49.997Z cpu11:148536)0x412250e1bdd0:[0x418004b31bbb]VSI_CheckValidLeaf@vmkernel#nover+0xca stack: 0x8c8
    2013-09-06T00:35:49.998Z cpu11:148536)0x412250e1be40:[0x418004b32222]VSI_GetInfo@vmkernel#nover+0xb1 stack: 0x4100194612c0
    2013-09-06T00:35:49.999Z cpu11:148536)0x412250e1beb0:[0x418004ca7f31]UWVMKSyscallUnpackVSI_Get@<None>#<None>+0x244 stack: 0x412250e27000
    2013-09-06T00:35:50.000Z cpu11:148536)0x412250e1bef0:[0x418004c79348]User_UWVMKSyscallHandler@<None>#<None>+0xa3 stack: 0x0
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf10:[0x4180048a8672]User_UWVMKSyscallHandler@vmkernel#nover+0x19 stack: 0xffea48d8
    2013-09-06T00:35:50.001Z cpu11:148536)0x412250e1bf20:[0x418004910064]gate_entry@vmkernel#nover+0x63 stack: 0x0
    2013-09-06T00:35:50.004Z cpu11:148536)base fs=0x0 gs=0x418042c00000 Kgs=0x0

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

  • Un hôte ESXi cesse de répondre et se déconnecte de vCenter Server
    L'hôte ESXi cesse de répondre et se déconnecte de vCenter Server. De plus, la DCUI et la connexion SSH à l'hôte ne fonctionnent pas en raison d'une perte de mémoire dans le service lsassd à cause de domaines hors ligne dans l'environnement Active Directory.

    Ce problème est résolu dans cette version.
  • Autoriser les machines virtuelles à afficher le numéro de série de l'hôte physique
    Les machines virtuelles ne peuvent pas refléter les numéros de série des hôtes ESXi physiques.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi affiche des valeurs incorrectes pour le compteur système resourceCpuAllocMax
    Lorsque vous tentez de récupérer la valeur des compteurs système resourceCpuAllocMax et resourceMemAllocMax sur le système hôte, l'hôte ESX renvoie des valeurs incorrectes. Ce problème se produit lorsque vSphere Client est connecté à un système vCenter Server.

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

  • L'affichage de la vitesse de l'adaptateur de bus hôte (HBA) Fibre Channel est toujours incorrect
    L'affichage de la vitesse de l'adaptateur de bus hôte (HBA) Fibre Channel à zéro est toujours incorrect pour certains hôtes ESXi dans le MOB (Managed Object Browser).

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

  • Plusieurs hôtes ESXi peuvent cesser de répondre dans vCenter Server
    Lorsque de nombreuses demandes d'URL HTTP GET /folderparallèles sont envoyées à hostd, le service hostd échoue. Il est alors impossible de rajouter l'hôte à vCenter Server. Un message d'erreur similaire au suivant peut s'afficher :
     
    Unable to access the specified host, either it doesn't exist, the server software is not responding, or there is a network problem.
     
    Ce problème est résolu dans cette version.
  • Les machines virtuelles dont la version matérielle est antérieure à 10 ne peuvent pas se connecter au réseau NVS
    Les machines virtuelles dont la version matérielle est antérieure à 10 ne peuvent pas se connecter au réseau NVS (NSX Virtual Switch). Cependant, les machines virtuelles disposant de la version matérielle 4 ou ultérieure peuvent se connecter au réseau NVS.

    Ce problème est résolu dans cette version.
  • L'hôte échoue et génère un vidage hostd-worker
    L'hôte ESXi 5.5 peut générer un vidage hostd-worker après avoir détaché le disque iSCSI logiciel qui est connecté à vmknic dans vDS. Ce problème survient lorsque vous essayez de récupérer les informations les plus récentes sur l'hôte.

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

  • La suppression à chaud d'un disque non persistant partagé est plus longue lorsque le disque est attaché (ou partagé) avec une autre machine virtuelle sous tension
    Lorsque vous ajoutez des disques en lecture seule non persistants partagés à une machine virtuelle, celle-ci peut mettre plus de temps à exécuter la tâche de suppression de disque.

    Ce problème est résolu dans cette version.
  • Le provisionnement et la personnalisation d'une machine virtuelle peuvent entraîner la perte de la connexion réseau
    Lorsque vous provisionnez et personnalisez une machine virtuelle à partir d'un modèle sur un vDS avec des ports éphémères, celle-ci peut perdre la connexion au réseau.

    Des messages d'erreur similaires à celui-ci peuvent être affichés dans les fichiers journaux :

    2013-08-05T06:33:33.990Z| vcpu-1| VMXNET3 user: Ethernet1 Driver Info: version = 16847360 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 0
    2013-08-05T06:33:35.679Z| vmx| Msg_Post: Error
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetPortID] Unable to get dvs.portId for ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.mac.cantGetNetworkName] Impossible d’obtenir networkName ou devName pour ethernet0
    2013-08-05T06:33:35.679Z| vmx| [msg.device.badconnect] Failed to connect virtual device Ethernet0.
    2013-08-05T06:33:35.679Z| vmx|

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

  • Des fichiers d'interruption sont créés dans l'hôte ESXi lorsque l'agent SNMP est interrompu
    Le protocole de gestion de réseau simple (SNMP) crée des fichiers d'interruption ( .trp) dans le dossier /var/spool/snmpde l'hôte ESXi lorsque l'agent SNMP est interrompu. Lorsque le répertoire /var/spool/snmpn'est pas supprimé avec succès par l'agent SNMP arrêté, l'hostd crée des fichiers d'interruption (.trp) dans /var/spool/snmp. L'hôte manque alors d'inodes et s'affiche comme étant déconnecté dans vCenter Server. Vous pouvez donc être dans l'incapacité d'exécuter une tâche sur l'hôte.

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

  • Il manque GuestNicInfo pour une machine virtuelle sous tension sur un hôte démarré dans un environnement PXE (Preboot Execution Environment)
    GuestNicInfo et GuestStackInfo ne sont pas disponibles sur une machine virtuelle sous tension lorsque VMware Tools est installé et en cours d'exécution.

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

  • L'exécution de commandes ESXCLI ou l'utilisation d'outils de contrôle qui reposent sur l'agent SNMP peut entraîner une perte de connexion à l'hôte ESXi
    Lorsque vous exécutez des commandes ESXCLI ou si vous utilisez des outils de contrôle qui reposent sur des données provenant de l'agent SNMP dans ESXi, la connexion à l'hôte ESXi peut être perdue en raison de l'échec du service hostd.

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

  • Les options bandwidthCap et throughputCap d'un hôte ESXi peuvent ne pas fonctionner sur le système d'exploitation invité
    Sur un hôte ESXi, lorsque les options bandwidthCap et throughputCap sont définies simultanément, il se peut que l'option de limitation d'E/S ne fonctionne pas sur les machines virtuelles. Cela se produit en raison d'une comparaison logique incorrecte lors de la définition de l'option de régularisation dans le planificateur SCSI.

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

  • Interruptions SNMP non reçues sur les hôtes sur lesquels SNMP est activé et lorsque des fournisseurs CIM tiers sont installés sur le serveur
    Lorsque l'état du matériel surveillé change sur un hôte ESXi sur lequel SNMP est activé et que des fournisseurs CIM tiers sont installés, il se peut que vous ne receviez pas d'interruptions SNMP. Des messages semblables à celui-ci s'affichent dans le fichier syslog :

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

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

  • L'hostd échoue lors de la tentative de réinitialisation du masque CPUID sur une machine virtuelle
    Lors de la tentative de réinitialisation du masque CPUID sur une machine virtuelle, l'hostd cesse de répondre lorsque la valeur de SetRegisterInfoest NULL ou une chaîne vide.

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

  • L'installation d'ESXi échoue avec l'erreur « UnboundLocalError »
    L'installation d'ESXi échoue avec l'erreur : « UnboundLocalError : variable locale « isLocalOnlyAdapter » référencée avant attribution"

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

  • Le profil hôte ne parvient pas à appliquer le profil de stockage réseau (NAS) par intermittence
    L'hôte ne parvient pas à appliquer NasStorageProfileet est dans l'impossibilité de quitter le mode de maintenance lors de l'échec de l'application.

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

  • Les tentatives d'application d'un profil d'hôte complexe peuvent entraîner une expiration de délai d'attente
    Lorsque vous appliquez un profil d'hôte complexe, par exemple un profil d'hôte contenant un grand nombre de groupes de ports et de banques de données, le délai d'attente de l'opération peut expirer avec un message d'erreur similaire au message suivant :

    2013-04-09T15:27:38.562Z [4048CB90 info 'Default' opID=12DA4C3C-0000057F-ee] [VpxLRO] -- ERROR task-302 -- -- vim.profile.host.profileEngine.HostProfileManager.applyHostConfig:

    vmodl.fault.SystemError :
    --> Résultat :
    --> (vmodl.fault.SystemError) {
    --> dynamicType = ,
    --> faultCause = (vmodl.MethodFault) null,
    --> reason = "",
    --> msg = "Une erreur système générale s'est produite : ",
    --> }

    Le délai d'attente par défaut du service hostd est de 10 minutes. Dans la mesure où applyHostConfig n'est pas une tâche progressive, le service hostd ne peut pas faire la distinction entre une tâche ayant échoué et une tâche de longue durée pendant le délai d'attente de hosttd. Par conséquent, le service hostd signale que la tâche applyHostConfig a échoué.

    Ce problème est résolu dans cette version en installant un délai d'attente de 30 minutes dans le cadre de l'objet géré HostProfileManager. Cependant, ce problème risque de se produire à nouveau si vous tentez d'appliquer un profil d'hôte volumineux et que la tâche peut dépasser le délai d'attente maximal de 30 minutes. Pour résoudre ce problème, réappliquez le profil d'hôte.

    Remarque : Le déclencheur réel de l'expiration du délai d'attente dépend de la complexité du profil d'hôte.
  • VMKernel échoue lorsqu'un moniteur de machine virtuelle renvoie un numéro de page machine non valide
    Lorsque VMX transmet une valeur VPN pour lire une page, VMKernel ne parvient pas à trouver un numéro de page machine valide pour cette valeur VPN ce qui entraîne l'échec de l'hôte avec un écran de diagnostic violet.

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

Problèmes de stockage

  • La sortie des données de performance esxtop peut s'afficher sous forme de zéros
    Lorsque la sortie des données de performance esxtop est redirigée vers un fichier au format CSV, les valeurs de esxtop.csvcollectées en mode de traitement par lot peuvent être remplacées par zéro. Le fichier esxtop.csvpeut afficher des valeurs d'E/S similaires aux suivantes :

    "09/04/2013 22:00:00","1251.43","4.89","7.12","1839.62","7.19","4.99","1273.05","4.97","7.08""09/04/2013
    22:00:10","1283.92","5.02","7.06","1875.14","7.32","4.89","1290.37","5.04","7.07""09/04/2013
    22:00:20","1286.49","5.03","7.03","1914.86","7.48","4.87","1320.55","5.16","6.90""09/04/2013
    22:00:31","1222.56","4.78","7.44","1775.23","6.93","5.21","1253.87","4.90","7.28""09/04/2013
    22:00:41","1269.87","4.96","7.15","1847.40","7.22","4.97","1267.62","4.95","7.13""09/04/2013
    22:00:51","1291.36","5.04","7.05","1857.97","7.26","4.96","1289.40","5.04","7.08""09/04/2013
    22:01:01","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:11","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:22","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013
    22:01:32","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00""09/04/2013 22:01:42","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00","0.00"


    Ce problème survient lorsque les messages VSCSI non valides sont définis sur Truepar défaut plutôt que sur False.

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

Problèmes de Virtual SAN

  • Vous ne pouvez pas débrancher à chaud les disques de stockage réclamés par le pilote AHCI (Advance Host Controller Interface) lorsque les disques font partie d'un groupe de disques de réseau Virtual SAN
    Le pilote AHCI réclame les données ou les disques de stockage SSD connectés aux ports SATA sur la carte mère ou au moyen d'adaptateurs de stockage activés pour l'AHCI. Si les disques sont réclamés par le pilote AHCI et font partie d'un groupe de disques de réseau Virtual SAN, vous ne pouvez pas les débrancher à chaud de l'hôte ESXi. Dans le cas contraire, l'hôte sera dans l'impossibilité de détecter les disques après que vous les avez reconnectés.

    Ce problème est résolu dans cette version.
  • Lors d'un débranchement à chaud de SSD, l'hôte ESXi peut rencontrer un échec.
    Si vous tentez de débrancher à chaud un SSD, votre hôte ESXi peut cesser de répondre et échouer.

    Ce problème est résolu dans cette version.
  • Le réseau Virtual SAN peut ne pas détecter le disque que vous débranchez et rebranchez à chaud
    Si vous débranchez à chaud un disque SSD ou non-SSD, le réseau Virtual SAN peut être dans l'impossibilité de le détecter après une rebranchement à chaud.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi forme un cluster à nœud simple et ne peut pas rejoindre un cluster Virtual SAN existant
    Ceci se produit lorsque le vmknic configuré pour un réseau Virtual SAN ne dispose pas d'adresse IP lorsque le réseau Virtual SAN est activé. Si l'hostd n'a pas démarré lorsque le vmknic sur lequel le réseau Virtual SAN est activé obtient une adresse IP, l'hôte peut former un cluster à nœud simple.

    Ce problème est résolu dans cette version.
  • Un nœud échoue à passer au mode de maintenance avec l'option Évacuation totale des données, si l'utilisation des capacités actuelles du cluster Virtual SAN est supérieure à 70 pour cent
    Ceci se produit lorsque la suppression d'un nœud du cluster entraîne une utilisation des capacités supérieure à 70 pour cent du cluster Virtual SAN. Les capacités du cluster correspondent à l'espace du cluster Virtual SAN.

    Ce problème est résolu dans cette version.
  • Le clonage d'une machine virtuelle avec une règle de stockage transfère toujours celle-ci à la machine virtuelle cible, même si vous n'en avez pas besoin.
    Lorsque vous clonez une machine virtuelle associée à une règle de stockage et que vous choisissez de ne pas attribuer celle-ci à la machine virtuelle cible, le processus de clonage réussit. Toutefois, la règle de stockage de la machine virtuelle d'origine peut être utilisée pour configurer la machine virtuelle cible. De ce fait, celle-ci peut utiliser des ressources supplémentaires involontairement avec la banque de données du réseau Virtual SAN.

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

Problèmes de vCenter Server et de vSphere Web Client

  • Le calcul des statistiques de performance du débit des disques virtuels peut être incorrect d'un facteur 1024
    Le calcul des statistiques de performance du débit de disques virtuels est mesuré par erreur en octets par seconde.

    Ce problème a été résolu dans cette version en modifiant l'unité de mesure en kilo-octets par seconde.

Problèmes de gestion des machines virtuelles

  • La machine virtuelle ne parvient pas à démarrer à partir d'un CD ou d'un DVD lorsque l'option Legacy Floppy Disk est désactivée dans le BIOS
    Le démarrage de la machine virtuelle peut échouer si vous désactivez l'option Legacy Floppy Disk dans le BIOS. Ce problème se produit lorsque vous effectuez la procédure ci-dessous :
    1. Créez une machine virtuelle sans système d'exploitation.
    2. Utilisez Paramètres de machine virtuelle pour configurer le CD ou le DVD de manière à établir une connexion à un fichier d'image ISO ou un lecteur physique pour installer le système d'exploitation invité.
    3. Désactivez Legacy Floppy Disk dans le BIOS.
    Après la désactivation de Legacy Floppy Disk dans le BIOS, la machine virtuelle produit deux signaux sonores et son démarrage échoue.

    Ce problème est résolu dans cette version.
  • Les tentatives d'exportation d'une machine virtuelle au format OVF échouent avec erreur de délai d'expiration
    Lorsque vous tentez d'exporter une machine virtuelle utilisant un système de fichiers Ext 2ou Ext 3et ayant une grande séquence de blocs vides sur le disque, par exemple un disque secondaire vide de 210 Go et plus, au format OVF (Open Virtualization Format), l'opération expire.

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

Problèmes de VMware HA et Fault Tolerance

  • Les tentatives de configuration de la haute disponibilité (HA) peuvent échouer avec un message d'erreur indiquant que l'agent principal de HA est introuvable
    Il se peut que vous soyez dans l'impossibilité de configurer la haute disponibilité (HA). Des messages d'erreur similaires au message suivant peuvent être écrits dans le fichier vmware.log :

    vpxd-1967.log:2013-04-06T01:35:02.156+09:00 [07220 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_GD for 120 seconds
    vpxd-1968.log:2013-04-06T05:02:55.991+09:00 [07320 warning 'DAS'] [FdmManager::ReportMasterChange] VC couldn't find a master for cluster HA_ID for 120 seconds


    Ce problème se produit lorsque la fonction hostd manque de sessions. Des messages d'erreur similaires au message suivant sont écrits dans le fichier hostd.log :

    Limite du nombre de sessions SOAP atteinte.

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

Problèmes de mise à niveau et d'installation

  • L'installation d'ESXi échoue avec l'erreur UnboundLocalError
    L'installation d'ESXi échoue avec l'erreur : UnboundLocalError: variable locale 'isLocalOnlyAdapter' référencée avant attribution

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

Problèmes de VMware Tools

  • Après des tentatives d'annulation de l'enregistrement du pilote VSS, vCenter Protect Agent peut afficher un message d'avertissement lors de la mise à jour de VMware Tools
    Lorsque vous tentez de mettre à jour VMware Tools sur un système d'exploitation invité Windows avec un build de VMware Tools disposant d'un fichier comreg.exenon signé et annulez l'enregistrement d'un pilote VSS, vCenter Protect Agent peut afficher un message d'avertissement similaire au message suivant :

    comreg.exe a tenté de s'exécuter

    Ce problème est résolu dans cette version par l'inclusion du fichier VMware signé comreg.exe.
  • Microsoft Office ne parvient pas à enregistrer des fichiers dans un répertoire partagé
    Lorsque vous enregistrez des fichiers à partir d'une application Microsoft Office 2007 ou Microsoft Office 2010 dans un répertoire partagé d'une machine virtuelle protégée par VMware vShield Endpoint et une solution antivirus sans agent, vous obtenez des messages d'erreur similaires aux messages suivants :

    Le fichier est en cours d'utilisation. Réessayez plus tard.
    Impossible d'enregistrer le fichier à cet emplacement.

    Les fichiers enregistrés dans le partage sont vides et ont une taille de 0 Ko.

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

  • Erreurs lors de la mise à jour de VMware Tools sur RHEL 6.2
    Une erreur similaire à l'exemple suivant peut s'afficher pendant la mise à jour d'une version antérieure de VMware Tools vers la version 9.0.5 d'une machine virtuelle RHEL 6.2 (Red Hat Linux Enterprise) utilisant RPM (Red Hat Package Manager) :

    Erreur : Module : kmod-vmware-tools-vsock-9.3.3.0-2.6.32.71.el6.x86_64.3.x86_64 (RHEL6-isv)
    Nécessite : vmware-tools-vsock-common = 9.0.1
    Installé : vmware-tools-vsock-common-9.0.5-1.el6.x86_64 (@/vmware-tools-vsock-common-9.0.5-1.el6.x86_64)
    vmware-tools-vsock-common = 9.0.5-1.el6
    Disponible : vmware-tools-vsock-common-8.6.10-1.el6.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 8.6.10-1.el6
    Disponible : vmware-tools-vsock-common-9.0.1-3.x86_64 (RHEL6-isv)
    vmware-tools-vsock-common = 9.0.1-3

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

  • Le service VMware Tools échoue lors de la récupération d'informations de machine virtuelle avec l'argument --cmd
    Lorsque vous exécutez une requête vmtoolsdtelle que vmtoolsd --cmd "info-get guestinfo.ovfEnv", le service VMware Tools peut échouer. Ce problème connu survient sur VMware Tools, versions 9.0.1 et 9.0.5.

    Ce problème est résolu dans cette version.
  • Des modules de noyau pré-intégrés sont manquants pour Oracle Linux 5.x
    VMware Tools est mis à jour pour fournir à Oracle Linux 5.x les modules de noyau pré-intégrés 2.6.39-200/400.

    Ce problème est résolu dans cette version.
  • Lorsque vous installez VMware Tools à l'aide de modules spécifiques du système d'exploitation, le répertoire /tmp/vmware-root se remplit de fichiers vmware-db.pl.*
    Lorsque vous installez VMware Tools à l'aide d'OSP, vous pouvez observer une augmentation du nombre de fichiers journaux dans le répertoire /tmp/vmware-root. Ce problème survient sur les machines virtuelles SUSE Linux Enterprise Server 11 Service Pack 2 et Red Hat Enterprise Linux 6.

    Ce problème est résolu dans cette version.
  • vSphere Web Client risque de ne pas pouvoir détecter que VMware Tools est installé pour les systèmes d'exploitation invités Linux
    vSphere Web Client risque de ne pas pouvoir détecter que VMware Tools est installé pour les systèmes d'exploitation invités Linux.
    Des messages d'erreur similaires au message suivant peuvent s'afficher sous l'onglet Résumé dans vSphere Web Client :
    VMware Tools n'est pas installé sur cette machine virtuelle.

    Ce problème est résolu dans cette version.
  • L'application Maxon Cinema 4D peut échouer en mode vSGA
    Maxon Cinema 4D peut échouer en mode vSGA (Virtual Shared Graphics Acceleration) lorsque vous tentez de cliquer sur un élément d'interface utilisateur de l'application en raison d'un problème du pilote VMware OpenGL.

    Ce problème est résolu dans cette version.
  • Des messages d'erreurs relatifs au rendu peuvent s'afficher lorsque que vous exécutez l'application Petrel 3D dans une machine virtuelle
    Des erreurs peuvent se produire lors de l'exécution de l'application Petrel 3D dans une machine virtuelle en raison d'un problème de pilote graphique OpenGL.

    Ce problème est résolu dans cette version.
  • L'utilisateur est déconnecté de force des machines virtuelles Windows 8 et Windows 8.1 lors de la mise à niveau de VMware Tools
    Lors de la mise à niveau de VMware Tools sur des machines virtuelles Windows 8 et Windows 8.1, l'utilisateur est automatiquement déconnecté de celles-ci.

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

Problèmes connus

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

Problèmes d'installation
  • 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.

  • L'installation sur un LUN du logiciel iSCSI échoue avec l'erreur Expecting 2 bootbanks, found 0
    L'erreur complète associée à ce problème est :
    Erreur (voir le journal pour plus d'info):
    Expecting 2 bootbanks, found 0.

    Ce problème se produit lorsque le premier adaptateur réseau est configuré pour démarrer à partir d'un iBFT iSCSI. Les paramètres IP d'iBFT sont utilisés pour configurer le port réseau VMkernel qui est créé pour accéder au disque de démarrage iSCSI. Dans ce cas, le port représente le port réseau de gestion, car le premier adaptateur est utilisé pour le trafic de gestion.

    Lorsque l'installation est effectuée à environ 90 pour cent, le programme d'installation reconfigure l'interface de gestion avec DHCP. Les paramètres IP d'iBFT sont alors perdus et la connexion TCP avec la cible de démarrage iSCSI est rompue.

    Solution : Effectuez l'une des actions suivantes :

    • Si plusieurs adaptateurs réseau sont disponibles, utilisez le deuxième adaptateur réseau pour accéder au disque de démarrage iSCSI.
    • Si un seul adaptateur réseau est disponible, configurez iBFT pour utiliser DHCP. La cible iSCSI doit se trouver sur le réseau de gestion. Si la cible iSCSI se trouve sur un autre sous-réseau, la passerelle VMkernel par défaut peut acheminer le trafic de gestion et le trafic iSCSI.

     

  • 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 --ignoressdn'est pas prise en charge avec la commande installorupgrade. Si vous utilisez l'option --ignoressdavec 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 --ignoressddans 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 deleteddans la liste itemlistde la règle. Vous pouvez ensuite exécuter l'applet de commande Remove-DeployRulepour 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.
    Expecting 2 bootbanks, found 0

    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 HEADLESSdé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".

Problèmes de mise à niveau

  • Le nom du correctif de l'ID de correctif ESXi550-Update01 s'affiche sous la forme « see description* »
    Lors de l'utilisation de vSphere Update Manager, il se peut que le nom du correctif du bundle de cumul ESXi 5.5 Update 1, ID de correctif ESXi550-Update01, affiche see description, (No KB).
    Cette absence du nom du correctif n'a aucune incidence fonctionnelle. Vous trouverez les détails du bundle de cumul dans l'article KB 2065832.

    Solution : Aucune
  • 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 : Suivez les étapes :

    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) 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 n'ont pas été définies manuellement 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 risquées. 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 vCenter Single Sign-On
  • L'erreur 29107 s'affiche pendant la mise à niveau de vSphere Web Client de 5.1 Update 1a vers 5.5
    Pendant une mise à niveau de vSphere Web Client de la version 5.1 Update U1a vers la version 5.5, l'erreur 29107 s'affiche si le service vCenter Single Sign-On qui était utilisé avant la mise à niveau dispose de la configuration Single Sign-On haute disponibilité.

    Solution : Recommencez la mise à niveau. Vous pouvez exécuter le programme d'installation et sélectionner Installation personnalisée pour mettre uniquement à niveau vSphere Web Client.

  • Impossible de changer le mot de passe d'administrator@vsphere.local dans le menu déroulant de vSphere Web Client
    Lorsque vous vous connectez au serveur vCenter Single Sign-On à partir de vSphere Web Client, vous pouvez effectuer un changement de mode passe dans le menu déroulant. Lorsque vous vous connectez en tant qu'administrator@vsphere.local, l'option Changer mot de passe est grisée.

    Solution :

    1. Sélectionnez l'onglet Gérer, puis sélectionnez vCenter Single Sign-On > Utilisateurs et groupes.
    2. Cliquez avec le bouton droit sur l'utilisateur administrateur et cliquez sur Modifier l'utilisateur.
    3. Changez le mot de passe.

     

Problèmes de mise en réseau

  • 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 les adresses IP dynamiques 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 –rpour 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 : Aucun

  • 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.logcontient des messages similaires aux messages suivants :
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] 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 : Procédez au choix comme suit :

    • 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

  • Un problème de navigation dans le menu se produit lors d'un l'accès à l'interface utilisateur de console directe (DCUI) à partir d'une console série*
    Lors d'un accès à l'interface utilisateur de console directe (DCUI) à partir d'une console série, les touches fléchées 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 1 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 1 et que des modifications de configuration d'hôte sont ensuite effectuées, si 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.

  • Des messages de non-conformité s'affichent après l'utilisation d'Auto Deploy pour une mise en cache sans état ou des installations avec état sur USB
    Après la modification d'un profil d'hôte pour activer la mise en cache sans état sur le disque USB de l'ordinateur hôte, le profil d'hôte reçoit des erreurs de conformité lors de la tentative de correction. L'hôte redémarre et la mise en cache se termine. Après la vérification de la conformité, l'erreur de conformité suivante s'affiche :
    L'état de l'hôte ne correspond pas à la spécification

    Solution : Aucune solution n'est nécessaire. Le message est incorrect.

  • 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

  • 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 dans l'état 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 de modification d'une stratégie de stockage de machine virtuelle
    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 .snapshotpour 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 : Aucun

  • 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 Operation 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=0dans 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 -dpour 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 smartne 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.bandwidthCapau 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.SchedulerWithReservationdans 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.SchedulerWithReservationen 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

  • 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 similaire au message suivant :

    Le nombre de disques est insuffisant.

    Solution : Aucun
  • É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 associé (SSD) 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 le nombre maximum de disques HDD par groupe de disques est de six. Cependant, 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 application logique 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 avant d'abandonner et d'attendre 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 maximum 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évue
    Si vous mettez hors tension un hôte de réseau Virtual SAN, la vue Fournisseurs de stockage peut ê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 étant terminée*
    Le réseau Virtual SAN peut signaler certaines tâches comme étant terminées même si elles ont échoué 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 : A general system error occurred: 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 : A general system error occurred: Trop de disques.
    • Condition : Les utilisateurs tentent d'ajouter un disque à un groupe de disques comportant des erreurs.
      Pile d'erreurs : A general system error occurred: 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 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 Virtual SAN d'un cluster vSphere HA est signalée comme protégée par 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 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.

  • La réclamation automatique de disques pour Virtual SAN ne fonctionne pas comme prévu si vous attribuez la licence à Virtual SAN après l'avoir activé*
    Si vous activez le réseau Virtual SAN en mode automatique et que vous attribuez ensuite une licence, le réseau Virtual SAN ne parvient pas à réclamer des 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) ne parvient pas à 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, ceci 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 survenir 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 : Aucun

vCenter Server et vSphere Web Client

  • Impossible d'ajouter un hôte ESXi à un domaine Active Directory*
    Vous pouvez observer qu'un nom de domaine Active Directory ne s'affiche pas 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
  • 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 de VMware HA et Fault Tolerance
  • 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 supporté
  • 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 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

  • 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 dans une RHEL (Red Hat Enterprise Linux) et de machines virtuelles CentOS qui avaient été installées à l'aide de modules spécifiques d'un 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