VMware ESXi 5.1 Update 1 | 25 avril 2013 | Build 1065491

Dernière mise à jour : 25 avril 2013

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

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

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

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

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

Versions antérieures d'ESXi 5.1

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

Internationalisation

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

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

Compatibilité et installation

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

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

vSphere Client et vSphere Web Client sont empaquetés avec vCenter Server et le fichier ZIP contenant les modules. Vous pouvez installer un client ou les deux à partir de l'assistant d'installation de VMware vCenter™.

Compatibilité ESXi, vCenter Server et VDDK

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

Compatibilité matérielle pour ESXi

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

La liste des processeurs pris en charge a été élargie dans cette version. Pour déterminer les processeurs compatibles avec cette version, reportez-vous au Guide de compatibilité de VMware.

Compatibilité des systèmes d'exploitation clients pour ESXi

Pour déterminer quels systèmes d'exploitation clients sont compatibles avec ESXi 5.1 Update 1, consultez les informations sur ESXi 5.1 Update 1 du Guide de compatibilité de VMware.

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

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

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

Compatibilité des machines virtuelles pour ESXi

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

Notice d'installation pour cette version

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

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

Migration de solutions tierces

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

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

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

Mises à niveau pour cette version

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

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

  • M ise à niveau interactive au moyen d'une image ISO du programme d'installation d'ESXi sur CD-ROM, DVD ou lecteur flash USB. Vous pouvez lancer le programme d'installation d'ESXi 5.1 Update 1 à partir d'un CD-ROM, DVD ou lecteur flash USB afin d'effectuer une mise à niveau interactive. Cette méthode convient à un petit nombre d'hôte.
  • Exécution d'une mise à niveau scriptée. Vous pouvez mettre à niveau ou migrer des hôtes ESX/ESXi 4.x et des hôtes ESXi 5.0.x et ESXi 5.1 vers ESXi 5.1 Update 1 en appelant un script de mise à jour pour effectuer une mise à niveau efficace et autonome. Les mises à niveau scriptées constituent un moyen efficace pour déployer plusieurs hôtes. Vous pouvez utiliser un script pour mettre à niveau ESXi à partir d'un CD-ROM ou d'un DVD, ou en effectuant un démarrage PXE du programme d'installation.

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

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

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

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

ESX4.0 Update 3
ESX 4.0 Update 4

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

ESXi 4.0 Update 3
ESXi 4.0 Update 4

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

ESX 4.1 Update 3

 

ESXi 4.1 :
Inclut
ESXi 4.1 Update 1

ESXi 4.1 Update 2
ESXi 4.1 Update 3

ESXi 5.0 :
Inclut
ESXi 5.0 Update 1

ESXi 5.0 Update 2

ESXi 5.1

VMware-VMvisor-Installer-5.1.0.update01-xxxxxx.x86_64.iso

 

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

Oui

Oui

Oui

Oui

Oui

Oui

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

Non

Non

Non

Non

Non

Oui

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

VMware vCenter Update Manager avec ligne de base de correctifs

Non

Non

Non

Non

Non

Oui

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

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

Remarques concernant l'assistance produit

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

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

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

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

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

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

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

Correctifs contenus dans cette version

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

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

ESXi510-201304201-UG : Met à jour le fichier vib esx-base d'ESXi 5.1
ESXi510-201304202-UG : Met à jour le fichier vib tools-light d'ESXi 5.1
ESXi510-201304203-UG : Met à jour le fichier vib net-ixgbe d'ESXi 5.1
ESXi510-201304204-UG : Met à jour le fichier vib ipmi-ipmi-si-drv d'ESXi 5.1
ESXi510-201304205-UG : Met à jour le fichier vib net-tg3 d'ESXi 5.1
ESXi510-201304206-UG : Met à jour le fichier vibs misc-drivers d'ESXi 5.1
ESXi510-201304207-UG : Met à jour le fichier vib net-e1000e d'ESXi 5.1
ESXi510-201304208-UG : Met à jour le fichier vib net-igb d'ESXi 5.1
ESXi510-201304209-UG : Met à jours le fichier vib scsi-megaraid-sas d'ESXi 5.1
ESXi510-201304210-UG : Met à jour le fichier vib net-bnx2 d'ESXi 5.1


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

ESXi510-201304101-SG : Met à jour le fichier vib esx-base d'ESXi 5.1
ESXi510-201304102-SG : Met à jour le fichier vib tools-light d'ESXi 5.1
ESXi510-201304103-SG - Met à jour le fichier vib net-bnx2x d'ESXi 5.1
ESXi510-201304104-SG - Met à jours le fichier vib esx-xserver d'ESXi 5.1


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

ESXi-5.1.0-20130402001-standard
ESXi-5.1.0-20130402001-no-tools

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

ESXi-5.1.0-20130401001s-standard
ESXi-5.1.0-20130401001s-no-tools


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

Problèmes résolus

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

CIM et API

  • L'UUID SMBIOS signalé par les hôtes ESXi 5.1 peut être différent de l'UUID SMBIOS réel
    Si la version SMBIOS du système ESXi 5.1 est la version 2.6 ou une version ultérieure, il est possible que l'UUID SMBIOS signalé par l'hôte ESXi 5.1 soit différent de l'UUID SMBIOS réel. L'ordre des octets des 3 premiers champs de l'UUID n'est pas correct.

    Ce problème est résolu dans cette version.
  • L'hote ESXi 5.x apparaît déconnecté dans vCenter Server et enregistre le message « the ramdisk (root) is full » dans le fichier vpxa.log
    Si le Protocole de gestion de réseau simple (SNMP) ne peut pas prendre en charge le nombre de fichiers trappe SNMP ( .trp) dans le dossier /var/spool/snmpd'ESXi, l'hôte peut apparaître déconnecté dans vCenter Server. Vous pouvez être dans l'incapacité d'exécuter une tâche sur l'hôte.
    Le fichier vpxa.logcontient plusieurs entrées similaires à celle-ci :
    WARNING: VisorFSObj: 1954: Cannot create file
    /var/run/vmware/f4a0dbedb2e0fd30b80f90123fbe40f8.lck for process vpxa because the inode table of its ramdisk (root) is full.
    AVERTIS: VisorFSObj: 1954: Cannot create file
    /var/run/vmware/watchdog-vpxa.PID for process sh because the inode table of its ramdisk (root) is full.


    Ce problème est résolu dans cette version.
  • vCenter Server ou vSphere Client ne peut pas surveiller l'état du contrôleur RAID matériel de l'hôte
    Si vous avez installé un fournisseur CIM de type contrôleur RAID matériel hôte (HHRC) tierce partie tel qu'un fournisseur CIM LSI, le processus sfcb-hhrc échoue en cas d'erreur du fournisseur CIM HHRC encapsulé.

    Cette version résout ce problème en améliorant la capacité de prise en charge des erreurs et la robustesse de HHRCWrapperProvider.

"Système d'exploitation client

  • Lorsque vous créez une machine virtuelle en utilisant un matériel version 9, l'option Mac OS X 10.8 64 bits n'est pas disponible
    Lorsque vous créez une machine virtuelle en utilisant un matériel virtuel version 9 dans vSphere 5.1, l'option du système d'exploitation Mac OS X 10.8 64 bits n'apparaît pas dans le menu déroulant des systèmes d'exploitation clients.

    Ce problème est résolu dans cette version si vous utilisez le client NGC pour vous connecter à vSphere 5.1 Update 1.
  • Le compteur d'horodatage (TSC) n'est pas étalonné correctement pour les machines virtuelles Solaris 10
    Ce problème est résolu dans cette version.
    Pour ramener l'étalonnage du TSC dans la fourchette de tolérance du protocole de temps du réseau (NTP), la prise en charge du Calibrage du temporisateur client a été ajoutée pour les systèmes d'exploitation Solaris 10.
  • Sur un hôte ESXi 5.1, les machines virtuelles peuvent cesser de répondre avec des vCPU occupés
    Sur un hôte ESXi 5.1, une machine virtuelle s'exécutant sur un matériel version 7 peut cesser de répondre avec des vCPU occupés. Ce problème affecte les machines virtuelles dont les systèmes d'exploitation clients utilisent le mode de destination logique du contrôleur d'interruption programmable avancé (APIC). Les machines virtuelles sur lesquelles les systèmes d'exploitation clients utilisent le mode de destination physique ne sont pas affectées.

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

  • La fonction CreateTemporaryFile InGuest() peut entraîner une exception GuestPermissionDeniedFault
    Lorsque vous reconfigurez une machine virtuelle sous tension pour ajouter un contrôleur SCSI et que vous essayez de créer un fichier temporaire dans le système d'exploitation client, l'opération peut échouer avec une exception GuestPermissionDeniedFault.

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

