VMware ESXi™ 5.1 | 10 SEPT. 2012 | Build 799733

VMware vCenter Server™ 5.1 | 10 SEPT. 2012 | Build 799731

vCenter Server Appliance 5.1 | 10 SEPT. 2012 | Build 799730

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 vSphere 5.1 inclut ESXi 5.1 et vCenter Server 5.1. Reportez-vous à Nouveautés de VMware vSphere 5.1 pour découvrir les nouvelles fonctions et améliorations de cette version.

Internationalisation

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

Compatibilité 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, consultez les informations ESXi 5.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 les systèmes d'exploitation clients compatibles avec vSphere 5.1, consultez les informations sur ESXi 5.1 dans le 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 version de vSphere ne prendront pas en charge ces systèmes d'exploitation clients, bien que vSphere 5.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 version de Novell Netware
  • Toutes les version d'IBM OS/2

Compatibilité des machines virtuelles pour ESXi

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

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

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

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 prend uniquement en charge les CPU avec les jeux d'instructions LAHF et SAHF. Pendant une installation ou une mise à niveau, le programme d'installation vérifie la compatibilité du CPU hôte avec vSphere 5.1. Si le matériel de votre hôte n'est pas compatible, un écran violet apparaît et affiche un message d'information pour signaler une incompatibilité, et vous ne pouvez pas installer ou effectuer de mise à niveau vers vSphere 5.1.

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.

Versions d'essai de vSphere 5.1
Les mises à niveau des versions vSphere 5.1 Beta et vSphere 5.0 Release Candidate vers vSphere 5.1 ne sont pas prises en charge. Désinstallez ESXi 5.1 Beta ou Release Candidate et vCenter Server 5.1 Beta ou Release Candidate puis lancez de nouvelles installations de vCenter Server 5.1 et ESXi 5.1. Si vous testiez les versions Beta ou Release Candidate de vSphere 5.1, VMware vous recommande de recréer les données de ces configurations que vous souhaitez conserver sur vSphere 5.1.

Mises à niveau vCenter Server

vSphere 5.1 prend en charge les scénarios de mise à niveau suivants.

  • Vous pouvez effectuer les mises à niveau sur place de systèmes 64 bits de vCenter Server 4.x et de vCenter Server 5.0 vers vCenter Server 5.1.
    Vous ne pouvez pas mettre à niveau une instance de vCenter Server 4.x opérationnelle sous Windows XP Professional x64 Edition.

  • Les clients avec VirtualCenter 2.5 update 6 et les versions ultérieures avec un système d'exploitation 32 bits devront effectuer une mise à niveau de migration vers vCenter Server 5.0 comme première étape du processus de mise à niveau en raison des différences 32 bits/64 bits. Après cette mise à niveau de la migration, les clients pourront effectuer une mise à niveau sur place de la version 5.0 vers la version 5.1. Consultez la documentation Mise à niveau vSphere de la version 5.0.

  • vCenter Server 5.1 peut gérer des hôtes ESX 5.x dans un même cluster avec des hôtes ESX/ESXi 4.x. vCenter Server 5.1 ne peut pas gérer les hôtes ESX 2.x ou 3.x.

Mises à niveau ESX/ESXi

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

  • vSphere Update Manager. Vous pouvez utiliser vSphere Update Manager pour mettre à niveau, mettre à jour et apporter des correctifs aux hôtes en cluster et aux machines virtuelles. Si votre site utilise vCenter Server, VMware recommande d'utiliser vSphere Update Manager. Pour effectuer une mise à niveau orchestrée de l'hôte ou d'une machine virtuelle, reportez-vous aux instructions figurant dans la documentation Mise à niveau vSphere. Pour obtenir des informations complètes sur vSphere Update Manager, consultez la documentation Installation et administration de VMware vSphere Update Manager.

  • Mise à niveau interactive au moyen d'une image ISO du programme d'installation d'ESXi sur CD-ROM, DVD, ou lecteur flash USB. Vous pouvez lancer le programme d'installation d'ESXi 5.1 à partir d'un lecteur de CD/DVD ou d'un 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 vers ESXi 5.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.0.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.0.x à l'aide de l'utilitaire de ligne de commande esxclipour ESXi afin d'installer ESXi 5.1 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 esxclipour mettre à niveau des hôtes ESX ou ESXI vers les versions 5.x d'ESX/ESXI antérieures à la version 5.0.

Composants en libre accès pour VMware vSphere 5.1

Les déclarations de copyright et les licences applicables aux composants de logiciels en libre accès distribués dans vSphere 5.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 VM à VM) 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.

Problèmes connus

Les problèmes connus sont classés comme suit :