Divers

  • L'utilisation de la commande invoke-vmscript affiche une erreur
    Lorsque vous utilisez le script de commandes PowerCLI invoke-vmscriptsur une machine virtuelle, le script échoue avec le message d'erreur suivant :

    L'agent des opérations client n'a pas pu être contacté.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi échoue avec un écran de diagnostic violet lorsque vous essayez de brancher ou débrancher un clavier ou une souris via un port USB
    Lorsque vous tentez de brancher ou débrancher un clavier ou une souris via le port USB, l'hôte ESXi échoue avec le message d'erreur suivant :
    PCPU## locked up. Failed to ack TLB invalidate.

    Pour plus d'informations, voir KB 2000091.

    Ce problème est résolu dans cette version.
  • Toute tentative d'ajout d'un hôte ESXi à un domaine à l'aide du service vSphere Authentication Proxy (service CAM) peut échouer la première fois, en raison du délai de réplication du Contrôleur de Domaine
    Le processus automatisé d'ajout d'un hôte ESXi pour la première fois à l'aide du service vSphere Authentication Proxy (service CAM) peut échouer avec un message d'erreur similaire à celui-ci :

    Cannot complete login due to an incorrect user name or password

    Ce problème se produit lorsque le service Authentication Proxy crée le compte sur un Contrôleur de Domaine et que l'hôte ESXi communique avec un autre Contrôleur de Domaine, ce qui entraîne un retard de réplication du Contrôleur de Domaine. L'hôte ESXi ne parvient donc pas à se connecter au Contrôleur de Domaine (DC) avec le compte nouvellement créé.
    Ce problème ne se produit pas lorsque l'hôte ESXi est ajouté directement au domaine Active Directory sans utiliser le service Authentication Proxy.

    Ce problème est résolu dans cette version.
  • Ajout de la journalisation basée sur les composants et des configurations avancées au niveau de journalisation hostd
    Pour éviter des difficultés d'obtention de journaux appropriés lorsqu'un problème se produit, cette version introduit la journalisation basée sur les composants en divisant les journaux en différents groupes et en les préfixant. En outre, une nouvelle configuration avancée vous permet de modifier le niveau de journalisation hostd sans redémarrer.

    Ce problème est résolu dans cette version.
  • Les machines virtuelles exécutant le système d'exploitation client Windows 2003 R2 64 bits sur un hôte ESXi avec vShield Endpoint peuvent échouer avec un écran de diagnostic bleu
    Sous certaines conditions, un appel API erroné dans vShield Endpoint driver vsepflt.syspeut faire échouer les machines virtuelles exécutant le système d'exploitation client Windows 2003 R2 64 bits avec un écran de diagnostic bleu.

    Ce problème est résolu dans cette version.
  • VMware Ondisk Metadata Analyser (VOMA) échoue avec une erreur de segmentation
  • VMware Ondisk Metadata Analyser (VOMA) échoue avec une erreur de segmentation provoquée par le module VMFSCK.
    Ce problème est résolu dans cette version.
  • Le vidage de mémoire réseau de vSphere ne collecte pas les données complètes
    Le vidage de mémoire réseau de vSphere ne collecte pas les données complètes si le vidage de disque ne parvient pas à collecter certaines données en raison d'une taille de slot de vidage insuffisante.

    Ce problème est résolu dans cette version. Plus aucune défaillance due à la taille du slot de vidage de disque n'affecte le vidage de mémoire réseau.

  • Les hôtes ESXi peuvent échouer si le thread persistant (worker) hostd consomme 100 % des ressources CPU
    Sous une charge suffisamment élevée de l'hôte ESXi, le thread persistant (worker) hostd peut échouer en consommant 100 % des ressources CPU pendant qu'il récupère le fichier de capture d'écran de la machine virtuelle pour vCloud Director UI. Ce problème peut entraîner l'échec de l'hôte ESXi.

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