Problèmes d'installation
  • Pour l'installation Stateful de 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 Stateful 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

  • La configuration de VDS échoue pour les systèmes ESXi démarrés avec Auto Deploy
    Dans un cluster, seuls deux hôtes sont capables d'exécuter une machine virtuelle sur laquelle Fault Tolerance (FT) est activée. L'un des hôtes est redémarré avec Auto Deploy. La configuration de VDS échoue, et l'hôte reste en mode maintenance après avoir été reconnecté au système vCenter Server.
    Ce problème se produit lorsque seul le système ESXi qui est cours de redémarrage peut héberger la machine virtuelle secondaire. Le processus Fault Tolerance ajoute la machine virtuelle secondaire à l'inventaire de l'hôte ESXi qui démarre, et la migration vDS échoue avec une erreur Resource In Use.
    Ce problème a été constaté dans les situations suivantes :

    • Pendant la mise à niveau d'hôtes ESXi qui se trouvent dans un cluster.
    • Si de nombreux hôtes dans un cluster redémarrent simultanément, de sorte que seul un ou deux hôtes démarrent entièrement.
    • Dans un petit cluster (deux ou trois hôtes).

    Solution : Si vous constatez le problème pendant une mise à niveau, désactivez temporairement Fault Tolerance sur les machines virtuelles. Les machines virtuelles peuvent migrer sur l'hôte déjà mis à niveau. Réactivez Fault Tolerance lorsque la mise à niveau est terminée.
    Si le problème se produit lorsque plusieurs hôtes redémarrent ou dans un petit cluster, attendez que plusieurs des hôtes dans le cluster aient terminé le processus de démarrage, puis redémarrez l'hôte affecté. Vous pouvez également désactiver Fault Tolerance sur la machine virtuelle dont la machine virtuelle secondaire est assignée à l'hôte affecté.

  • Sur HP DL980 G7, les hôtes ESXi ne démarrent pas via Auto Deploy lorsque des NIC intégrés sont utilisés
    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 un NIC additionnel approuvé par HP sur l'hôte, par exemple un HP NC3 60T, et utilisez ce NIC pour le démarrage PXE.

  • L'installation de vCenter Server et des composants associés échoue si le nom d'utilisateur de l'utilisateur connecté contient des caractères qui ne sont pas au format ASCII
    Si le nom d'utilisateur de l'utilisateur actuellement connecté contient des caractères qui ne sont pas au format ASCII, l'installation de vCenter Server, de vCenter Inventory Server, de vCenter Single Sign On ou de vSphere Web Client échoue avec le message d'erreur suivant : Le nom d'utilisateur comporte des caractères qui ne sont pas au format ASCII. Veuillez vous connecter avec un nom d'utilisateur comportant uniquement des caractères au format ASCII.

    Solution : Connectez-vous avec un nom d'utilisateur qui contient uniquement des caractères au format ASCII, puis relancez l'installation.

  • L'installation d'Auto Deploy échoue si le chemin d'accès de l'installation comporte des caractères qui ne sont pas au format ASCII
    Si vous sélectionnez un dossier qui contient des caractères qui ne sont pas au format ASCII lorsque vous exécutez le programme d'installation d'Auto Deploy, l'erreur suivante se produit 
    : Erreur 29106. Erreur inconnue.

    Solution : Sélectionnez un dossier dont le nom du chemin d'accès comporte uniquement des caractères au format ASCII.

  • 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'aucun NIC n'est connecté à la machine
    Si le fichier kickstart se trouve sur lecteur de CD-ROM dans un système auquel aucun NIC n'est connecté, 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.

  • Le service VMware VirtualCenter Management Webservice ne parvient pas à démarrer après que vCenter Server a été installé dans un emplacement qui contient une combinaison des caractères spéciaux !, @, ou #
    Si le chemin d'accès de l'installation de vCenter Server contient une combinaison des caractères spéciaux !, @, ou #, l'installation de vCenter Server réussit mais le service VMware VirtualCenter Management Webservice ne démarre pas, et la connexion à vCenter Server échoue avec l'erreur do not have permissions. Par exemple, le chemin d'accès de l'installation qui suit produirait l'erreur : C:\VMware!@SingleSign@On!#$Installer.

    Solution : Installez vCenter Server dans l'emplacement par défaut ou dans un emplacement personnalisé qui ne comporte pas de caractères spéciaux.

  • 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

  • L'installation du serveur vCenter Single Sign On échoue sur les systèmes exécutant IBM DB2 9.7 Fix Pack 1 ou une version antérieure
    Les composants de Single Sign On (SSO) nécessitent DB2 9.7 Fix Pack 2 ou une version ultérieure. Lorsque vous essayez d'installer SSO sur un système qui exécute une version de DB2 antérieure à la version 9.7, l'installation échoue.

    Solution : Mettez à jour l'instance DB2 9.7 vers Fix Pack 2 ou une version ultérieure.

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

  • L'installation échoue lorsque vous installez vCenter Single Sign On avec une base de données locale sur une version turque de Windows 2008 R2 64 bits
    Il est possible que vous obteniez une erreur (Erreur 20003 ou 20010) lorsque vous installez vCenter Single Sign On dans un environnement Windows turc et que la base de données se trouve sur le système local. Cette erreur se produit lorsque Microsoft SQL Server met certaines lettres en majuscules, ce qui rend la base de données incompatible avec vCenter Single Sign On.

    Solution :

    1. Installez la base de données sur un système distinct qui exécute une version anglaise de Windows 2008 Server.
    2. Exécutez le programme d'installation de vCenter Single Sign On sur le système qui exécute la version turque de Windows 2008 Server.
    3. Connectez-vous à distance à la base de données.

  • L'installation de vCenter Single Sign On en mode haute disponibilité ou en mode de récupération échoue si le mot de passe principal et le mot de passe administrateur sont différents
    Le comportement suivant se produit lorsque vous installez vCenter Single Sign On en mode haute disponibilité :

    • Lorsque vous indiquez le mot de passe administrateur correct de vCenter Single Sign On, la validation semble réussir, mais l'installation échoue avec une erreur signalant que le mot de passe principal de vCenter Single Sign On est incorrect.
    • Lorsque vous indiquez le mot de passe principal correct de vCenter Single Sign On, la validation échoue parce que le programme d'installation attend le mot de passe administrateur de vCenter Single Sign On.

    Le comportement suivant se produit lorsque vous installez vCenter Single Sign On en mode de récupération :

    • Lorsque vous indiquez le mot de passe administrateur correct de vCenter Single Sign On, l'installation échoue avec une erreur signalant que le mot de passe principal de vCenter Single Sign On est incorrect.
    • Lorsque vous installez vCenter Single Sign On sur une machine du domaine et que vous indiquez le mot de passe principal correct de vCenter Single Sign On, l'installation échoue avec une erreur signalant que le compte du service SSPI ne peut pas être configuré car le programme d'installation attend le mot de passe administrateur de vCenter Single Sign On.
    • Lorsque vous installez Single Sign On sur une machine d'un groupe de travail, l'installation échoue avec une erreur indiquant que la configuration de Lookup Service a échoué. Le fichier journal contient une erreur indiquant que le mot de passe administrateur de vCenter Single Sign On est incorrect.

    Solution : Assurez-vous que le même mot de passe est utilisé comme mot de passe principal de vCenter Single Sign On et comme mot de passe administrateur de vCenter Single Sign On. Vous pouvez vérifier les mots de passe à l'aide des commandes suivantes. <ssoserver folder> par défaut est généralement C:\Program Files\VMware\Infrastructure\SSOServer.

    • Mot de passe principal de vCenter Single Sign On :
      <ssoserver folder>\utils>rsautil.cmd manage-secrets -a list

    • Mot de passe administrateur de vCenter Single Sign On :
      <ssoserver folder>\utils>rsautil.cmd manage-identity-sources -a list -u admin

    Vous pouvez définir les mots de passe à l'aide des commandes suivantes :

    • Mot de passe principal de vCenter Single Sign On :
      <ssoserver folder>\utils\rsautil.cmd manage-secrets -a change -m <master password> -N <new Master Password>

    • Mot de passe administrateur de vCenter Single Sign On :
      <ssoserver folder>\utils\rsautil.cmd reset-admin-password -m <master password> -u <admin> -p <pass>

    Par défaut, le mot de passe administrateur de vCenter Single Sign On expire après 365 jours. Lorsque vous réinitialisez ce mot de passe, réinitialisez également le mot de passe principal de vCenter Single Sign On afin de vous assurer qu'ils restent identiques.

  • L'installation échoue lorsque vous essayez d'installer vCenter Single Sign On dans un environnement IPv6
    Lorsque vous utilisez la commande netsh interface ipv4 uninstallavec un redémarrage dans un environnement exclusivement IPv6 sur Windows 2003, 2008 ou 2008 R2, l'installation de vCenter Single Sign On échoue. L'erreur suivante se produit : Erreur 29114. Impossible de se connecter à la base de données.En outre, l'erreur suivante peut apparaître dans le fichier install.log : Error: Failed to access configuration database: Network error IOException: Address family not supported by protocol family: create.

    Solution : Utilisez le FQDN ou le nom d'hôte du système vCenter Server. La meilleure pratique consiste à utiliser FQDN, qui fonctionne dans tous les cas, au lieu de l'adresse IP, qui peut changer si elle a été attribuée par DHCP. De plus, vous devez réinstaller l'interface IPv4 avec la commande suivante : netsh interface ipv4 install.
    Autre possibilité : sur Windows 2003, 2008 ou 2008 R2, accédez à la boîte de dialogue Modifier les paramètres de l'adaptateur et décochez la case : Protocole Internet version 4 (TCP/IPv4).

  • L'installation de la base de données de vCenter Single Sign On échoue lorsque vous utilisez un guillemet dans votre mot de passe
    Lorsque vous utilisez un guillemet (") dans le mot de passe de Single Sign On, l'installation de la base de données de Single Sign On échoue. Un message d'erreur apparaît lors de l'installation de Single Sign On SQL Express.

    Solution : N'utilisez pas de mot de passe pour Single Sign On contenant des guillemets.

  • L'installation de vCenter Single Sign On échoue lorsque le nom d'hôte du système contient des caractères qui ne sont pas pris en charge
    Un message d'erreur apparaît et l'installation de Single Sign On échoue lorsque le nom d'hôte du système Single Sign On contient des caractères ASCII étendus ou des caractères qui ne sont pas au format ASCII.

    Solution : Utilisez uniquement des caractères au format ASCII pour les noms d'hôte des systèmes sur lesquels Single Sign On est installé.

  • L'installation de Single Sign On échoue lorsque le nom du dossier de Single Sign On contient des caractères qui ne sont pas pris en charge
    Un message d'erreur s'affiche, et l'installation de Single Sign On échoue lorsque le nom du dossier contient des caractères ASCII étendus ou qui ne sont pas au format ASCII.

    Solution : Utilisez uniquement des caractères au format ASCII pour les dossiers source qui contiennent les fichiers du programme d'installation de Single Sign On.

  • La connexion à la base de données MSSQL échoue pendant l'installation de vCenter Single Sign On
    Le message d'erreur La connexion à la base de données a échouéapparaît lorsque vous installez vCenter Single Sign On et que vous utilisez des utilisateurs de base de données MSSQL créés manuellement. Avec les bases de données MSSQL, vous devez utiliser les utilisateurs de base de données d'authentification SQL Server. Les utilisateurs de Windows Authentication ne sont pas pris en charge.

    Solution : Assurez-vous que les utilisateurs de base de données créés manuellement utilisent l'authentification SQL Server.

  • Une erreur se produit en raison de privilèges insuffisants lorsque vous utilisez des utilisateurs de bases de données DB2 créés manuellement
    Lorsque vous installez vCenter Single Sign On et que le programme d'installation demande des informations sur la base de données Single Sign On pour les bases de données existantes, vous pouvez cocher la case Utiliser les utilisateurs de la base de données créés manuellement. Si vous utilisez une base de données DB2 et que vous avez créé manuellement des utilisateurs avec le script rsaIMSLiteDB2SetupUsers.sql, il est possible qu'une erreur se produise et signale que les utilisateurs de la base de données ne disposent pas des privilèges suffisants.

    Solution : Le script rsaIMSLiteDB2SetupUsers.sql, situé dans le répertoire <installation directory>\Single Sign On\DBScripts\SSOServer\schema\db2, n'inclut pas deux des privilèges requis. Si vous utilisez le script pour créer manuellement des utilisateurs, modifiez le script pour inclure les privilèges suivants :
    GRANT DBADM ON DATABASE TO USER RSA_DBA;
    GRANT CREATETAB ON DATABASE TO USER RSA_USER;

Problèmes de mise à niveau

Les problèmes connus qui affectent à la fois l'installation et la mise à niveau sont répertoriés dans Problèmes d'installation.
  • Pendant la mise à niveau de vSphere Authentication Proxy 5.0 vers la version 5.1, un avertissement « mauvais nom d'utilisateur ou mauvais mot de passe» apparaît
    Lorsque vous effectuez une mise à niveau de vSphere Authentication Proxy 5.0 vers la version 5.1, sur les systèmes sur lesquels vCenter Server Heartbeat est installé, le programme d'installation peut afficher l'avertissement Erreur 29453 la connexion a échoué en raison d'un nom d'utilisateur ou d'un mot de passe erroné. Vous pouvez ignorer cet avertissement et continuer l'installation.

Problèmes d'octroi de licence
  • Impossible d'ajouter ESXi 5.1 à vCenter Server en utilisant le compte administrateur nommé
    Lorsque vous essayez d'ajouter un hôte ESXi 5.1 à vCenter Server en utilisant un compte administrateur nommé, une erreur de téléchargement de licence peut se produire : Le téléchargement du fichier de licence depuis <IP address> vers vCenter Server a échoué en raison d'une exception : vim.fault.HostConnectFault.

    Solution : Utilisez le compte racine pour ajouter un hôte ESXi 5.1 à vCenter Server.

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'allocation d'adresses MAC par préfixe et par plage est uniquement prise en charge dans vCenter Server 5.1 et ESXi 5.1
    L'allocation d'adresses MAC par préfixe et par plage est uniquement prise en charge dans vCenter Server 5.1 et ESXi 5.1. Si vous ajoutez une version d'hôte antérieure à 5.1 à vCenter Server 5.1 et que vous n'utilisez pas d'allocation d'adresses MAC par préfixe ou par plage VMware OUI, les machines virtuelles qui ne sont pas affectées d'adresses MAC par préfixe VMware OUI ne pourront pas se mettre sous tension sur leur hôtes dont la version est antérieure à la version 5.1.
    Les schémas d'allocation d'adresses MAC par préfixe et par plage ne sont pas pris en charge sur des hôtes dont la version est antérieure à 5.1 car ceux-ci se valident explicitement si une adresse MAC utilise le préfixe VMware OUI 00:50:56. Si l'adresse MAC n'utilise pas le préfixe 00:50:56, la machine virtuelle avec une version d'hôte antérieure à 5.1 ne parvient pas à se mettre en sous tension.

    Solution :

    1. N'ajoutez pas de version d'hôte antérieure à 5.1 à vCenter Server 5.1.

    2. Si la machine virtuelle a été nouvellement créée et est placée sur des versions d'hôte antérieures à 5.1, modifiez les paramètres de la machine virtuelle. Si l'adresse MAC de la nouvelle machine virtuelle ne comporte pas le préfixe 00:50:56, modifiez son adresse MAC en type d'adresse manuel et indiquez une autre adresse MAC valide avec le préfixe 00:50:56. Après avoir effectué la modification, les adresses MAC sans les préfixes VMware OUI et celles avec pourront coexister dans vCenter Server.

  • L'état d'administration d'un NIC physique n'est pas signalé correctement comme étant désactivé
    Le paramétrage administratif d'un NIC physique en état désactivé n'est pas conforme aux normes IEEE. Lorsqu'un NIC physique est configuré comme étant désactivé 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'un 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 signalera l'état d'administration, mais il le signalera 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é 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é.

  • vMotion et Storage vMotion pour les machines virtuelles sur disques monoflat avec un snapshot ne fonctionnent pas
    Monoflat est un format de disque qui n'est plus pris en charge par VMware. Les disques monoflat peuvent être mis sous tension lorsqu'ils sont liés à des machines virtuelles, mais VMware ne recommande pas la migration des machines virtuelles liées. La migration échoue lorsqu'un snapshot est présent.

    Solution : Modifiez le format du disque avant d'essayer des migrations. VMware prend en charge les formats de disque Système de fichiers de la machine virtuelle (VMFS) eagerzeroedthick, zeroedthick, thin disk et 2gbsparse.

  • Modifications de la prise en charge du pilote Linux
    Les pilotes de périphérique pour les NIC virtuels 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 un NIC virtuel 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 maxProxySwitchPorts n'est pas cohérent après un redémarrage de l'hôte sans état
    Le nombre maximum de ports sur un hôte est réinitialisé à 512 après le redémarrage de l'hôte et l'application d'un profil d'hôte. Lorsque vous configurez maxProxySwitchPorts sur un hôte sans état spécifique sur un commutateur distribué, il est possible que le paramètre ne demeure pas quand l'hôte est redémarré. Ce problème s'applique uniquement aux hôtes sans état qui font partie d'un commutateur distribué et dont le paramètre maxProxySwitchPorts a été modifié.

    Solution : Modifiez manuellement les paramètres maxProxySwitchPorts des hôtes après le redémarrage.

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

  • Les session en miroir distantes encapsulées nécessitent que l'IP de destination soit une IP monodiffusion valide
    Dans une session en miroir distante encapsulée, un vSphere Distributed Switch redirige le trafic d'origine vers l'IP de destination spécifiée. Si vous avez sélectionné une adresse IP de multidiffusion ou de diffusion comme destination de la session, le trafic d'origine est mis en miroir vers plusieurs destinations. Cette opération peut consommer une quantité importante de bande passante réseau physique. Si vous avez spécifié une adresse IP non valide, par exemple une adresse IP réservée, le trafic d'origine n'est pas mis en miroir.

    Solution : Configurez des adresses IP multidiffusion valides comme destination de la session en miroir distante encapsulée.

  • La recherche de groupes de ports virtuels distribués par un VLAN privé peut renvoyer des résultats erronés dans un environnement avec plusieurs vCenter Server
    Lorsque vous gérez plusieurs vCenter Servers avec une instance de vSphere Web Client, une recherche de groupes de ports virtuels distribués qui ont des paramètres VLAN privé spécifiques peut non seulement renvoyer les groupes de ports spécifiques, mais également des groupes de ports qui ne devraient pas figurer dans les résultats.

    Solution : Effectuez une autre recherche.

  • L'attribution d'un nom à un profil de protocole réseau avec des codets de substitution provoque une erreur
    La création d'un profil de protocole réseau avec des codets de substitution provoque un échec et un message d'erreur lié à la gestion d'UTF-8 dans vSphere Web Client.

    Solution : Évitez d'utiliser des codets de substitution pour les profils de protocole d'hôte.

  • Si le fichier kickstart d'une installation scriptée appelle un NIC qui est déjà utilisé, 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 un 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 : un NIC configuré pour SWFCoE/SWiSCSI, et un NIC configuré 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 un NIC disponible dans le fichier kickstart pour configurer un réseau de gestion après l'installation.

  • Impossible de joindre vCenter Server au groupe en Linked Mode
    Vous ne parvenez pas à joindre vCenter Server à un groupe en Linked Mode si vous avez modifié le port HTTPS de vCenter Server pendant une mise à niveau de vCenter Server.

    Solution :

    1. Ouvrez vSphere Client.
    2. Accédez à Administration > Paramètres de vCenter Server > Paramètres avancés.
    3. Sélectionnez la clé nommée VirtualCenter.VimApiURL.
    4. Dans le champ de la valeur, remplacez le numéro de port dans l'URL par celui qui vous a été donné lors de la mise à niveau de vCenter Server.
    5. Redémarrez le service VMware VirtualCenter Server.
    6. Démarrez la configuration Modifier Linked Mode en cliquant sur le Menu démarrer > VMware > Configuration vCenter Server Linked Mode. Cette option lie un vCenter Server à un groupe en linked mode.

  • 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

  • La topologie standard de commutateur de vSphere Web Client montre les règles de basculement au niveau du commutateur et au niveau du groupe de ports
    L'icône d'état du port ainsi que l'étiquette Stand By ou Unused s'appliquent aux règles de basculement au niveau du commutateur. Lorsqu'un groupe de ports est sélectionné, la ligne orange s'applique aux règles de basculement au niveau du groupe de ports.

    Solution : Aucune. Les adaptateurs réseau physiques soulignés en orange sont utilisés pour le trafic du groupe de ports même s'ils sont étiquetés Stand By ou Unused dans leur topologie.

  • ESXi échoue avec les NIC BladeEngine-3 10G Emulex (pilote be2net)
    ESXi risque d'échouer sur les sytè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
  • La machine virtuelle a observé une latence de la banque de données
    Il est possible que vous voyiez des valeurs de latence de la banque de données incorrectes observées par la machine virtuelle lors de l'exécution de SDRS ou de SIOC sur une banque de données connectée à une combinaison d'hôtes ESXi 5.0 et ESXi 5.1. ESXi 5.1 recueille une nouvelle statistique appelée « la machine virtuelle a observé une latence de la banque de données » qui n'est pas recueillie dans ESXi 5.0. En raison de cette différence, il n'est pas possible de calculer correctement la moyenne des valeurs statistiques entre un mélange d'hôtes ESXi 5.0 et ESXi 5.1. Cela peut également se traduire par un comportement d'équilibrage de charge E/S SDRS réduit lorsqu'un cluster de la banque de données a des banques de données montées avec une combinaison d'hôtes ESXi 5.0 et ESXi 5.1, par rapport à un cluster de banque de données comportant uniquement des hôtes ESXi 5.1.

    Solution : Mettez à niveau tous les hôtes vers ESXi 5.1.

  • Activation des diagrammes de performance historiques des banques de données et des clusters de banques de données dans un environnement activé par un DRS de stockage
    Dans un environnement vSphere 5.1, si le niveau de collecte pour les statistiques est défini sur sa valeur par défaut de 1, seuls les diagrammes de performance en temps réel sont affichés pour les compteurs de données DRS de stockage associés aux mesures de banques de données et des clusters de banques de données. Si vous sélectionnez une fréquence différente, le diagramme affiche No data available. Cette situation est due au fait que de nombreuses mesures de banques de données et des clusters de banques de données sont passées, par défaut, au niveau 3 de collecte de statistiques, afin d'améliorer les performances.

    Solution : Pour activer les diagrammes de performance historiques des mesures des banques de données et des clusters de banques de données, transférez les compteurs DRS de stockage sur le niveau 1 de collecte de statistiques. Pour plus d'informations, consultez l' article 2009532 de la base de connaissances. Sachez que les modifications des niveaux de compteurs peuvent entraîner une augmentation importante de la collecte et du stockage de données ainsi qu'une baisse des performances correspondante. Pour plus d'informations, voir Modifier les niveaux de collecte des compteurs de performance dans le Guide de programmation de vSphere Web Services et la Référence vSphere API.

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

  • Storage vMotion peut échouer avec un message d'erreur
    Lorsque la configuration du stockage est surchargée et accentuée, il est possible que le temps d'ouverture d'un fichier sur une banque de données VMFS soit beaucoup plus long. Ce délai peut provoquer un échec de Storage vMotion d'une machine virtuelle avec le message d'erreur Un chemin d'accès au disque parent est nécessaire pour le snapshot du disque/chemin d'accès/à/disk/XXX.vmdk.

    Solution : Exécutez le script Power CLI suivant pour recharger l'information de disque de la machine virtuelle et réexécuter Storage vMotion.

    1. Remplacez ce qui suit par les valeurs appropriées :
      Connect-VIServer ...
      $hostName = ...
      $vmName = ...
    2. Obtenez l'objet public API ServiceInstance.
      $serviceInstance = Get-View ServiceInstance
    3. Chargez l'assemblage InternalVimService51.
      [System.Reflection.Assembly]::LoadWithPartialName( InternalVimService51)
    4. Configurez l'instance API VimService interne.
      $internalVimService = new-Object InternalVimApi_51.InternalvimService
      $internalVimService.Timeout = $serviceInstance.Client.VimService.Timeout;
      $internalVimService.Url = $serviceInstance.Client.VimService.Url;
      $internalVimService.CookieContainer = $serviceInstance.Client.VimService.CookieContainer;
      $svcRef = new-object InternalVimApi_51.ManagedObjectReference
      $svcRef.type = ServiceInstance;
      $svcRef.Value = ServiceInstance;
      $internalServiceContent = $internalVimService.RetrieveServiceContent($svcRef);
    5. Récupérez l'objet VMHost.
      $vmhost = Get-VMHost $hostName | Get-View
      $hostRef = new-object InternalVimApi_51.ManagedObjectReference
      $hostRef.type = $vmhost.MoRef.Type
      $hostRef.Value = $vmhost.MoRef.Value
    6. Récupérer le gestionnaire de configuration interne.
      $configManager = $internalVimService.RetrieveInternalConfigManager($hostRef)
    7. Récupérez l'objet VM.
      $vm = Get-VM $vmName | Get-View
      $vmRef = new-object InternalVimApi_51.ManagedObjectReference
      $vmRef.type = $vm.MoRef.Type
      $vmRef.Value = $vm.MoRef.Value
    8. Rechargez les disques de la VM.
      $internalVimService.ReloadDisks_Task($configManager.llProvisioningManager, $vmRef, @( currentConfig, snapshotConfig))

    Pour éviter un échec de Storage vMotion lorsque la baie de stockage est accentuée et lente, modifiez l'option suivante dans le fichier /etc/vmware/configpour augmenter le nombre de tentatives d'ouverture de disque :
    diskLibMiscOptions.openRetries = grand nombre, par exemple 99

  • 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 disque 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. Supprimez 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 un 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 un 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é à un 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 que Active Directory est activé, profil qui a été 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. Essayez ceci :
      • 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. Modifiez les valeurs de

  • Des défaillances de conformité de la stratégie réseau se poursuivent sur les profils d'hôte créés depuis des hôtes ESXi 4.1 ou ESXi 4.0 et appliqués à des hôtes ESXi 5.1
    Après avoir appliqué un profil d'hôte créé depuis un hôte ESXi 4.1 ou ESXi 4.0 à un hôte ESXi 5.1, il est possible que les défaillances de conformité du profil d'hôte suivantes se poursuivent :

    For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.failureCriteria doesn't match
    For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.reversePolicy doesn't match

    Les paramètres réseau ci-dessus ne sont pas pris en charge sur les hôtes ESXi 5.1 et ne sont plus configurés lors de l'application d'un profil d'hôte qui contient ces paramètres.

    Solution : Deux solutions sont possibles :

    • Après l'avoir appliqué le profil d'hôte créé à l'origine depuis un hôte ESXi 4.1 vers un hôte ESXi 5.1, créez un nouveau profil d'hôte depuis l'hôte ESXi 5.1 et attachez-le à cet hôte ESXi 5.1 et aux autres hôtes ESXi 5.1 concernés.
    • Modifiez la stratégie d'association de cartes réseau dans le profil d'hôte avec l'option L'utilisateur doit choisir explicitement l'option de stratégie au lieu de l'option Appliquer la stratégie d'association de cartes réseau spécifiée.

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

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

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

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

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

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

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

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

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

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

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

  • Des erreurs de conformité du profil d'hôte se produisent lors de la suppression d'hôtes ESXi de l'inventaire de vCenter Server
    Lors de la vérification de conformité d'un profil d'hôte, vCenter Server a parfois besoin d'effectuer une requête auprès d'un hôte ESXi pour des données liées aux profils d'hôtes. L'hôte cible de l'opération de vérification de conformité n'est pas nécessairement l'hôte ESXi que vCenter Server utilise pour ces requêtes de données de profil d'hôte. Une condition de concurrence existe lorsqu'un client supprime un hôte ESXi de l'inventaire de vCenter Server et effectue en même temps une opération de vérification de conformité. Pendant ce temps, une requête pour des données de profil d'hôte provoque une erreur avec le message Host Unavailable For Checking Compliance.

    Solution : Après avoir supprimé l'hôte de l'inventaire de vCenter Server, revérifiez la conformité de l'hôte. vCenter Server essaye d'utiliser un hôte différent pour demander les données du profil d'hôte.

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

  • Des défaillances de conformité de l'ensemble de règles du pare-feu peuvent se produire après la correction d'un hôte ESXi 5.1 avec un profil d'hôte ESXi 5.0
    Lors de la vérification de conformité utilisant un profil d'hôte créé depuis un hôte ESXi 5.0, vous pouvez voir des défaillances de conformité liées à CIMHttpsService et à CIMHttpService.

    Dans certains cas, une discordance dans le profil d'hôte peut exister entre l'état activé de l'ensemble de règles de pare-feu pour les services CIM/WBEM (CIMHttpService et CIMHttpsService) et la stratégie de démarrage des services des services CIM/WBEM (sfcb-watchdog). Lorsque le service démarre, les ports du pare-feu s'ouvrent automatiquement. Il s'en suit une défaillance de conformité de l'ensemble de règles de pare-feu du service CIM.

    Solution : Procédez au choix comme suit :

    • Rendez le profil d'hôte cohérent en modifiant l'ensemble de règles de pare-feu pour CIMHttpService et CIMHttpsService dans le profil d'hôte afin que le paramètre activé soit True.
    • Accédez à la configuration du profil de sécurité de l'hôte ESXi depuis lequel le profil d'hôte a été créé (ou le nouvel hôte de référence, s'il a changé depuis la création), puis actualisez manuellement les informations du pare-feu. Effectuez ensuite une opération Mettre à jour le profil d'hôte depuis l'hôte de référence.

    Si vous utilisez vSphere Web Client, vous pouvez également effectuez une opération « Copier les paramètres depuis l'hôte » afin de mettre à jour le profil d'hôte.

  • 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'interface Web de vCenter Server Appliance ne fonctionne pas avec Firefox 14
        Avec Firefox 14 ou une version ultérieure, les onglets Administration, Services et Stockage n'apparaissent pas dans l'interface Web de vCenter Server Appliance. La page Admin s'affiche mais reste vierge. Ceci empêche la configuration de l'appartenance à Active Directory et d'autres paramètres.

        Solution : Utilisez un autre navigateur pris en charge ou utilisez la version étendue du support Firefox basée sur Firefox 10 et téléchargeable sur http://www.mozilla.org/en-US/firefox/organizations/all.html.

      • Les plug-ins désinstallés apparaissent dans l'interface de gestion des plug-ins de vSphere Web Client
        Si vous désinstallez un plug-in vSphere Web Client actuellement chargé, l'interface de gestion des plug-ins continue d'afficher le plug-in jusqu'au redémarrage du serveur Web. La fonctionnalité de plug-in elle-même n'est plus disponible dans vSphere Web Client.

        Solution : Redémarrez le serveur Web.

      • La console de la machine virtuelle dans vSphere Web Client ne répond pas aux entrées à la souris
        Sur les machines virtuelles exécutant certaines distributions de Linux, il est possible que la console ne réponde pas au départ aux entrées à la souris lorsque vous lancez la console depuis vSphere Web Client.

        Solution : Cliquez sur Plein écran pour faire passer la console en mode plein écran.

      • Un menu contextuel du navigateur Web apparaît en cliquant avec le bouton droit sur un objet dans l'inventaire de vSphere Web Client.
        Avec Windows 8 et Internet Explorer 10, lorsque vous accédez à un objet dans l'inventaire de vSphere Web Client et que vous cliquez sur le bouton droit, le menu contextuel du navigateur s'affiche au-dessus du menu contextuel de l'objet. .

        Solution : Cliquez avec le bouton droit à un autre endroit dans l'application afin d'afficher le menu contextuel de l'objet.

      • Impossible de supprimer un dossier
        Si vous avez l'autorisation Dossier.Supprimer dossier définie uniquement au niveau du dossier, toute tentative de suppression de ce dossier produit un message d'erreur indiquant que vous ne disposez pas des autorisations requises.

        Solution : Aucune.

      • Erreurs Échec de la lecture de la requêtedans vpxd.log
        Des messages d'erreur similaires aux suivants peuvent apparaître dans :
        2012-05-15T08:41:03.120Z [7F7DCB7C6700 error 'QsAdapter.HTTPService'] Failed to read request; stream: UNIX(/var/run/vmware/vpxd-qsadapter-pipe), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:03.120Z [7F7DCB889700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:33.124Z [7F7DCB5BE700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:48.125Z [7F7DCB57D700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:48.125Z [7F7DCAD75700 error 'SSL SoapAdapter.HTTPService'] Failed to read request; stream: SSL(no stream), error: N7Vmacore16TimeoutExceptionE(Operation timed out)
        2012-05-15T08:41:58.127Z [7F7DCBC58700 error 'SoapAdapter.HTTPService'] Failed to read request; stream: TCP(), error: N7Vmacore16TimeoutExceptionE(Operation timed out)

        Ces entrées de journal ne sont sont pas de véritables erreurs, elles indiquent uniquement une tentative de connexion à un service externe qui n'est pas en cours d'exécution.

        Solution : Aucune.

      • Les noms de balise ne peuvent pas contenir de codets de substitution
        Si vous tentez de créer une balise dont le nom comporte des codets de substitution, la création de la balise échoue.

        Solution : N'utilisez pas de codets de substitution dans les noms de balise.

      • Les modifications du nom d'hôte du système vCenter Server ne sont pas reflétées dans vSphere Web Client ou dans l'inventaire de vSphere Web Client
        Si vous modifiez le nom d'hôte d'un système vCenter Server ou vCenter Server Appliance, la machine locale affiche le nouveau nom d'hôte, mais l'ancien nom apparaît dans vSphere Web Client et dans l'inventaire de vSphere Client.

        Solution : Utilisez vSphere Web Client ou vSphere Client pour modifier le nom d'affichage du système vCenter Server.

        Dans vSphere Web Client, procédez comme suit :

        1. Accédez à l'instance vCenter Server et sélectionnez l'onglet Gérer.
        2. Dans Paramètres, cliquez sur Général.
        3. Dans la boîte de dialogue Modifier les paramètres de vCenter Server, sélectionnez Paramètres d'exécution.
        4. Dans Nom du vCenter Server, tapez le nom du système vCenter Server.
        5. Cliquez sur OK.

        Dans vSphere Client, procédez comme suit :

        1. Sélectionnez Administration > Paramètres de vCenter Server.
        2. Si le système vCenter Server fait partie d'un groupe en Linked Mode, sélectionnez le serveur à configurer dans la liste déroulante vCenter Server actuel.

          Remarque : Le Linked Mode n'est pas pris en charge sur vCenter Server Appliance.

        3. Dans le volet de navigation, sélectionnez Paramètres d'exécution.
        4. Dans Nom du vCenter Server, tapez le nom du système vCenter Server.
        5. Cliquez sur OK.

      • vSphere Web Client ne répond plus lors de l'exécution de plusieurs opérations
        Lorsque vous effectuez des opérations qui affectent plusieurs machines virtuelles, par exemple mettre sous tension ou hors tension plusieurs machines virtuelles, il est possible que vSphere Web Client ne réponde plus jusqu'à ce que les tâches soient terminées. Ce problème est lié à une limitation de Flash quant au nombre de tâches qu'il est possible d'exécuter en parallèle. vSphere Web Client ne répond plus lorsque toutes les tâches sont envoyées au serveur.

        Solution : Aucune.

      • La sauvegarde de la base de données d'Inventory Service échoue
        Une sauvegarde de la base de données d'Inventory Service pendant l'exécution d'Inventory Service échoue en raison d'une erreur bad_certificate.

        Solution : Fermez Inventory Service avant d'effectuer une sauvegarde.

        Sur un système Windows, procédez comme suit :

        1. Arrêtez Inventory Service :
          1. Ouvrez le panneau de configuration des outils d'administration de Windows, puis sélectionnez Services.
          2. Cliquez avec le bouton droit sur VMware vCenter Inventory Service et sélectionnez Arrêter.
        2. Ouvrez l'invite de commande et remplacez le répertoire par vCenter_Server_installation_directory\Infrastructure\Inventory Service\scripts.

          vCenter_Server_installation_directory est le répertoire dans lequel vous avez installé vCenter Server. Par défaut, il s'agit de C:\VMware\.

        3. Lorsque vous y êtes invité, exécutez la commande suivante pour sauvegarder la base de données d'Inventory Service : backup.bat -file backup_file_name.

        Sur vCenter Server Appliance, procédez comme suit :

        1. Ouvrez une console et exécutez la commande service vmware-inventory service stoppour arrêter Inventory Service.
        2. Remplacez le répertoire par /usr/lib/vmware-vpx/inventoryservice/scripts/.
        3. Exécutez la commande suivante pour effectuer une sauvegarde de la base de données de Inventory Service : ./backup.sh -file backup_file_name.

      • Impossible d'ajouter un hôte ESXi à vCenter Server Appliance avec l'adresse IPv6 de lien local
        Si vous essayez d'ajouter un hôte ESXi à vCenter Server Appliance avec une adresse IPv6 de lien local de la forme fe80::*, vous voyez apparaître le message, Cannot contact the specified host.

        Solution : Utilisez une adresse IPv6 valide pour l'hôte qui ne soit pas une adresse de lien local.

      • L'activation de DRS pour un cluster engendre un avertissement erroné sur l'activation de DRM
        Si vous reprenez une tâche Modifier les services de cluster depuis le volet Travail en cours et que vous activez DRS, vous pouvez voir un message indiquant de manière erronée que DPM sera activé. Cette erreur se produit après vous être déconnecté puis reconnecté à vSphere Web Client tandis que la tâche Modifier les services de cluster est enregistrée dans le volet Travail en cours.

        Solution : Aucune solution n'est nécessaire. DPM ne sera pas activé.

      • Une recherche échoue et les plugins Intégrité du matériel et État du matériel sont désactivés dans vSphere Client
        vSphere Client ne se connecte pas à Inventory Service lorsqu'il est installé sur Windows 2003 ou Windows XP. Les effets sont les suivants :

        • Lorsque vous essayez d'effectuer une recherche dans l'inventaire de vSphere Client, vous voyez apparaître le message d'erreur, La connexion au service de requête a échoué. Une erreur de communication s'est produite lors de l'envoi des données au serveur. (La connexion sous-jacente a été fermée : Une erreur inattendue s'est produite lors d'un envoi.)
        • Les plugins Intégrité du matériel et État du matériel sont désactivés et ne peuvent pas être affichés dans vSphere Client.

        Solution : Aucune pour Windows XP 32 bits. Pour Windows 2003 ou Windows XP 64 bits, appliquez le correctif logiciel approprié figurant dans la liste qui suit.

        Plateforme : x64
        Langue : Anglais
        Emplacement : ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351403_ENU_x64_zip.exe)

        Plateforme : ia64
        Langue : Anglais
        Emplacement : ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351397_ENU_ia64_zip.exe)

        Plateforme : i386
        Langue : Anglais
        Emplacement : ( http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe)

      • Les service vCenter Server et vCenter Single Sign On ne démarrent pas
        Lorsque vous modifiez le nom d'hôte ou l'attribution du port du serveur de la base de données de Single Sign On, Single Sign On échoue. De ce fait, le démarrage de vCenter Server échoue. Ce problème se produit lorsque vous utilisez SQL Server Express Edition, qui est installé avec Single Sign On et vCenter Server. Si SQL Server Express Edition est configuré pour utiliser des ports dynamiques, l'attribution de ports peut changer lors du redémarrage du système. Ce problème se produit lorsque le port est déjà occupé par un autre service.

        Solution : Lorsque vous modifiez le nom d'hôte ou le port du serveur de la base de données de Single Sign On, vous devez reconfigurer Single Sign On avec le nouveau nom d'hôte ou le nouveau port.

        1. Arrêtez le serveur vCenter Single Sign On.
        2. Entrez la commande suivante :
          <ssoserver folder>\utils> ssocli configure-riat -a configure-db --database-host <new database server> --database-port <new database port> -m <master password>
        3. Modifiez le fichier texte suivant afin de remplacer le numéro de port par la nouvelle valeur sur la ligne qui commence par db.url=:
          <ssoserver folder>\webapps\lookupservice\WEB-INF\classes\config.properties
        4. Démarrez le serveur vCenter Single Sign On.

      • L'attachement d'une base de données Oracle à vCenter Server Appliance provoque une erreur relative à un schéma incompatible
        Si vous tentez de configurer vCenter Server Appliance avec une base de données Oracle externe qui auparavant était utilisée avec vCenter Server 5.0 Appliance, vous voyez apparaître le message d'erreur, Error: Incompatible DB schema version.

        Solution : Vous pouvez utiliser l'assistant de configuration de vCenter Server Appliance pour réinitialiser la base de données. Cette opération détruira tous les enregistrements qui se trouvent actuellement dans la base de données. Pour conserver les enregistrements de la base de données, suivez le processus de mise à niveau décrit dans la documentation relative à la mise à niveau de vSphere pour effectuer une mise à niveau de vCenter Server Appliance et de la base de données de vCenter Server 5.0 vers vCenter Server 5.1.

        Pour réinitialiser la base de données :

        1. Connectez-vous à l'interface Web de vCenter Server Appliance et démarrez l'assistant de configuration.
        2. Entrez les informations relatives à la base de données.

          L'assistant affiche le message, The database has been initialized with an incompatible schema version.

        3. Sélectionnez réinitialiser le contenu de la base de données.

      • Des erreurs liées aux scripts python apparaissent lorsqu'un fichier de configuration non valide est téléchargé vers l'assistant de configuration de vCenter Server Appliance
        Dans l'assistant de configuration initiale de vCenter Server Appliance, si vous sélectionnez Télécharger le fichier de configuration et que vous sélectionnez un fichier non valide, l'interface Web affiche des erreurs liées aux scripts python.

        Solution : Aucune.

      • Erreurs de connexion ou de navigation après la mise à niveau de vCenter Server Appliance avec une adresse IP statique
        Après avoir effectué une mise à niveau de vCenter Server Appliance avec une adresse IP statique, les erreurs suivantes peuvent se produire :

        • Lorsque vous essayez de vous connecter à l'interface Web de vCenter Server Appliance, vous pouvez voir l'erreur, Connexion au serveur impossible. Veuillez réessayer.
        • Lorsque vous essayez d'accéder à une nouvelle page dans l'interface Web de vCenter Server Appliance, vous pouvez voir l'erreur, Not Found.

        Solution : Videz le cache du navigateur et reconnectez-vous à l'interface Web de vCenter Server Appliance.

      • Active Directory n'est pas reconnu comme source d'identité si vCenter Server Appliance est joint à un domaine Active Directory avant que vCenter Single Sign On ne démarre
        Ce problème peut se produire lorsque vCenter Server Appliance est joint à un domaine Active Directory dans le cadre de la configuration initiale avec l'assistant de configuration de l'interface Web. Après la configuration, les services vCenter Server et vCenter Single Sign On associés peuvent fonctionner, mais Active Directory n'est pas reconnu comme une source d'identité.

        Solution : Effectuez l'une des opérations suivantes.

        • Redémarrez vCenter Server Appliance.
        • Redémarrez vCenter Single Sign On, puis le service vSphere Web Client.

      • Impossible de reconfigurer les paramètres de vCenter Server Appliance qui ont échoué lors de la configuration initiale
        Le première fois que vous vous êtes connecté à vCenter Server Appliance, l'assistant de configuration initiale vous a demandé d'accepter le CLUF et de configurer les options des bases de données, de vCenter Single Sign On et d'Active Directory. Si l'une de ces étapes échoue, l'assistant de configuration termine les étapes restantes et démarre le service vCenter Server.

        Si vous essayez de reconfigurer l'un des paramètres que l'assistant n'est pas parvenu à configurer, vous voyez le message, Erreur : VPXD doit être arrêté pour effectuer cette opération.

        Solution : Procédez comme suit :

        1. Connectez-vous à la console de vCenter Server Appliance, puis exécutez la commande suivante : /etc/init.d/vmware-vpxd stop
        2. Reconnectez-vous à l'interface Web de vCenter Server Appliance et reconfigurez les paramètres selon vos besoins.
        3. Redémarrez le service vCenter Server avec l'interface Web.

      • L'élément associé figurant dans les résultats de la recherche avancée peut ne pas être l'élément spécifié dans les critères de recherche
        Lorsque vous effectuez une recherche avancée dans vSphere Web Client et que vous spécifiez une relation entre les objets, les résultats de la recherche sont corrects, mais l'objet associé affiché dans les résultats peut ne pas être l'objet que vous avez spécifié dans les critères de recherche.

        Si par exemple vous recherchez tous les dossiers qui disposent d'un hôte dont le nom contient « exemple », la liste correcte des dossiers apparaît dans les résultats de la recherche. Toutefois, l'hôte figurant dans la colonne des objets associés peut ne pas être l'hôte dont le nom contient « exemple », mais un hôte portant un nom différent qui se trouve également dans ce dossier.

        Solution : Aucune.

      • Certains caractères chinois ou japonais ne s'affichent pas correctement dans vSphere Web Client
        Lorsque vous accédez à vSphere Web Client depuis un système Linux dont le chinois ou le japonais est la langue par défaut, certains textes dans vSphere Web Client s'affichent sous forme de boîtes rectangulaires au lieu des caractères chinois ou japonais corrects.

        Solution : Installez Linux avec l'anglais comme langue par défaut, puis choisissez le chinois ou le japonais comme langue par défaut après l'installation.

      • L'assistant de configuration initiale de vCenter Server Appliance ne prend pas en charge la configuration d'adresses IP statiques
        Lorsque vous vous connectez à l'interface Web de vCenter Server Appliance pour la première fois après le déploiement, l'assistant de configuration démarre et vous invite à accepter le CLUF et à configurer les options des bases de données, de vCenter Single Sign On et d'Active Directory. L'assistant ne présente pas les options de configuration du réseau. vCenter Server Appliance est configuré pour utiliser DHCP par défaut.

        Solution : Si vous avez terminé l'assistant de configuration initiale, une modification vers une configuration de réseau statique nécessite une modification du certificat SSL du dispositif :

        1. Sur la page Admin de l'interface Web de vCenter Server Appliance, cliquez sur le bouton Basculer le paramétrage de certificat pour modifier l'option Régénération de certificat activée sur Oui.
        2. Configurez l'adresse IP statique de vCenter Server Appliance.

        Si vous n'avez pas terminé l'assistant de configuration initiale, procédez comme suit :

        1. Ouvrez une session sur l'interface Web de vCenter Server Appliance.
        2. Acceptez le CLUF puis cliquez sur Annuler.
        3. Configurez le réseau.

          Si vous modifiez le nom ou l'adresse IP de l'hôte, vous serez déconnecté de l'interface Web. Reconnectez-vous en utilisant le nouveau nom d'hôte ou la nouvelle adresse IP.

        4. Sur la page de vCenter Server, cliquez sur l'onglet Résumé.
        5. Cliquez sur le bouton Lancer en regard de l'assistant de configuration. Terminez l'assistant de configuration pour finir la configuration initiale du dispositif.

        Si vous utilisez vCenter Server pour déployer vCenter Server Appliance en tant qu'OVF, vous pouvez configurer une adresse IP statique pendant le déploiement. Cependant, cette opération s'applique uniquement aux environnements dans lesquels une instance de vCenter Server est déployée.

      • Impossible de modifier le nom de l'hôte dans l'interface Web de vCenter Server Appliance
        Une tentative de modification du nom d'hôte dans l'interface Web de vCenter Server Appliance peut échouer. Ce problème se produit lorsqu'un dispositif est configuré de sorte à utiliser une adresse IP et un nom d'hôte statiques. Dans l'onglet «Réseau », si vous modifiez à la fois le nom d'hôte et l'adresse IP et que vous enregistrez ces paramètres, seule l'adresse IP est modifiée. Le nom d'hôte reste identique.

        Solution : Si vous devez modifier à la fois le nom d'hôte et l'adresse IP, effectuez ces modifications en deux opérations distinctes.

      • La modification du MTU de matériel indépendant iSCSI dans vSphere Client nécessite que vous activiez auparavant les trames Jumbo
        Lorsque vous utilisez vSphere Client pour modifier le paramètre MTU dans la boîte de dialogue Paramètres avancés, vous devez tout d'abord cocher la case Trame Jumbo. Si vous ne le faites pas, la modification du MTU ne se propage pas à l'adaptateur matériel indépendant. Dans vSphere Web Client, la case Trame Jumbo n'est pas présente. Vous modifiez par conséquent la valeur dans la zone d'entrée du MTU.

        Solution :
        Dans vSphere Client :

        1. Sélectionnez un hôte dans le panneau d'inventaire.
        2. Cliquez sur l'onglet Configuration et cliquez sur Adaptateurs de stockage dans le panneau Matériel.
        3. Sélectionnez un adaptateur matériel indépendant dans la liste des adaptateurs de stockage.
        4. Cliquez sur Propriétés, puis sur Avancé.
        5. Activez les trames Jumbo en cochant la case Trame Jumbo.
        6. Modifiez la valeur dans la zone d'entrée du MTU et cliquez sur OK.
        7. Remarque : Si vous activez les trames Jumbo, mais que la valeur de la taille du MTU que vous entrez ne dépasse pas 1500 octets, l'activation des trames Jumbo est ignorée.

        Dans vSphere Web Client :
        1. Accédez à l'hôte dans le navigateur d'objets de vSphere Web Client.
        2. Cliquez sur l’onglet Gérer, puis cliquez sur Stockage.
        3. Cliquez sur Adaptateurs de stockage et sélectionnez l'adaptateur iSCSI matériel indépendant dans la liste des adaptateurs.
        4. Dans Détails de l'adaptateur, cliquez sur l'onglet Options avancées, puis cliquez sur Modifier.
        5. Modifiez la valeur du paramètre MTU.

      • Impossible de se connecter à vCenter Server après avoir remplacé les certificats SSL
        Après avoir remplacé les certificats SSL de vCenter Server, il est possible que vous ne parveniez pas à vous connecter au serveur. La raison en est que vCenter Server n'est pas redémarré lorsque vous remplacez les certificats SSL. Vous devez redémarrer le serveur pour actualiser les certificats pour Single Sign On.

        Solution : Redémarrez vCenter Server après avoir remplacé les certificats SSL.

      • Une exception d'E/S Java apparaît dans le fichier journal lorsque vous démarrez vCenter Single Sign On sur vCenter Server Appliance
        Lorsque vous démarrez vCenter Single Sign On sur un vCenter Server Appliance, une exception d'E/S Java peut apparaître dans /var/log/vmware/sso/catalina.out.

        Par exemple :

        java.io.IOException: ClientAbortException: java.net.SocketException: Broken pipe
        at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:278)
        at com.sun.xml.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:539)

        En outre, lorsque vous arrêtez le serveur Single Sign On sur vCenter Server Appliance, une fuite de mémoire peut apparaître dans /var/log/vmware/sso/catalina.out.

        Par exemple :

        SEVERE: The web application [/ims] appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.

        Solution : Aucune.

      • Le démarrage de vCenter Server peut échouer ou vous ne parvenez pas à vous connecter à vSphere Web Client après avoir redémarré le système du serveur de Single Sign On
        Lorsque vous redémarrez la machine sur laquelle vCenter Single Sign On est installé, des modifications peuvent se produire sur le système. Par exemple, des mises à jours sont appliquées au système d'exploitation, le nom de la machine change, ou la machine est ajoutée ou supprimée du domaine Active Directory. En raison de ces modifications, il est possible que le serveur de Single Sign On ne réponde pas, bien que Single Sign On soit actif. De ce fait, vCenter Server ne démarre pas. Cela peut se produire si vous clonez ou modifiez les paramètres d'une machine virtuelle sur laquelle Single Sign On est installé (par exemple, la quantité de mémoire, le nombre de processeurs, l'adresse MAC, etc.).

        Solution : Procédez comme suit :

        1. Sur le système sur lequel Single Sign On est installé, localisez le répertoire d'installation de Single Sign On et exécutez les commandes suivantes depuis le dossier utils :
          rsautil manage-secrets -a recover -m masterPassword
        2. Redémarrez le service Single Sign On.
        3. Démarrez le service vCenter Server.
        1. Le domaine Active Directory auquel appartient vCenter Server n'apparaît pas dans la liste des serveurs de sources d'identité Single Sign On
          Sur Windows, si vCenter Server est installé sur une machine jointe à un domaine Active Directory, les utilisateurs du domaine n'apparaissent pas dans vSphere Client ou vSphere Web Client. Sur Linux, le message d'erreur Impossible de récupérer l'utilisateur du domaineapparaît.

          Solution : Configurez une zone de recherche directe inversée, un enregistrement de pointeur associé, et synchronisez l'horloge système.

        2. vCenter Server Appliance ne prend pas en charge la configuration d'Active Directory avec IPv6
          Si vous essayez de configurer Active Directory sur vCenter Server Appliance avec IPv6, la configuration échoue.

          Solution : Configurez Active Directory sur vCenter Server Appliance avec IPv4.

        3. Les profils de stockage créés précédemment sur vCenter Server Appliance ne sont pas visibles après une sauvegarde et une restauration de la base de données d'Inventory Service
          Après avoir effectué une sauvegarde et une restauration de la base de données d'Inventory Service, les profils de stockage que vous avez créés précédemment ne sont pas visibles sur vCenter Server Appliance.

          Solution :

          1. Connectez-vous à la console Web de vCenter Server Appliance à l'adresse https:// adresse_ip-du-dispositif:5480.
          2. Redémarrez le service vmware-SPS.

          Lorsque le service est redémarré, les profils de stockage sont à nouveau visibles.

        4. vCenter Server Appliance ne prend pas en charge les adresses IPv6 dans le paramètre proxy
          Si vous essayez d'entrer une adresse IPv6 pour le paramètre proxy sur la page Mise en réseau de la console Web de vCenter Server Appliance, la configuration échoue.

          Solution : Utilisez une adresse IPv4 pour le paramètre proxy de vCenter Server Appliance.

        5. La page de connexion de vSphere Web Client met plusieurs minutes à s'ouvrir après certaines opérations
          Généralement, lorsque vous ouvrez l'URL de vSphere Web Client dans un navigateur, la page de connexion s'ouvre immédiatement. Mais si vous venez de terminer l'installation, ou si vous redémarrez le service vSphere Web Client ou que vous configurez vCenter Server Appliance, la page de connexion ne s'ouvre pas immédiatement. Il est possible qu'une page vide apparaisse pendant quelques minutes, suivie d'une page HTTP 404.

          Solution : Attendez quelques minutes, puis essayez d'actualiser la page. Si vous actualisez la page après 2 à 4 minutes, la page de connexion s'ouvre correctement.

        6. Sur les systèmes Linux, la police n'apparaît pas correctement sur certaines pages de vSphere Web Client
          Les services d'hébergement Web des shell Linux et UNIX (*nix/*nux) n'appliquent pas correctement les apparences Adobe Flex Spark sur certaines pages de vSphere Web Client. Par exemple, les polices en gras dans les titres n'apparaissent pas en gras.

          Solution : Installez les polices True Type Core de Microsoft, msttcorefonts, pour votre système d'exploitation. Par exemple, sur les système Ubuntu, tapez sudo apt-get install msttcorefontsdans l'invite de commande.

        7. Impossible de se connecter à vSphere Web Client avec les informations d'identification de session Windows
          vSphere Web Client ne prend pas en charge la connexion avec les informations d'identification de session Windows lorsque vous êtes connecté à Windows comme utilisateur du système d'exploitation local. Lorsque vous vous connectez à vSphere Web Client avec les informations d'identification de session Windows, vous devez être un utilisateur Active Directory d'un domaine qui existe en tant que source d'identité dans vCenter Single Sign On.

          Remarque : La connexion avec les informations d'identification de session Windows n'est pas prise en charge pour les systèmes vCenter Server 5.0.

          Solution : Pour utiliser les informations d'identification de session Windows pour vous connecter à vSphere Web Client depuis un navigateur sur un système Windows, vous devez vous connecter en tant qu'utilisateur Active Directory d'un domaine qui existe comme source d'identité dans vCenter Single Sign On.

        8. Lorsque vous cliquez sur l'explorateur de journal dans vSphere Web Client, une erreur indiquant un accès non autorisé apparaît
          Lorsque vous cliquez sur le lien de l'explorateur de journal dans vSphere Web Client, un message d'erreur apparaît : Exception : https://<system-address>:12443/vmwb/logbrowser: Accès non autorisé.Cette erreur se produit après avoir remplacé le certificat SSL par défaut du serveur vCenter Single Sign On, soit directement, soit en régénérant le certificat dans vCenter Server Appliance.

          Solution :

          1. Connectez-vous à vSphere Web Client en tant qu'administrateur Single Sign On.
          2. Accédez à Administration > Connexion et découverte > Configuration, puis cliquez sur l'onglet Certificat STS.
          3. Cliquez sur Edit.
          4. Sélectionnez le magasin de clés SSL de Single Sign On.
            • Si Single Sign On est exécuté sur un système Windows, sélectionnez le fichier suivant :
              C:\Program Files\VMware\Infrastructure\SSOServer\security\server-identity.jks(chemin d'accès par défaut)
            • Si Single Sign On est exécuté sur Linux (vCenter Server Appliance), sélectionnez le fichier suivant :
              /usr/lib/vmware-sso/security/server.jks(chemin d'accès par défaut)
          5. Ouvrez le fichier .xml du serveur de Single Sign On avec un éditeur de texte ou un navigateur.
            • Sur Windows :
              C:\Program Files\VMware\Infrastructure\SSOServer\conf\server.xml(chemin d'accès par défaut)
            • Sur Linux :
              /usr/lib/vmware-sso/conf/server.xml(chemin d'accès par défaut)
          6. Recherchez keystorePass="..."sur l'élément de connexion. La chaîne entre guillemets est votre mot de passe.
          7. Entrez le mot de passe dans vSphere Web Client lorsque vous y êtes invité.
          8. Sélectionnez uniquement la chaîne affichée.
          9. Cliquez sur OK et ressaisissez le mot de passe.
          10. Redémarrez les services suivants : vSphere Web Client, vCenter Server, vCenter Inventory Service et VMware Log Browser. Vous n'avez pas besoin de redémarrer Single Sign On.

        9. L'authentification échoue lorsque des utilisateurs du système vCenter Single Sign On (domaine système) essayent de se connecter à vSphere Web Client
          La stratégie de mot de passe par défaut des utilisateurs du système vCenter Single Sign On spécifie que les mots de passe expirent au terme de 365 jours. Toutefois, vCenter Single Sign On n'adresse pas d'avertissement lorsque le mot de passe d'un utilisateur approche de son expiration.

          Solution : Les utilisateurs administrateurs de vCenter Single Sign On peuvent modifier les mots de passe des utilisateurs du domaine système. Demandez à un administrateur de réinitialiser votre mot de passe. Si vous êtes un utilisateur administrateur de Single Sign On, utilisez l'outil de ligne de commande ssopasspour réinitialiser le mot de passe.

          Sur Windows :

          1. Ouvrez une fenêtre de terminal et accédez à C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli
          2. Exécutez la commande suivante.
            ssopass <username>
          3. Saisissez le mot de passe actuel de l'utilisateur, même s'il a expiré.
          4. Saisissez le nouveau mot de passe, puis saisissez-le à nouveau pour confirmation.

          Sur Linux (vCenter Server Appliance) :

          1. Ouvrez une fenêtre de terminal et accédez à /usr/lib/vmware-sso/bin.
          2. Exécutez la commande suivante.
            ./ssopass <username>
          3. Saisissez le mot de passe actuel de l'utilisateur, même s'il a expiré.
          4. Saisissez le nouveau mot de passe, puis saisissez-le à nouveau pour confirmation.

        10. Impossible d'utiliser l'authentification de session Windows dans vSphere Web Client si vCenter Single Sign On est configuré pour une disponibilité élevée
          L'utilisation de l'authentification de session Windows requière plusieurs appels consécutifs au Single Sign On et tous ces appels doivent aller au même serveur. Le client Security Token Service (STS) n'acceptant pas les cookies envoyés depuis le STS, il n'y a aucune garantie que les appels aillent au même serveur dans une configuration de disponibilité élevée.

          Solution : Aucun

        11. vCenter Server est anormalement long à démarrer et vSphere Client risque d'expirer
          Lorsqu'un grand nombre de permissions sont affectées à des objets dans l'inventaire du vCenter Server, le service vCenter Server ne démarre pas aussi vite qu'il devrait puisque vCenter Server vérifie que les utilisateurs et groupes existent bien dans la source d'identité. De même, la connexion à vSphere Client pourrait expirer si vous vous connectez avec les informations d'identification de session Windows. Les messages suivants apparaissent dans les journaux système de vCenter Server pendant que le service est en cours de démarrage :
          [SSO] [SsoAdminFacadeImpl] [FindGroup]
          [UserDirectorySso] GetUserInfo (DOMAIN\ *USER OR GROUP*, true) res: DOMAIN\ *USER OR GROUP*
          [UserDirectorySso] NormalizeUserName (DOMAIN\ *USER OR GROUP*, false) re: DOMAIN\ *USER OR GROUP*

          Solution : Minimisez le nombre de permissions que vous affectez aux objets, ou bien utilisez l'héritage d'un objet de niveau supérieur pour réduire le nombre d'affectations de permissions individuelles.

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

        • 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

        • La personnalisation d'une machine virtuelle Windows échoue lors du processus de clonage ou de déploiement
          Dans vCenter Server, la personnalisation d'invité d'une machine virtuelle Windows 2008, Windows 2008 R2 ou Windows 7 échoue avec une erreur : Une erreur interne s'est produite lors de l'installation Windows lors du chargement ou de la recherche d'un fichier de réponses sans surveillance.Ce problème se produit car la spécification de personnalisation contient des caractères &, >, <, ", ou ' dans l'un des champs suivants : Nom de l'ordinateur, Nom du propriétaire enregistré ou Nom de l'organisation enregistrée.

          Solution : N'utilisez pas de caractères spéciaux dans ces champs.

        • vSphere Client et vSphere Web Client permettent de créer un disque virtuel de 2 To-1 Mo, alors que la taille maximale prise en charge est de 2 To-512 octets
          Si vous créez un disque virtuel avec vSphere Client et vSphere Web Client, vous pouvez créer un disque virtuel d'une taille maximale de 2 To-1 Mo. Cependant, la taille maximale prise en charge pour un disque virtuel est de 2 To-512 octets.

          Solution : Utilisez la commande vmkfstoolspour créer un disque virtuel de 2 To-512 octets :
          vmkfstools -c --createvirtualdisk disk_size

        • 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'intéragir 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 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.

        • Dans un cluster vSphere HA qui utilise Fault Tolerance, les machines virtuelles peuvent ne plus être protégées si une erreur APD (Tous chemins hors service) se produit sur tous les nœuds.
          Dans un cluster vSphere HA, s'il y a un APD sur le nœud principal et le nœud secondaire de la banque de données qui héberge une machine virtuelle, il est possible que la machine virtuelle ne soit plus protégée. Ce problème est lié à un échec du démarrage de la VM secondaire en tant que nouvelle VM principale qui provient d'un problème de minutage avec le rapport APD qui peut rendre la machine virtuelle inconnue. Ce problème ne semble pas se produire dans les clusters avec un nombre inférieur de machines virtuelles tolérantes aux pannes.

          Solution :

          1. Dans vCenter Server, annulez l'enregistrement de la machine virtuelle puis réenregistrez-la avec le même nom. La machine virtuelle revient sur l'ancien nœud principal.
          2. Reconfigurez le paramétrage du cluster vSphere HA et de Fault Tolerance à sa configuration précédente.

        Problèmes de matériel pris en charge
        • 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 avec 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 test 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.

        • L'explorateur de journal de vSphere Web Client n'affiche pas certains types de journaux
          Sur les installations Windows de vCenter Server et de vSphere Web Client, l'explorateur de journal n'affiche pas les types de journaux suivants :

          • Installer
          • Serveur de recherche
          • SSO-service-cfg

          Ce problème n'existe pas dans vLogBrowser dans VMware Workbench.

          Solution : Générez et téléchargez un bundle de journaux. Utilisez un éditeur de texte pour afficher les fichiers journaux.