Mise en réseau

  • Les opérations vMotion de longue durée peuvent provoquer une saturation monodiffusion
    Lors de l'utilisation de la fonction multiple-NIC vMotion avec vSphere 5, si les opérations vMotion se poursuivent pendant une longue durée, on observe une saturation monodiffusion sur toutes les interfaces du commutateur physique. Si l'opération vMotion dure au-delà du temps de la table d'adresses MAC, l'hôte source et l'hôte de destination commencent à recevoir un trafic réseau volumineux.

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

  • ESXi peut afficher un message d'erreur de non-conformité après l'application d'un profil d'hôte sur l'hôte
    Lorsque vous appliquez le profil d'hôte à un hôte ESXi, l'hôte peut ne pas être conforme et afficher un message d'erreur semblable à celui-ci :
    IPv4 routes did not match

    Ce problème se produit lorsque deux ou plusieurs groupes de ports VMkernel utilisent le même sous-réseau.

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

  • Les machines virtuelles avec la carte réseau vNIC VMXNET 3 peuvent afficher des messages d'erreur dans le fichier journal hostd
    Les machines virtuelles avec la carte réseau vNIC VMXNET 3 peuvent afficher des messages d'erreur semblables à celui-ci dans le fichier journal hostd :

    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.
    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.
    2012-06-12T07:09:03.351Z [5E342B90 error 'NetworkProvider'] Unknown port type [0]: convert to UNKNOWN.


    Ce problème se produit lorsque le type de port n'est pas défini. Il s'agit d'un comportement normal. Vous pouvez donc ignorer ce message.

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

  • L'hôte ESXi cesse de répondre avec un écran de diagnostic violet durant arpresolve
    L'hôte ESXi peut cesser de répondre durant arpresolve et afficher un écran de diagnostic violet avec les messages suivants :

    2012-08-30T14:35:11.247Z cpu50:8242)@BlueScreen: #PF Exception 14 in world 8242:idle50 IP 0x4180280056ad addr 0x1
    2012-08-30T14:35:11.248Z cpu50:8242)Code start: 0x418027800000 VMK uptime: 7:14:19:29.193
    2012-08-30T14:35:11.249Z cpu50:8242)0x412240c87868:[0x4180280056ad]arpresolve@ # +0xd4 stack: 0x412240c878a8
    2012-08-30T14:35:11.249Z cpu50:8242)0x412240c878e8:[0x418027ff69ba]ether_output@ # +0x8d stack: 0x412240c87938
    2012-08-30T14:35:11.250Z cpu50:8242)0x412240c87a28:[0x4180280065ad]arpintr@ # +0xa9c stack: 0x41003eacd000
    2012-08-30T14:35:11.251Z cpu50:8242)0x412240c87a68:[0x418027ff6f76]ether_demux@ # +0x1a1 stack: 0x41003eacd000
    2012-08-30T14:35:11.252Z cpu50:8242)0x412240c87a98:[0x418027ff72c4]ether_input@ # +0x283 stack: 0x412240c87b50
    2012-08-30T14:35:11.253Z cpu50:8242)0x412240c87b18:[0x418027fd338f]TcpipRx@ # +0x1de stack: 0x2
    2012-08-30T14:35:11.254Z cpu50:8242)0x412240c87b98:[0x418027fd2d9b]TcpipDispatch@ # +0x1c6 stack: 0x410008ce6000
    2012-08-30T14:35:11.255Z cpu50:8242)0x412240c87c48:[0x4180278ed76e]WorldletProcessQueue@vmkernel#nover+0x3c5 stack: 0x0
    2012-08-30T14:35:11.255Z cpu50:8242)0x412240c87c88:[0x4180278edc79]WorldletBHHandler@vmkernel#nover+0x60 stack: 0x2
    2012-08-30T14:35:11.256Z cpu50:8242)0x412240c87ce8:[0x41802781847c]BHCallHandlers@vmkernel#nover+0xbb stack: 0x100410000000000
    2012-08-30T14:35:11.257Z cpu50:8242)0x412240c87d28:[0x41802781896b]BH_Check@vmkernel#nover+0xde stack: 0x4a8a29522e753
    2012-08-30T14:35:11.258Z cpu50:8242)0x412240c87e58:[0x4180279efb41]CpuSchedIdleLoopInt@vmkernel#nover+0x84 stack: 0x412240c87e98
    2012-08-30T14:35:11.259Z cpu50:8242)0x412240c87e68:[0x4180279f75f6]CpuSched_IdleLoop@vmkernel#nover+0x15 stack: 0x62
    2012-08-30T14:35:11.260Z cpu50:8242)0x412240c87e98:[0x41802784631e]Init_SlaveIdle@vmkernel#nover+0x13d stack: 0x0
    2012-08-30T14:35:11.261Z cpu50:8242)0x412240c87fe8:[0x418027b06479]SMPSlaveIdle@vmkernel#nover+0x310 stack: 0x0
    2012-08-30T14:35:11.272Z cpu50:8242)base fs=0x0 gs=0x41804c800000 Kgs=0x0

    Ce problème est résolu dans cette version.
  • Les machines virtuelles Solaris 11 avec une carte réseau VMXNET3 peuvent écrire des messages sur /var/adm/messages toutes les 30 secondes
    Les machines virtuelles Solaris 11 avec une carte réseau VMXNET3 peuvent écrire des messages sur /var/adm/messages. Un message d'erreur similaire à celui-ci peut être affiché dans le journal système :
    vmxnet3s: [ID 654879 kern.notice] vmxnet3s:1: getcapab(0x200000) -> no
    Ce problème est répété toutes les 30 secondes.
    Ce problème est résolu dans cette version.
  • Un hôte ESXi peut cesser de répondre et afficher un écran violet de diagnostic en raison d'une erreur durant le nettoyage de l'anneau de transit
    Un hôte ESXi peut cesser de répondre et afficher un écran violet de diagnostic avec des messages similaires à celui-ci :

    @BlueScreen: #PF Exception 14 in world 4891:vmm0:HQINTSQ IP 0x41800655ea98 addr 0xcc
    41:11:55:21.277 cpu15:4891)Code start: 0x418006000000 VMK uptime: 41:11:55:21.277
    41:11:55:21.278 cpu15:4891)0x417f818df948:[0x41800655ea98]e1000_clean_tx_irq@esx:nover+0x9f stack: 0x4100b5610080
    41:11:55:21.278 cpu15:4891)0x417f818df998:[0x418006560b9a]e1000_poll@esx:nover+0x18d stack: 0x417f818dfab4
    41:11:55:21.279 cpu15:4891)0x417f818dfa18:[0x41800645013a]napi_poll@esx:nover+0x10d stack: 0x417fc68857b8
    41:11:55:21.280 cpu15:4891)0x417f818dfae8:[0x4180060d699b]WorldletBHHandler@vmkernel:nover+0x442 stack: 0x417fc67bf7e0
    41:11:55:21.280 cpu15:4891)0x417f818dfb48:[0x4180060062d6]BHCallHandlers@vmkernel:nover+0xc5 stack: 0x100410006c38000
    41:11:55:21.281 cpu15:4891)0x417f818dfb88:[0x4180060065d0]BH_Check@vmkernel:nover+0xcf stack: 0x417f818dfc18
    41:11:55:21.281 cpu15:4891)0x417f818dfc98:[0x4180061cc7c5]CpuSchedIdleLoopInt@vmkernel:nover+0x6c stack: 0x410004822dc0
    41:11:55:21.282 cpu15:4891)0x417f818dfe68:[0x4180061d180e]CpuSchedDispatch@vmkernel:nover+0x16e1 stack: 0x0
    41:11:55:21.282 cpu15:4891)0x417f818dfed8:[0x4180061d225a]CpuSchedWait@vmkernel:nover+0x20d stack: 0x410006108b98
    41:11:55:21.283 cpu15:4891)0x417f818dff28:[0x4180061d247a]CpuSched_VcpuHalt@vmkernel:nover+0x159 stack: 0x4100a24416ac
    41:11:55:21.284 cpu15:4891)0x417f818dff98:[0x4180060b181f]VMMVMKCall_Call@vmkernel:nover+0x2ba stack: 0x417f818dfff0
    41:11:55:21.284 cpu15:4891)0x417f818dffe8:[0x418006098d19]VMKVMMEnterVMKernel@vmkernel:nover+0x10c stack: 0x0
    41:11:55:21.285 cpu15:4891)0xfffffffffc058698:[0xfffffffffc21d008]__vmk_versionInfo_str@esx:nover+0xf59cc9f7 stack: 0x0
    41:11:55:21.297 cpu15:4891)FSbase:0x0 GSbase:0x418043c00000 kernelGSbase:0x0

    Cette erreur se produit si, durant le nettoyage de l'anneau de transit, le processeur est affecté à d'autres tâches pendant qu'un autre processeur nettoie l'anneau. Le premier processeur nettoie alors par erreur l'anneau de transit à nouveau et finit par déréférencer un skb NULL.

    Ce problème est résolu dans cette version.
  • La connectivité du réseau sur les machines virtuelles IPv6 ne fonctionne pas avec VMXNET3
    Lorsque plus de 32 adresses IPv6 sont configurées sur une interface VMXNET3, la connectivité unicast et multicast est perdue pour certaines de ces adresses.

    Ce problème est résolu dans cette version.
  • Met à jour le pilote tg3 vers la version 3.123b.v50.1
    La version du pilote intégré tg3 livrée avec ESXi 5.1 Update 1 est la version 3.123b.v50.1.
  • Le profil de l'hôte peut ne pas pouvoir appliquer de valeur MTU aux vSwitches de l'hôte de destination
    Lorsque vous appliquez un profil d'hôte qui modifie seulement la valeur MTU d'un vSwitch standard, la nouvelle configuration MTU n'est pas appliquée aux vSwitches du nouvel hôte de destination.
    Ce problème est résolu dans cette version.
  • Une machine virtuelle peut perdre sa connectivité du réseau de son environnement externe après une opération vMotion dans un environnement vNetwork Distributed Switch
    Une machine virtuelle peut perdre sa connectivité du réseau de son environnement externe après une opération vMotion dans un environnement vNetwork Distributed Switch.
    Ce problème peut se produire lorsque toutes les conditions suivantes sont réunies :
    • Le groupe de ports réseau de la machine virtuelle est configuré sur vNetwork Distributed Switch.
    • La machine virtuelle est configurée avec une NIC VMXNET2 (enhanced) ou Flexible (VMXNET).
    • La configuration du paramètre de sécurité du groupe de ports réseau de la machine virtuelle est définie sur Rejeter changement d'adresse MAC.

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

  • L'hôte ESX/ESXi avec un pilote Broadcom bnx2x Async version 1.61.15.v50.1 peut échouer avec un écran de diagnostic violet
    L'hôte ESX/ESXi avec un pilote Broadcom bnx2x Async version 1.61.15.v50.1 peut échouer avec un écran de diagnostic violet lorsque le pilote bnx2x Async définit la valeur de la taille maximale de segment (MSS) du déchargement de la segmentation TCP (TSO) dans VMkernel sur zéro.

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

  • Les NIC physiques réglées sur Négociation automatique ne peuvent pas être modifiées sur Fixe en utilisant les profils d'hôte si les mêmes paramètres de vitesse et de duplex sont présents
    Les profils d'hôte vérifient la conformité de la vitesse et du duplex d'une NIC physique. Si la vitesse et le duplex d'une NIC physique d'un hôte ESXi correspondent à ceux du profil d'hôte, l'hôte ESXi apparaît conforme, même si la NIC physique est définie sur Négociation automatique et le profil d'hôte sur Fixe. En outre, les NIC physiques définies sur Négociation automatique ne peuvent pas être modifiées en Fixe en utilisant les profils d'hôte si les paramètres de vitesse et de duplex de l'hôte ESXi et du profil d'hôte sont identiques.

    Ce problème est résolu dans cette version.
  • L'hôte ESXi 5.1 avec Sondage balise activé peut échouer avec un écran violet lors du redémarrage
    Si vous redémarrez un hôte ESXi 5.1 avec Sondage balise activé, l'hôte peut échouer avec un écran violet et afficher des messages d'erreur similaires à celui-ci :
    2012-09-12T13:32:10.964Z cpu6:4578)@BlueScreen: #PF Exception 14 in world 4578:helper34-0 IP 0x41803c0dbf43 addr 0x200 2012-09-12T13:32:10.964Z cpu6:4578)Code start: 0x41803ba00000 VMK uptime: 0:00:10:57.178 2012-09-12T13:32:10.965Z cpu6:4578)0x41220789ba70:[0x41803c0dbf43]NCPGetUplinkBeaconState@ # +0x1e stack: 0x410003000000 2012-09-12T13:32:10.966Z cpu6:4578)0x41220789bf40:[0x41803c0dcc5d]NCPHealthChkTicketCB@ # +0x258 stack: 0x0 2012-09-12T13:32:10.967Z cpu6:4578)0x41220789bf60:[0x41803c0a991d]NHCTicketEventCB@com.vmware.net.healthchk#1.0.0.0+0x3c stack: 0x0 2012-09-12T13:32:10.968Z cpu6:4578)0x41220789bff0:[0x41803ba483df]helpFunc@vmkernel#nover+0x52e stack: 0x0

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

  • La carte réseau Gigabit Intel I350 génère une adresse MAC incorrecte pour un hôte ESXi
    Sur un hôte ESXi, les adresses MAC incorrectes ou dupliquées sont attribuées à la carte réseau intégrée Gigabit Intel I350, entraînant une perte élevée de packages.

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

  • Les LUN iSCSI n'apparaissent pas après la récupération de l'état APD
    Après la récupération de l'état APD (Tous chemins hors service), les LUN iSCSI n'apparaissent que si l'hôte est redémarré. Ce problème se produit sur ??les cartes Broadcom iSCSI dont le déchargement est autorisé, configurées pour iSCSI.
     
    Ce problème est résolu dans cette version.

Sécurité

  • La mise à jour des adresses libxslt résout plusieurs problèmes de sécurité
    Le package userworld libxslt ESXi a été mis à jour afin de résoudre plusieurs problèmes de sécurité. Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué les noms CVE-2011-1202, CVE-2011-3970, CVE-2012-2825, CVE-2012-2870 et CVE-2012-2871 à ces problèmes.
  • La mise à jour de la bibliothèque libxml2 résout plusieurs problèmes de sécurité
    La bibliothèque libxml2 userworld ESXi a été mise à jour afin de résoudre plusieurs problèmes de sécurité. Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué les noms CVE-2011-3102, CVE-2012-2807et CVE-2012-5134à ces problèmes.

Configuration des serveurs

  • L'hôte ESXi cesse de répondre et affiche un écran de diagnostic violet
    L'hôte ESXi cesse de répondre et affiche un écran de diagnostic violet en raison d'un déverrouillage inopérant dans le pilote IPMI. Un message d'erreur similaire au suivant s'affiche avec une trace ipmi_request_settimeet i_ipmi_request :

    Failed to ack TLB invalidate

    Ce problème est résolu dans cette version.
  • L'hôte ESXi peut cesser de répondre lorsqu'il entretient simultanément deux interruption à déclenchement par niveau
    Lorsque des interruptions à déclenchement par niveau sont appelées pour le même périphérique ou pilote par deux CPU différents d'un même hôte ESXi et sont exécutées simultanément, l'hôte ESXi cesse de répondre et affiche un écran de diagnostic violet avec un message similaire à l'un des suivants :
    • mpt2sas_base_get_smid_scsiio
    • Failed at vmkdrivers/src_9/vmklinux_9/vmware/linux_scsi.c:2221 -- NOT REACHED

    Ce problème est résolu dans cette version en améliorant le mécanisme de gestion des interruptions à déclenchement par niveau.

  • vCenter Server et l'hôte ESXi affichent incorrectement les noms des cartes de la série Dell H310
    Les identifiants PCI de la série Dell H310 n'avaient pas été ajoutés au pilote megaraid_sas. Par conséquent, vCenter Server et l'hôte ESXi affichent incorrectement les noms des cartes de la série Dell H310.

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

  • Toute tentative d'application d'un profil d'hôte peut échouer avec un message d'erreur indiquant que l'inscription à l'indication CIM ne peut être supprimée
    Les abonnements d'indication CIM sont stockés dans le dépôt et disposent d'une copie en mémoire. Si vous essayez d'appliquer un profil d'hôte lorsque le dépôt et la mémoire ne sont pas synchronisés, l'opération de suppression peut échouer. Un message d'erreur similaire à celui-ci est écrit dans var/log/syslog.log :
    Error deleting indication subscription. L'objet demandé est introuvable

    Ce problème est résolu dans cette version.
  • Une machine virtuelle exécutant Red Hat Enterprise Linux 4.8 32 bits peut afficher une charge moyenne plus élevée avec ESXi 5.x qu'avec ESX 4.0
  • Une machine virtuelle exécutant un client Red Hat Enterprise Linux 4.8 32 bits, sous une charge de travail quasiment nulle avec activation intermittente et simultanée de plusieurs tâches, peut afficher une charge moyenne plus élevée avec ESX 5.x qu'avec ESX 4.0.
    Ce problème est résolu dans cette version.
  • L'onglet État du matériel peut cesser d'afficher l'état de santé de l'hôte
    Sur un hôte ESXi 5.1, Small-Footprint CIM Broker daemon ( sfcbd) peut échouer fréquemment et afficher des erreurs CIM. Par conséquent, l'onglet État du matériel peut cesser d'afficher l'état de santé de l'hôte et syslog.log peut contenir un message d'erreur similaire à celui-ci :
    Timeout (or other socket error) sending request to provider.

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

Stockage

  • L'hôte ESXi peut échouer avec un écran de diagnostic violet si le sens des données de la commande SCSI n'est pas initialisé durant l'allocation
    Si un module tierce partie crée une structure de commande Small Computer System Interface (SCSI) personnalisée sans utiliser les API VMKernel et exécute cette structure de commande SCSI, l'hôte ESXi peut échouer avec un écran de diagnostic violet.
    Ce problème se produit si la commande SCSI nécessite un transfert DMA (Direct Memory Access) et que le sens des données n'est pas initialisé dans la structure de commande SCSI.
    Ce problème est résolu dans cette version.
  • Un message d'erreur relatif à ScsiDeviceIO peut être journalisé durant la découverte des périphériques
    Durant la découverte des périphériques, si une commande SCSI optionnelle échoue dans certaines conditions, l'hôte ESXi 5.1 peut journaliser l'échec de commandes SCSI optionnelles. Un message d'erreur semblable au suivant peut être écrit sur vmkernel.log :
    2011-10-03T15:16:21.785Z cpu3:2051)ScsiDeviceIO: 2316: Cmd(0x412400754280) 0x12, CmdSN 0x60b to dev "naa.600508e000000000f795beaae1d28903" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

    Ce problème est résolu dans cette version.
  • Toute tentative d'activation du contrôle de flux sur le contrôleur Ethernet Gigabit Intel 82599EB échoue
    Lorsque vous essayez d'activer le contrôle de flux sur le contrôleur Gigabit Ethernet Intel 82599EB, le pilote ixgbe définit de façon incorrecte le contrôle de flux sur un contrôle de flux basé sur la priorité dans lequel le contrôle de flux est toujours désactivé. De ce fait, le message d'erreur Impossible de définir les paramètres de pause du périphérique : Invalid argumentapparaît lorsque vous essayez d'activer le contrôle de flux.

    Ce problème est résolu dans cette version.
  • Toute tentative de création d'une partition de diagnostic sur un disque vierge ou un disque partitionné en GPT peut échouer
    Toute tentative de création d'une partition de diagnostic à l'aide de vSphere Client peut échouer si vous essayez de créer une partition de diagnostic sur un disque vierge (un disque sans table de partitionnement) ou sur un disque partitionné en GPT disposant d'espace libre en fin de disque.
    Un message d'erreur similaire à celui-ci s'affiche lorsque vous essayez de créer une partition de diagnostic sur un disque vierge :
    Partition format unknown is not supported
    Un message d'erreur similaire à celui-ci s'affiche lorsque vous essayez de créer une partition de diagnostic sur un disque partitionné en GPT disposant d'espace libre en fin de disque :
    Une erreur est survenue lors de la configuration de l'hôte.

    Ce problème est résolu dans cette version.
  • Impossible de supprimer des fichiers dans le répertoire VMFS après qu'un ou plusieurs fichiers y aient été déplacés
    Après avoir déplacé un ou plusieurs fichiers dans un répertoire, toute tentative de suppression du répertoire ou de l'un des fichiers de ce répertoire peut échouer. Dans pareil cas, le fichier vmkernel.logcontient des entrées similaires aux suivantes :
    2012-06-25T21:03:29.940Z cpu4:373534)AVERTISSEMENT : Fil3: 13291: newLength 85120 but zla 2
    2012-06-25T21:03:29.940Z cpu4:373534)Fil3: 7752: Corrupt file length 85120, on FD <281, 106>, not truncating


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

  • Un hôte ESXi peut afficher un écran de diagnostic violet lorsque vous exécutez la commande ioctl IOCTLCMD_VMFS_QUERY_RAW_DISK depuis disklib
    L'hôte ESXi cesse de répondre avec un écran de diagnostic violet lorsqu'un pseudo LUN de classe SCSI_CLASS_RAID(0xc)avec le même naa.id que celui utilisé par un Raw Device Mapping physique (pRDM) dans une machine virtuelle est présenté comme un nouveau LUN et qu'une nouvelle analyse est exécutée.

    Ce problème est résolu dans cette version.
  • Impossible d'identifier la machine virtuelle émettant des messages d'avertissement READ10/WRITE10
    Avec les avertissements READ10/WRITE10, il est difficile de déterminer la machine virtuelle émettant ces commandes car les journaux affichent uniquement l'identifiant de gestion VSCSCI. L'identifiant mondial présent dans les journaux VMkernel ne correspond pas toujours à la machine virtuelle qui émet la commande.

    Cette version résout ce problème en améliorant les avertissements READ10/WRITE10 afin d'écrire également le nom de la machine virtuelle.
  • Lorsque vous créez une banque de données VMFS3 avec un secteur de démarrage différent du secteur par défaut ou sur un numéro d'unité logique avec de très petites partitions, les appels à QueryVmfsDatastoreExpandOptions et à QueryVmfsDatastoreExtendOptions peuvent échouer
    L'hôte ESXi (hostd) gère incorrectement les appels des méthodes de l'objet géré DatastoreSystem à QueryVmfsDatastoreExpandOptionset QueryVmfsDatastoreExtendOptions. Ce problème est constaté dans les banques de données suivantes :
    • Banque de données VMFS3 créée avec un secteur de démarrage d'une capacité supérieure à 1 Mo et inférieure à la valeur donnée par la formule (nombre de têtes * nombre de secteurs * capacité des secteurs).
    • Banque de données VMFS3 créée sur un numéro d'unité logique avec une partition dont la capacité est inférieure à la valeur donnée par la formule (nombre de têtes * nombre de secteurs * capacité des secteurs).

    Ce problème est résolu dans cette version.
  • L'hôte ESXi peut échouer en raison d'une erreur de synchronisation entre les E/S copy-on-write (COW) asynchrones en attente et la fermeture du fichier journal épars
    L'hôte ESXi peut échouer avec un écran de diagnostic violet et signale une erreur d'exception PF avec une trace similaire à celle-ci :

    @BlueScreen: #PF Exception 14 in world 137633099:vmm0:TSTSPSR IP 0x41801e20b01f addr 0x0
    cpu4:137633099)Code start: 0x41801dc00000 VMK uptime: 464:10:04:03.850
    cpu4:137633099)0x417f86a5f6b8:[0x41801e20b01f]COWCopyWriteDone@esx:nover+0x122 stack: 0x41027f520dc0
    cpu4:137633099)0x417f86a5f6e8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x0
    cpu4:137633099)0x417f86a5f968:[0x41801e20b2c2]COWAsyncDataDone@esx:nover+0x125 stack: 0x41027f5aebd8
    cpu4:137633099)0x417f86a5f998:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f556ec0
    cpu4:137633099)0x417f86a5f9c8:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027fd9c540
    cpu4:137633099)0x417f86a5f9f8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f5ae440
    cpu4:137633099)0x417f86a5fa18:[0x41801de240b9]FS_IOAccessDone@vmkernel:nover+0x80 stack: 0x41027f556858
    cpu4:137633099)0x417f86a5fa48:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x41027f59a2c0
    cpu4:137633099)0x417f86a5fa78:[0x41801dc085e9]AsyncCompleteOneIO@vmkernel:nover+0xac stack: 0x41027f480040
    cpu4:137633099)0x417f86a5faa8:[0x41801dc0838a]AsyncPopCallbackFrameInt@vmkernel:nover+0x81 stack: 0x417f86a5fad8
    cpu4:137633099)0x417f86a5fad8:[0x41801de3fd1d]FDSAsyncTokenIODone@vmkernel:nover+0xdc stack: 0x0
    cpu4:137633099)0x417f86a5fbd8:[0x41801de4faa9]SCSICompleteDeviceCommand@vmkernel:nover+0xdf0 stack: 0x41027f480040

    Ce problème est résolu dans cette version.
  • L'accès à des métadonnées corrompues sur un volume VMFS3 peut entraîner un échec de l'hôte ESXi
    Si les métadonnées d'un fichier sont corrompues sur un volume VMFS3, un hôte ESXi peut échouer avec un écran de diagnostic violet en tentant d'accéder à ce fichier. La corruption d'un fichier VMFS est extrêmement rare, mais peut être causée par des problèmes de stockage externe.

    Ce problème est résolu dans cette version.
  • L'ajout d'un nouvel hôte ESXi à un cluster Haute Disponibilité avant une reconfiguration de ce cluster peut entraîner l'échec d'un autre hôte dans le cluster avec un écran de diagnostic violet
    Lorsqu'un nouvel hôte ESXi est ajouté à un cluster Haute Disponibilité (HA) avant une reconfiguration de ce cluster, un autre hôte du cluster HA existant peut échouer avec un écran de diagnostic violet et un message d'erreur similaire à celui-ci .

    0x4122264c7ce8:[0x41802a07e023]NFSLock_GetLease@<None>#<None>+0x2e stack: 0x410023ce8570.

    Le redémarrage de l'hôte ESXi échoué peut entraîner un échec similaire de l'hôte.
    Ce problème se produit quand tous les scénarios suivants sont vrais dans l'environnement HA :
    • La valeur de l'option Network File System (NFS) LockRenewMaxFailureNumber, qui détermine le nombre d'échecs de mise à jour du verrouillage qui doivent se produire avant que le verrouillage ne soit marqué comme caduc, est modifiée de 1 à 0.
    • La valeur de l'option NFS LockUpdateTimeout, qui détermine la durée avant l'annulation d'une requête de mise à jour du verrouillage, est modifiée de 1 à 0.
    • Un hôte quelconque essaye de s'approprier le verrouillage sur le volume NFS.

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

  • L'hôte ESXi peut échouer avec un écran de diagnostic violet en raison de conditions de concurrence dans VMkernel entraînant des exceptions de pointeur NULL
    Des exceptions de pointeur NULL se produisent suite à l'échec de l'hôte ESXi avec un écran de diagnostic violet, en raison de conditions de concurrence dans VMkernel.
    Ces conditions de concurrence peuvent se produire lorsque vous exécutez certaines opérations sur un système de fichiers Device File System (DevFS) dans l'hôte ESXi.

    Ce problème est résolu dans cette version.
  • La mise à niveau depuis ESX/ESXi 4.x ou une version antérieure vers ESXi 5.0 ou une version ultérieure peut échouer si la valeur par défaut de l'option de configuration MaxHeapSizeMB pour VMFS a été modifiée
    Un hôte ESX peut ne pas répondre après une mise à niveau depuis ESX 4.x ou une version antérieure vers ESX 5.0 ou une version ultérieure avec l'erreur suivante :

    hostCtlException: Unable to load module /usr/lib/vmware/vmkmod/vmfs3: Échec

    Ce problème peut survenir si vous définissez l'option de configuration MaxHeapSizeMBpour VMFS manuellement sur un hôte ESX/ESXi avant la mise à niveau.

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

  • Lorsque l'opération de snapshot suspendu échoue, les fichiers journaux ne sont pas consolidés
    Lorsque vous essayez d'effectuer un snapshot suspendu d'une machine virtuelle, si l'opération de snapshot échoue vers la fin, les fichiers journaux créés dans le cadre du snapshot ne sont pas consolidés. Les fichiers journaux peuvent consommer beaucoup d'espace de la banque de données.

    Ce problème est résolu dans cette version. Si l'opération de snapshot suspendu échoue, les fichiers journaux sont consolidés.

  • Les machines virtuelles résidant dans des banques de données NFS sont inaccessibles dans un hôte ESXi 5.1 après que vSphere Storage Appliance (VSA) 5.1 est sorti du mode de maintenance
    L'agent hostd signale un état incorrect des machines virtuelles à vCenter et à l'hôte ESXi après que vous avez déconnecté le stockage NFS qui dépasse la valeur Misc.APDTimeout. Ce problème se produit avec les machines virtuelles hors tension.

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

  • Le suivi de modification de bloc peut retourner un disque entièrement alloué dynamiquement
    Sur de très grands disques virtuels alloués dynamiquement, chaque appel QueryChangedDiskAreaspeut retourner l'intégralité du disque, plutôt que les seules zones en cours d'utilisation du disque alloué dynamiquement si le nombre d'IOCTL requis dépasse la limite codée en dur des IOCTL. Il en résulte des données de sauvegarde trop grandes. Cela se voit particulièrement sur les systèmes de fichiers Linux ext2 et ext3.

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

  • Les hôtes ESXi peuvent échouer dans le pilote ata avec un écran de diagnostic violet
    Une condition de concurrence dans le pilote ata peut entraîner son échec et les hôtes ESXi peuvent échouer avec un écran de diagnostic violet et un suivi de la pile similaire à celui-ci :
    BUG: failure at vmkdrivers/src_9/drivers/ata/libata-core.c:5833/ata_hsm_move()! (dans vmklinux)
    Panic_vPanic@vmkernel#nover+0x13 stack: 0x3000000010, 0x412209a87e00
    vmk_PanicWithModuleID@vmkernel#nover+0x9d stack: 0x412209a87e20,0x4
    ata_hsm_move@com.vmware.libata#9.2.0.0+0xa0 stack: 0x0, 0x410017c03e
    ata_pio_task@com.vmware.libata#9.2.0.0+0xa5 stack: 0x0, 0x0, 0x53fec
    vmklnx_workqueue_callout@com.vmware.driverAPI#9.2+0x11a stack: 0x0,
    helpFunc@vmkernel#nover+0x568 stack: 0x0, 0x0, 0x0, 0x0, 0x0


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

Matériel pris en charge

  • L'hôte ESXi peut échouer avec un écran de diagnostic violet si vous exécutez la commande vmware-vimdump depuis DCUI
    Lorsque vous exécutez la commande vmware-vimdumpdepuis l'interface utilisateur de console directe (DCUI), l'hôte ESXi peut échouer avec un écran de diagnostic violet. Cela peut également entraîner la non-réception de signaux de pulsation. Ce problème ne se produit pas lorsque la commande est exécutée avec une connexion via une console SSH.

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

Mise à niveau et installation

  • Les RDM attachés aux machines virtuelles Solaris peuvent être écrasés lors de la mise à niveau d'hôtes ESXi à l'aide d'Update Manager
    Lorsque vous mettez à niveau vers ESXi 5.x en utilisant Update Manager, une erreur de compréhension du type de partition du disque peut provoquer l'écrasement des RDM attachés aux machines virtuelles Solaris. Il peut en résulter une perte de données sur les RDM.

    Ce problème est résolu dans cette version.
  • La réinstallation d'ESXi 5.1 ne supprime pas le libellé de la banque de données du VMFS local d'une précédente installation
    La réinstallation d'ESXi 5.1 avec un volume VMFS local existant conserve le libellé de la banque de données même une fois que l'utilisateur a choisi d'écraser l'option de la banque de données pour écraser le volume VMFS.

    Ce problème est résolu dans cette version.
  • L'installation scriptée d'ESXi 5.x avertit à tort qu'un support USB ou SD ne prend pas VMFS en charge, malgré le paramètre --novmfsondisk dans le fichier kickstart
    Si vous exécutez l'installation par script pour installer ESXi 5.1 sur un disque identifié comme support USB ou SD, le programme d'installation peut afficher le message d'avertissement suivant :

    Le disque (<id-disque>) spécifié dans install ne prend pas VMFS en charge.

    Ce message s'affiche même si vous avez inclus le paramètre --novmfsondiskpour la commande d'installation dans le fichier kickstart.

    Ce problème est résolu dans cette version.
  • Lors de l'utilisation d'AutoDeploy, le processus iPXE peut expirer
    Lorsque vous utilisez AutoDeploy pour démarrer des hôtes ESXi 5.1, le processus iPXE peut expirer en essayant d'obtenir une adresse IP des serveurs DHCP et le processus de démarrage d'AutoDeploy s'arrête soudainement.

    Ce problème est résolu dans cette version en augmentant le délai d'attente de 60 secondes.
  • Toute tentative de mise à niveau de l'hôte ESXi dans un cluster HA peut échouer avec vCenter Update Manager
    La mise à niveau d'un hôte ESXi dans un cluster Haute Disponibilité (HA) peut échouer avec un message d'erreur similaire à celui-ci avec vCenter Update Manager (VUM) :
    the host returned esx update error code 7
    Ce problème se produit lorsque plusieurs opérations de transfert sont exécutées avec différentes lignes de base dans Update Manager.

    Ce problème est résolu dans cette version.
  • Toute tentative de mise à niveau depuis ESX 4.1 avec les extensions sur la banque de données locale vers ESXi 5.1 échoue
    La mise à niveau depuis ESX 4.1 avec les extensions sur la banque de données locale vers ESXi 5.1 n'est pas prise en charge. Cependant, le processus de mise à niveau actuel autorise ce comportement de mise à niveau et annule les extensions sur une banque de données locale sans afficher de message d'erreur ou d'avertissement.

    Ce problème est résolu dans cette version par l'ajout d'une vérification sur le script de vérification préalable pour détecter une telle situation. Un message s'affiche indiquant à l'utilisateur de mettre fin à la mise à niveau ou de migrer.
  • Les services de déploiement Microsoft Windows (WDS) peuvent ne pas démarrer par PXE les machines virtuelles qui utilisent la carte réseau VMXNET3
    Toute tentative de démarrage par PXE de machines virtuelles qui utilisent la carte réseau VMXNET3, en utilisant les services de déploiement Microsoft Windows (WDS), peut échouer avec des messages similaires aux suivants :

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

    Statut : 0xc0000001

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

    Ce problème est résolu dans cette version.
  • L'installation ou la mise à niveau scriptée d'ESXi depuis un lecteur USB attaché peut échouer si le type de système de fichiers de l'un des lecteurs USB n'est pas fat16 ou fat32
    Si plusieurs lecteurs flash USB sont attachés à un hôte ESXi, l'installation ou la mise à niveau scriptée d'ESXi à l'aide de l'option de démarrage ks=usbpeut échouer avec une erreur d'exception si le type de système de fichiers de l'un des lecteurs USB avec un partitionnement MS-DOS n'est pas fat16ou fat32.

    Ce problème est résolu dans cette version.
  • Après une mise à niveau d'ESXi, l'hôte ESXi conserve l'ancienne version du fichier /etc/vmware/service/service.xml
    Lorsque vous modifiez le fichier etc/vmware/service/service.xml, dont le sticky bit est défini, puis exécutez une mise à niveau d'ESX/ESXi 4.0 vers la version 5.1, les anciens fichiers service.xmlpeuvent entraîner des problèmes de compatibilité. Cela se produit car l'ancien fichier service.xmlest conservé par l'hôte ESXi même après la mise à niveau.

    Ce problème est résolu dans cette version.
  • L'installation scriptée d'ESXi 5.1 avec des informations IPv6 échoue
    Lorsque vous exécutez une installation scriptée d'ESXi 5.1, avec les informations IPv6 mentionnées dans ks.cfg, l'installation échoue pendant la validation des informations IPv6.

    Ce problème est résolu dans cette version.
  • La valeur Syslog.global.logDir et Syslog.global.logHost n'est pas persistante après une mise à niveau de l'hôte ESXi
    Lorsque vous mettez à niveau un hôte ESXi 4.x vers la version 5.x, la valeur de Syslog.global.logDiret Syslog.global.logHostpeut ne pas persister.

    Ce problème est résolu dans cette version.
  • Les tests VIB tiers ne doivent pas s'exécuter pendant la mise à niveau de l'hôte ESXi 5.0 vers la version 5.1
    Lorsque vous exécutez une mise à niveau d'ESXi 5.0 vers ESXi 5.1 avec des VIB tiers depuis Powerpath, le programme d'installation d'ESXi et vSphere Update Manager ne doivent pas afficher les messages d'avertissement des VIB tiers.

    Ce problème est résolu dans cette version.
  • resxtop échoue lors de la mise à niveau de vSphere 5.0 vers vSphere 5.1
    Dans vSphere 5.1, les vérifications de certification SSL sont activées. Cela peut empêcher resxtop de se connecter aux hôtes et affiche un message d'exception similaire à celui-ci :
    HTTPS_CA_FILE or HTTPS_CA_DIR not set.

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

  • Toute tentative de mise à niveau d'ESX/ESXi 4.0 Update 4 vers ESXi Server 5.1 peut afficher un message d'erreur si le mot de passe du compte vpxuser n'est pas configuré avec un chiffrement MD5
    Lorsque vous mettez à niveau ESX/ESXi 4.0 Update 4 vers ESXi Server 5.1 à l'aide de VMware Update Manager (VUM), un message d'erreur semblable au suivant peut s'afficher :

    Password for user vpxuser was not set with MD5 encryption. Seuls les 8 premiers caractères comptent. Réinitialisez le mot de passe lors du redémarrage.

    Ce problème se produit si le mot de passe du compte vpxuser n'est pas configuré avec un chiffrement MD5.

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

vCenter Server, vSphere Client et vSphere Web Client

  • VMRC et vSphere Client peuvent cesser de répondre lorsqu'ils sont connectés à une machine virtuelle qui a échoué
    Sur un hôte ESXi 5.1, VMware Remote Console (VMRC) et vSphere Client peuvent cesser de répondre lorsqu'ils sont connectés à une machine virtuelle qui a échoué ou qui exécute une occurrence de VMware Tools qui a échoué.

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

Gestion des machines virtuelles

  • Impossible de déployer des machines virtuelles à l'aide de fichiers de modèle
    Il se peut que vous ne puissiez pas déployer de machine virtuelle à l'aide de fichiers de modèle. Ce problème se produit lors de la resignature d'une banque de données qui contient les fichiers de modèle et les fichiers .vmtxne sont pas mis à jour.

    Ce problème est résolu dans cette version par la mise à jour des fichiers de machine virtuelle .vmtxdu modèle avec le dernier chemin de la banque de données resignée.

  • L'opération de mise sous tension de la machine virtuelle peut échouer avec des messages d'avertissement de mémoire insuffisante de la pile de VMFS
    Si une machine virtuelle a plus de 18 disques virtuels dont la capacité individuelle est supérieure à 256 Go, il peut ne pas être possible de mettre sous tension l'hôte ESXi sur cette machine virtuelle. Un message d'avertissement similaire à celui-ci peut être journalisé dans vmkernel.log :
    WARNING: Heap: 2525: Heap vmfs3 already at its maximum size. Cannot expand. AVERTIS: Heap: 2900: Heap_Align(vmfs3, 2099200/2099200 bytes, 8 align) failed. caller: 0x4180368c0b90

    Ce problème est résolu dans cette version.
  • Impossible de créer un snapshot suspendu après la suppression d'un disque indépendant d'une machine virtuelle
    Si un disque indépendant est supprimé d'une machine virtuelle, toute tentative de création d'un snapshot suspendu d'une machine virtuelle peut échouer car les données d'un mode de disque d'un nœud SCSI donné sont périmées.
    Un message d'erreur similaire au suivant peut s'afficher :
    Statut : Une erreur est survenue lors de la suspension de la machine virtuelle. Consultez le journal des événements pour obtenir des détails.

    Les fichiers journaux peuvent contenir des entrées similaires aux suivantes :
    HotAdd: Adding scsi-hardDisk with mode 'independent-persistent' to scsi0:1

    ToolsBackup: changing quiesce state: STARTED -> DONE SnapshotVMXTakeSnapshotComplete done with snapshot 'back': 0
    SnapshotVMXTakeSnapshotComplete: Snapshot 0 a échoué : Échec de la suspension de la machine virtuelle. (40).

    Ce problème est résolu dans cette version.
  • La synchronisation de l'heure avec le serveur ESXi peut entraîner un redémarrage inopiné du système d'exploitation client quand un serveur ESXi est configuré en tant que serveur NTP
    Lorsqu'un hôte ESXi est configuré en tant que serveur du protocole de temps du réseau (NTP), le système d'exploitation client peut redémarrer inopinément durant la synchronisation de l'heure avec l'hôte ESXi. Ce problème se produit lorsque le niveau de sensibilité de la surveillance des machines virtuelles est défini sur Élevé sur un cluster Haute Disponibilité et que l'option das.iostatsIntervalest définie sur Faux.

    Ce problème peut être résolu en définissant l'option das.iostatsIntervalsur Vrai.
  • L'hôte ESXi peut échouer pendant l'exécution de certaines opérations de machine virtuelle
    Quand vous exécutez certaines opérations de machine virtuelle, un problème lié à la corruption des métadonnées des LUN peut parfois entraîner l'échec de l'hôte ESXi avec un écran violet et afficher des messages d'erreur similaires aux suivants :
    @BlueScreen: #DE Exception 0 in world 4277:helper23-15 @ 0x41801edccb6e 3:21:13:31.624 cpu7:4277)Code start: 0x41801e600000 VMK uptime: 3:21:13:31.624 3:21:13:31.625 cpu7:4277)0x417f805afed0:[0x41801edccb6e]Fil3_DirIoctl@esx:nover+0x389 stack: 0x410007741f60 3:21:13:31.625 cpu7:4277)0x417f805aff10:[0x41801e820f99]FSS_Ioctl@vmkernel:nover+0x5c stack: 0x2001cf530 3:21:13:31.625 cpu7:4277)0x417f805aff90:[0x41801e6dcf03]HostFileIoctlFn@vmkernel:nover+0xe2 stack: 0x417f805afff0 3:21:13:31.625 cpu7:4277)0x417f805afff0:[0x41801e629a5a]helpFunc@vmkernel:nover+0x501 stack: 0x0 3:21:13:31.626 cpu7:4277)0x417f805afff8:[0x0] stack: 0x0

    Ce problème est résolu dans cette version. La corruption des métadonnées des LUN entraîne désormais un message d'erreur.

vMotion et Storage vMotion

  • Lorsque vous effectuez une migration en direct de machines virtuelles Windows Server 2008 d'ESX/ESXi 4.0 vers ESXi 5.1 et que vous effectuez ensuite une opération Storage vMotion, les snapshots suspendus échouent
    Une opération Storage vMotion sur ESXi 5.1 par défaut définit disk.enableUUIDsur vrai pour une machine virtuelle Windows Server 2008, permettant ainsi la suspension de l'application. L'opération de snapshots suspendus suivante échoue jusqu'à ce que la machine virtuelle subisse un cycle d'alimentation.

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

VMware Tools

  • VMware Tools peut échouer en prenant un snapshot suspendu d'une machine virtuelle
    Si des fichiers non exécutables sont présents dans le dossier backupScripts.d, VMware Tools peut échouer en prenant un snapshot suspendu d'une machine virtuelle.

    Ce problème est résolu dans cette version.
  • Après l'installation de VMware Tools, le nom du système d'exploitation client passe de Microsoft Windows Server 2012 (64 bits) à Microsoft Windows 8 (64 bits)
    Après la création des machines virtuelles de Microsoft Windows Server 2012 (64 bits) et l'installation de VMware Tools, le nom du système d'exploitation client passe de Microsoft Windows Server 2012 (64 bits) à Microsoft Windows 8 (64 bits).

    Ce problème est résolu dans cette version.
  • Les packages VMware Tools OSP ont les mêmes identificateurs de distribution dans leurs noms de fichiers
    Les packages OSP de VMware Tools n'ont pas de noms de fichier distinctifs pour les systèmes d'exploitation clients SUSE Linux Enterprise Server 11, Red Hat Enterprise Linux 5 et Red Hat Enterprise Linux 6. En conséquence, il est difficile de déployer les packages OSP de VMware Tools à l'aide du serveur Red Hat Satellite.

    Ce problème est résolu dans cette version.
  • VMware Tools installe une version antérieure de la bibliothèque de composants runtime Microsoft Visual C++
    VMware Tools installe la version 9.0.30729.4148de la bibliothèque de composants runtime de Microsoft Visual C++, bien que la version 9.0.30729.6161existe.

    Ce problème est résolu dans cette version. VMware Tools installe désormais la dernière version de la bibliothèque de composants runtime Microsoft Visual C++. Si une version plus récente de la bibliothèque de composants runtime Microsoft Visual C++ est disponible dans le système, VMware Tools ne l'installe pas.
  • VMware Tools peut entraîner une fuite de mémoire dans le système d'exploitation client Linux
    Lorsque plusieurs VLAN sont configurés pour une interface réseau dans le système d'exploitation client Linux, VMware Tools peut entraîner une fuite de mémoire.

    Ce problème est résolu dans cette version.
  • Les autorisations de fichier de /etc/fstab sont susceptibles de changer après l'installation de VMware Tools
    Lorsque VMware Tools est installé sur une machine virtuelle telle que SUSE Linux Enterprise Server 11 SP1, l'attribut d'autorisation de fichier de /etc/fstabest susceptible de changer de 644 à 600.

    Ce problème est résolu dans cette version.
  • VMware Tools peut échouer par intermittence sur une machine virtuelle Linux
    VMware Tools inclut une bibliothèque partagée nommée libdnet. Lorsque certains autres logiciels, tels que Dell OpenManage, sont installés, une autre bibliothèque partagée portant le même nom est créée sur le système de fichiers. Lors du chargement de VMware Tools, le logiciel Dell OpenManage ouvre la bibliothèque libdnet.so.1au lieu de libdnet.sode VMware Tools. Par conséquent, les informations relatives au système d'exploitation client peuvent ne pas s'afficher dans l'onglet Résumé de vSphere Client. Il en est de même pour les informations relatives à la NIC.

    Ce problème est résolu dans cette version.
  • Sur un hôte ESX/ESXi avec des versions antérieures à la version 5.1, la seule mise à niveau de VMware Tools vers la version 5.1 entraîne un message d'avertissement
    Sur un hôte ESX/ESXi avec des versions antérieures à la version 5.1 et avec une machine virtuelle exécutant un système d'exploitation client Windows, si vous mettez à niveau uniquement VMware Tools vers la version 5.1, un message d'avertissement similaire à celui-ci peut s'afficher dans Windows Event Viewer :
    [ warning] [vmusr:vmusr] vmware::tools::UnityPBRPCServer::Start: Failed to register with the host!

    Ce problème est résolu dans cette version.
  • L'installation de View Agent entraîne un message d'erreur lors du redémarrage
    VMware Tools affiche le message d'erreur suivant lorsque vous essayez de redémarrer après l'installation de View Agent :

    VMWare Tools unrecoverable error: (vthread-3)

    Ce problème est résolu dans cette version.
  • Toute tentative d'i nstallation de VMware Tools peut échouer avec un noyau Linux version 3.7
    Les pilotes VMware Tools ne sont pas compilés, car les scripts d'installation de VMware Tools ne peuvent pas identifier le nouveau chemin d'accès aux fichier d'en-tête du noyau Linux version 3.7. Cela peut entraîner l'échec de l'installation de VMware Tools.

    Ce problème est résolu dans cette version.
  • La personnalisation du système d'exploitation client peut échouer lorsqu'elle est déployée depuis certaines versions non anglaises des modèles de systèmes d'exploitation client Windows
    La personnalisation du système d'exploitation client peut échouer lorsqu'elle est déployée depuis certaines versions non anglaises des modèles de systèmes d'exploitation client Windows, telles que la version française de Microsoft Windows 7, la version russe de Microsoft Windows 7 et la version française de Microsoft Windows Server 2008 R2. Ce problème se produit lorsque le service VMware Tools vmtoolsd.exeéchoue.

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

  • Impossible d'afficher les noms et descriptions du processeur de la VM ou du compteur de performances de la mémoire de la VM sur les systèmes d'exploitation client tels que Windows Vista, ou version ultérieure
    Lors de la configuration d'un journal de performances à distance sur les systèmes d'exploitation client tels que Windows Vista, ou version ultérieure, s'exécutant en tant qu'administrateur, il se peut que les noms et descriptions du processeur de la VM et de la mémoire de la VM ne s'affichent pas dans la console Analyseur de performances Windows ( perfmon).
    Cela se produit lorsque le système d'exploitation client Windows est installé dans une autre langue que en_uset de. Ce problème se produit avec VMware Tools version 8.3.1.2.

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

  • Les modules pré-intégrés (PBM) ne sont pas disponibles pour les systèmes d'exploitation Ubuntu 12.10 32 bits et 64 bits sur l'hôte ESXi 5.1
    Il se peut que vous ne trouviez pas les modules pré-intégrés (PBM) pour les systèmes d'exploitation Ubuntu 12.10 32 bits et 64 bits sur l'hôte ESXi 5.1.

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

  • Les machines virtuelles avec vShield Endpoint Thin Agent peuvent rencontrer des problèmes de performances lors de la copie de fichiers réseau vers ou depuis un partage CIFS
    Vous pouvez rencontrer des problèmes de performances avec des machines virtuelles lors de la copie de fichiers réseau vers ou depuis un partage CIFS (Common Internet File System).
    Ce problème se produit lorsque les machines virtuelles exécutant vShield Endpoint Thin Agent, disponible dans l'offre groupée VMware Tools, sont utilisées.

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

  •   Le système d'exploitation client Windows s'exécutant sur un hôte ESXi 5.1 avec vShield Endpoint et VMware Tools peut afficher des erreurs de violation de partage
    Dans un environnement avec le composant vShield Endpoint intégré à VMware Tools, le système d'exploitation client Windows s'exécutant sur un hôte ESXi 5.1 peut afficher des erreurs de violation de partage lors de l'accès aux fichiers réseau. Un message d'erreur similaire au suivant peut s'afficher lorsque vous tentez d'ouvrir un fichier réseau :

    Error opening the document. This file is already open or is used by another application.


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

Problèmes connus

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

Problèmes de mise à niveau et d'installation

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

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

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

    Solution : Aucune.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Solution : Aucune.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Solution :

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

        • Vous pouvez activer ou désactiver la vérification L3 sur certains commutateurs, par exemple sur la série de commutateurs 4500 de Cisco. Si ces commutateurs sont utilisés, désactivez la vérification L3. Désactivez l'option Longueur du paquet en miroir pour les commutateurs qui ne peuvent pas être configurés.

       

      • L'activation de plus de 16 cartes réseau VMkernel provoque un échec de vMotion
        vSphere 5.x a une limite de 16 cartes réseau VMkernel pouvant être activées pour vMotion par hôte. Si vous activez plus de 16 cartes réseau VMkernel pour vMotion sur un hôte donné, les migrations vMotion vers ou depuis cet hôte peuvent échouer. Un message d'erreur dans les journaux de VMkernel indique Refusing request to initialize 17 stream ip entries, le nombre correspondant au nombre de cartes réseau VMkernel que vous avez activées pour vMotion.

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

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

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

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

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

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

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

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

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

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

        Solution : Augmentez la taille de dvsLargeHeap.

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

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

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

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

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

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

        Solution : Aucune.

      Problèmes de stockage

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

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

        Solution :

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

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

        Dans vSphere Web Client

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

        Dans vSphere Client

        1. Dans le panneau d'inventaire de vSphere Client, sélectionnez l'hôte.
        2. Cliquez sur l'onglet Configuration, puis sur Paramètres avancés sous Logiciel.
        3. Modifiez la valeur du paramètre VMFS3.HardwareAcceleratedLocking :
          • 0 désactivé
          • 1 activé

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

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

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

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

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

        Le disque passe du format GPT au format MBR.

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

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

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

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

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

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

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

        Solution : Procédez au choix comme suit :

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

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

        Solution : Procédez au choix comme suit :

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

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

        Solution : Aucune solution de rechange n'est disponible.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          • Utilisez la taille de disque delta 4 Ko.

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

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

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

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

          Solution : Aucune.

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

          Solution : Aucune.

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

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

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

          Solution : Aucune.

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

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

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

          Solution : Aucune.