Notes de mise à jour de vCenter Server 6.5.0d

|

vCenter Server 6.5.0d | 18 avril 2017 | ISO Build 5318154

vCenter Server Appliance 6.5.0d | 18 avril 2017 | ISO Build 5318154

vCenter Server 6.5.0d sous Windows | 18 avril 2017 | ISO Build 5318154

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

La version 6.5.0d de vCenter Server inclut de nouvelles fonctionnalités et des correctifs de bogues liés à vSAN 6.6. Pour plus d'informations, consultez les Notes de mise à jour de vSAN 6.6 et la documentation de vSAN 6.6.

Versions antérieures à vCenter Server 6.5

Les fonctionnalités et problèmes connus de vCenter Server sont décrits dans les notes de mise à jour de chaque version. Notes de mise à jour des versions antérieures de vCenter Server 6.5 :

Notes de mise à jour de VMware vCenter Server 6.5.0c
Notes de mise à jour de VMware vCenter Server 6.5.0b
Notes de mise à jour de VMware vCenter Server 6.5.0a
Notes de mise à jour de VMware vSphere 6.5

Pour plus d'informations sur la compatibilité, l'installation et les mises à niveau, ainsi que les remarques concernant l'assistance produit et les fonctionnalités, reportez-vous aux versions précédentes des notes de mise à jour de vCenter Server.

Notes de mise à jour de VMware vSphere 6.5

Correctifs contenus dans cette version

Cette version de vCenter Server 6.5.0d fournit les correctifs suivants. Reportez-vous au Centre de téléchargement des correctifs de VMware pour plus d'informations sur le téléchargement de correctifs.

Internationalisation

VMware vSphere 6.5 est disponible dans les langues suivantes :

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

Les composants de VMware vSphere 6.5, notamment vCenter Server, ESXi, vSphere Web Client et vSphere Client n'acceptent pas l'entrée de caractères non ASCII.

Problèmes connus dans cette version de correctif

  • Lorsque vous clonez une machine virtuelle vers une banque de données vSAN dans une autre instance de vCenter Server, la barre de progression du chargement de la page Sélectionner un stockage de l'assistant Cloner vers une machine virtuelle n'arrête pas le chargement
    Lorsque vous clonez une machine virtuelle vers une banque de données vSAN, une vérification de coûts de provisionnement est déclenchée. Si votre environnement comporte un Platform Services Controller externe et que vous tentez de cloner la machine virtuelle vers une banque de données VMware vSAN dans une instance différente de vCenter Server, le contrôle entraîne une erreur et la barre de progression de la page Sélectionner un stockage ne peut pas arrêter le chargement.

    Solution :

    1. Clonez la machine virtuelle vers une banque de données non-vSAN dans l'instance de destination de vCenter Server.
    2. Migrez la machine virtuelle ou déployez-la à partir d'un modèle localement au sein de l'instance de destination de vCenter Server.

  • Après une mise à jour vers la version 6.5.0d de vCenter Server sous Windows, vous pouvez voir l'ancien nom de vSAN dans vSphere Web Client
    Après une mise à jour vers la version 6.5.0d à partir de la version 6.5 de vCenter Server sous Windows, si vous disposez d'une clé de licence standard vSAN dans les informations de licence de vSphere Web Client, le nom Virtual SAN Standard s'affiche. Virtual SAN Standard est l'ancien nom de produit de VMware vSAN Standard.

    Solution : redémarrez le service de licence VMware. Pour redémarrer le service de licence VMware, consultez la base de connaissances https://kb.vmware.com/kb/2109887.

Problèmes détectés dans les versions antérieures

Pour obtenir la liste des problèmes détectés dans les versions antérieures, cliquez ici.

Problèmes de mise à niveau
  • Les vérifications préalables à la mise à niveau indiquent que l'interface eth0 est manquante lors de la mise à niveau vers vCenter Server Appliance 6.5
    Les vérifications préalables à la mise à niveau indiquent que l'interface eth0 est manquante et qu'elle est nécessaire pour terminer la mise à niveau de vCenter Server Appliance. En outre, un avertissement peut s'afficher indiquant que si plusieurs adaptateurs réseau sont détectés, seule l'interface eth0 est conservée.

    Solution : reportez-vous à l'article de la base de connaissances suivant http://kb.vmware.com/kb/2147933 pour trouver une solution.

  • La mise à niveau de vCenter Server échoue lorsque le commutateur virtuel distribué et les groupes de ports virtuels distribués ont le même nom supérieur/non ASCII dans un environnement Windows
    Dans un environnement Windows, si les commutateurs virtuels distribués et les groupes de ports virtuels distribués utilisent des caractères dupliqués supérieurs/non ASCII comme noms, la mise à niveau de vCenter Server échoue avec l'erreur :
    Impossible de lancer UpgradeRunner. Vérifiez les fichiers vminst.log et vcsUpgrade\UpgradeRunner.log dans le dossier temp pour obtenir plus de détails.

    Solution : renommez les commutateurs virtuels distribués ou les groupes de ports virtuels distribués en utilisant des noms non uniques.

  • Les tentatives de mise à niveau d'un dispositif vCenter Server Appliance ou Platform Services Controller peuvent échouer avec un message d'erreur concernant les paramètres de configuration DNS si le dispositif source est défini avec une configuration IPv4 et IPv6 statique.
    La mise à niveau d'un dispositif configuré avec des adresses IPv4 et IPv6 statiques peut échouer avec le message d'erreur suivant : Erreur lors de la définition de la configuration du DNS. Détails : L'opération a échoué. Code : com.vmware.applmgmt.err_operation_failed.

    Le fichier journal /var/log/vmware/applmgmt/vami.log du dispositif récemment déployé contient les entrées suivantes :
    INFO:vmware.appliance.networking.utils:Running command: ['/usr/bin/netmgr', 'dns_servers', '--set', '--mode', 'static', '--servers', 'IPv6_address,IPv4_address']
    INFO:vmware.appliance.networking.utils:output:
    error:
    returncode: 17
    ERROR:vmware.appliance.networking.impl:['/usr/bin/netmgr', 'dns_servers', '--set', '--mode', 'static', '--servers', 'IPv6_address,IPv4_address'] error , rc=17

    Solution :

    1. Supprimez le dispositif récemment déployé et restaurez le dispositif source.

    2. Sur le dispositif source, désactivez la configuration IPv6 ou IPv4.

    3. À partir du serveur DNS, supprimez l'entrée de l'adresse IPv6 ou IPv4 que vous avez désactivée.

    4. Recommencez la mise à niveau.

    5. (Facultatif) Une fois la mise à niveau terminée, ajoutez à nouveau l'entrée DNS, puis, sur le dispositif mis à niveau, définissez l'adresse IPv6 ou IPv4 que vous avez désactivée.

  • Les tentatives de mise à niveau d'un dispositif vCenter Server Appliance ou Platform Services Controller à l'aide d'un mot de passe racine ayant expiré échouent avec un message générique signalant une erreur interne
    Lors de la mise à niveau du dispositif, le programme d'installation se connecte au dispositif source pour détecter son type de déploiement. Si le mot de passe racine du dispositif source a expiré, le programme d'installation ne parvient pas à se connecter au dispositif source et la mise à niveau échoue avec le message d'erreur suivant : Une erreur interne s'est produite pendant les vérifications de pré-mise à niveau.

    Solution :

    1. Connectez-vous à l'interface utilisateur de la console directe (DCUI) du dispositif.

    2. Définissez un nouveau mot de passe racine.

    3. Recommencez la mise à niveau.

  • La mise à niveau d'un dispositif vCenter Server Appliance peut échouer, car un chemin de bibliothèque partagé de dépendance est manquant
    La mise à niveau d'un dispositif vCenter Server Appliance peut échouer avant la phase d'exportation, et le journal d'erreurs affiche le message suivant : /opt/vmware/share/vami/vami_get_network : erreur lors du chargement des bibliothèques partagées : libvami-common.so : impossible d'ouvrir le fichier objet partagé : Aucun fichier ou répertoire de ce type. Ce problème survient, car le chemin de bibliothèque partagé de dépendance est manquant.

    Solution :

    1. Connectez-vous à l'interpréteur de commandes Bash du dispositif vCenter Server Appliance à mettre à niveau.

    2. Exécutez les commandes suivantes :
      echo "LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/opt/vmware/lib/vami/" >> /etc/profile
      echo 'export LD_LIBRARY_PATH' >> /etc/profile

    3. Déconnectez-vous de l'interpréteur de commandes du dispositif.

    4. Recommencez la mise à niveau.

  • La mise à niveau de vCenter Server 6.0 avec une base de données externe échoue si vCenter Server 6.0 comporte des bibliothèques de contenu dans l'inventaire
    La vérification préalable à la mise à niveau échoue si vous tentez de mettre à niveau une instance de vCenter Server 6.0 avec des bibliothèques de contenu dans l'inventaire et une base de données Microsoft SQL Server ou Oracle. Vous recevez un message d'erreur semblable au suivant : Une erreur interne s'est produite pendant les vérifications de pré-mise à niveau du service de bibliothèque de contenu VMware.

    Solution : aucune.

  • L'extraction de l'image ISO de vCenter Server Appliance à l'aide d'un outil d'extraction tiers génère une erreur d'autorisation
    Lors de l'extraction de l'image ISO dans Mac OS X pour exécuter le programme d'installation à l'aide d'un outil tiers disponible sur Internet, l'erreur suivante risque de se produire pendant l'exécution du programme d'installation de l'interface de ligne de commande : OSError: [Errno 13] Autorisation refusée.

    Ce problème se produit car lors de l'extraction, certains outils d'extraction modifient l'autorisation par défaut définie dans le fichier ISO de vCenter Server Appliance.

    Solution : effectuez la procédure suivante avant d'exécuter le programme d'installation :

    1. Pour ouvrir le fichier ISO de vCenter Server Appliance, exécutez la commande Mac OS X automount.

    2. Copiez tous les fichiers dans un nouveau répertoire.

    3. Exécutez le programme d'installation depuis le nouveau répertoire.

  • La mise à niveau de vCenter Server peut échouer lors du premier démarrage du démon VMware Authentication Framework (VMAFD)
    Le premier démarrage du démon VMware Authentication Framework (VMAFD) peut échouer avec le message d'erreur suivant : Échec de Vdcpromo. Erreur 382312694 : Accès refusé, raison = rpc_s_auth_method (0x16c9a0f6).

    Lors d'une mise à niveau de vCenter Server, le premier démarrage du VMAFD peut échouer si le système que vous mettez à niveau est installé à l'aide du logiciel tiers qui installe sa propre version des bibliothèques OpenSSL et modifie la variable d'environnement PATH du système.

    Solution : Supprimez les répertoires tiers contenant les bibliothèques OpenSSL de %PATH% ou déplacez-les à la fin de %PATH%.

  • VMware vSphere vApp (vApp) et un pool de ressources ne sont pas disponibles comme options cibles de la mise à niveau d'un dispositif vCenter Server Appliance ou Platform Services Controller
    Lors de la mise à niveau d'un dispositif à l'aide de l'interface utilisateur graphique ou l'interface de ligne de commande du programme d'installation de vCenter Server Appliance, vous pouvez sélectionner vApp ou un pool de ressources comme cible de la mise à niveau.

    Les interfaces du programme d'installation de vCenter Server Appliance ne permettent pas de sélectionner vApp ou un pool de ressources comme cible de la mise à niveau.

    Solution : effectuez la mise à niveau sur l'hôte ESXi sélectionné ou sur l'instance de vCenter Server. Lorsque la mise à niveau est terminée, déplacez manuellement la machine virtuelle qui vient d'être déployée de la manière suivante :

    • Si vous avez mis à niveau le dispositif sur un hôte ESXi qui fait partie d'un inventaire vCenter Server ou sur une instance de vCenter Server, connectez-vous à l'instance de vSphere Web Client ou vCenter Server et déplacez la machine virtuelle qui vient d'être déployée dans l'instance de vApp ou le pool de ressources requis.

    • Si vous avez mis à niveau le dispositif sur un hôte ESXi autonome, ajoutez l'hôte à un inventaire vCenter Server puis connectez-vous à l'instance de vSphere Web Client ou vCenter Server et déplacez la machine virtuelle qui vient d'être déployée dans l'instance de vApp ou le pool de ressources requis.

  • La mise à niveau de vCenter Server 6.5 peut échouer lors de la phase du premier amorçage de vmon-api en raison d'une adresse IPv6 non valide dans le champ SAN du certificat SSL
    Le certificat SSL de vCenter Server prend une adresse IPv6 dans le champ SAN lorsque vous installez vCenter Server et activez IPv4 et IPv6. Si vous désactivez IPv6 après l'installation et tentez ensuite de mettre à niveau vCenter Server vers la version 6.5, la mise à niveau échoue à la phase du premier démarrage vmon-api.

    Solution : vérifiez que le champ SAN du certificat SSL de vCenter Server source contient l'adresse IP valide de l'instance de vCenter Server source.

  • La mise à niveau de vCenter Server 6.5 échoue car des noms d'entités sont dupliqués dans le dossier réseau
    vSphere 6.5 permet uniquement des noms uniques dans toutes les instances de Distributed Virtual Switch et Distributed Virtual Portgroup dans le dossier réseau. Dans les versions antérieures de vSphere, une instance de Distributed Virtual Switch et une instance de Distributed Virtual Portgroup pouvaient avoir le même nom. Si vous tentez de mettre à niveau à partir d'une version qui autorise les noms dupliqués, la mise à jour échoue.

    Solution : renommez les instances de Distributed Virtual Switch ou Distributed Virtual Portgroup qui ont le même nom avant de commencer la mise à niveau.

  • Le collecteur Syslog peut cesser de fonctionner après la mise à niveau d'ESXi
    Les collecteurs Syslog qui utilisent SSL pour communiquer avec le démon syslog d'ESXi peuvent cesser de recevoir les messages de journalisation de l'hôte ESXi après une mise à niveau.

    Solution : reconfigurez le démon syslog d'ESXi en exécutant les commandes suivantes sur l'hôte ESXi mis à niveau :
    esxcli system syslog config set --check-ssl-certs=true
    esxcli system syslog reload

  • La commande Ctrl+C ne permet pas de quitter la page Contrat de Licence Utilisateur Final (CLUF) pendant le transfert ou l'installation de correctifs sur vCenter Server Appliance
    Si vous transférez ou installez les packages de mise à jour de vCenter Server Appliance à l'aide de la commande correspondante sans ajouter le paramètre optionnel --acceptEulas, les pages CLUF s'affichent dans l'invite de commande. Il doit être possible de quitter la page sans accepter le contrat à l'aide de la commande Ctrl+C et que l'exécution de cette commande vous permette de rester sur les pages CLUF.

    Solution : quittez le CLUF en saisissant NON à la fin de la dernière page.

  • Lorsque la validation se termine avec un échec sur les correctifs transférés dans un dispositif vCenter Server Appliance, les packages de mise à jour transférés sont supprimés
    Pour mettre à jour votre dispositif vCenter Server Appliance, vous devez commencer par transférer les correctifs de mise à jour disponibles avant de les installer sur le dispositif. Si la validation de ces packages transférés échoue, leur transfert est annulé et ils sont supprimés. Une tentative de validation des packages après un échec initial génère une erreur.

    Solution : répétez l'opération de transfert.

Problèmes liés aux fonctionnalités de sécurité
  • Problèmes liés à l'exécution de TLS ReConfigurator si l'authentification par carte à puce est activée
    vSphere 6.5 inclut TLS Reconfigurator, un outil qui permet de gérer la configuration TLS. Les utilisateurs doivent installer cet outil. Les fonctionnalités de cet outil sont documentées dans l'article 2147469 de la base de connaissances VMware.
    Si vous exécutez l'outil dans un environnement vSphere 6.5 sur lequel l'authentification par carte à puce est activée sur Platform Services Controller, les services ne parviennent pas à démarrer et une exception se produit. Cette erreur se produit lors de l'exécution de l'outil pour modifier les configurations TLS sur Platform Services Controller, pour les services du gestionnaire de contenu (PSC pour Windows) ou du service vmware-stsd (dispositif Platform Services Controller).

    Solution :

    1. Ouvrez le fichier server.xml pour le modifier.

    2. Windows : C:\ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\con

      Linux : /usr/lib/vmware-sso/vmware-sts/conf

    3. Supprimez la première des deux entrées correspondant à la balise Server.

    4. Redémarrez tous les services.

    Dans l'exemple suivant, la première entrée Server est supprimée, mais pas la deuxième.

    <!--Remove the first Server entry-->
    <Server port="${base.shutdown.port}" shutdown="SHUTDOWN">
    <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
    <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
    ...
    </Server>
    <!--Keep the second Server entry-->
    <Server port="${base.shutdown.port}" shutdown="SHUTDOWN">
    <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
    <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
    ...
    </Server>

  • Erreur lors de l'ajout d'un hôte ESXi dans les environnements comprenant plusieurs vCenter Server et Platform Services Controller derrière un équilibrage de charge
    Vous avez configuré un environnement comprenant plusieurs instances de vCenter Server et Platform Services Controller derrière un équilibrage de charge. L'environnement utilise VMCA comme autorité de certification intermédiaire. Lorsque vous tentez d'ajouter un hôte ESXi, l'erreur suivante peut être renvoyée :
    Unable to get signed certificate for host name : Error: Failed to connect to the remote host, reason = rpc_s_too_many_rem_connects Lorsque vous tentez de récupérer l'autorité de certification racine sur Platform Services Controller, la commande échoue, comme suit :
    /usr/lib/vmware-vmca/bin/certool --getrootca --server=wx-sxxx-sxxx.x.x.x Status : Failed Error Code : 382312518 Error Message : Failed to connect to the remote host, reason = rpc_s_too_many_rem_connects (0x16c9a046)

    Solution : redémarrez le service VMCA sur Platform Services Controller.

  • Les services vCenter Server ne démarrent pas après un redémarrage ou un basculement en cas d'indisponibilité du nœud Platform Services Controller
    Si un nœud Platform Services Controller n'est pas disponible temporairement et que vCenter Server est redémarré ou si un basculement vCenter HA se produit au cours de cette période, les services vCenter ne parviennent pas à se lancer.

    Solution : restaurez le nœud Platform Services Controller et redémarrez vCenter Server, ou démarrez tous les services à partir de la ligne de commande à l'aide de la commande suivante :
    service-control --start --all

  • Démarrage du processus STS impossible sur vCenter Server Appliance
    Après que vous avez installé vCenter Server Appliance, ou effectué une mise à niveau ou une migration vers vCenter Server Appliance 6.5, le processus Secure Token Service ne parvient pas à démarrer dans certains cas. Ce problème ne survient que rarement, mais il a déjà été observé.

    Solution : aucune. Ce problème a été observé lorsque le DNS ne peut pas résoudre localhost comme adresse loopback dans un environnement IPv6. Pour corriger le problème, vérifiez la configuration de votre réseau.

  • Erreur 400 lors d'une tentative de connexion à vCenter Server à partir de vSphere Web Client
    Vous vous connectez à vCenter Server à partir de vSphere Web Client, puis vous vous déconnectez. Si après un minimum de 8 heures, vous tentez de vous connecter à partir du même onglet du navigateur, l'erreur suivante est renvoyée :
    400 An Error occurred from SSO. urn:oasis:names:tc:SAML:2.0:status:Requester, sub status:null

    Solution : fermez le navigateur ou l'onglet, puis reconnectez-vous.

  • Une VM chiffrée devient verrouillée (non valide) lorsque vCenter Server est restauré à un état de sauvegarde précédent
    Dans la plupart des cas, une machine virtuelle chiffrée est ajoutée à vCenter Server à l'aide de vSphere Web Client ou de vSphere API.
    Cependant, la machine virtuelle peut être ajoutée d'autres manières, par exemple, lorsqu'elle est ajoutée par une opération de sauvegarde à l'aide de solutions de sauvegarde et de restauration basées sur des fichiers.
    Dans ce cas, vCenter Server n'envoie pas les clés de chiffrement à l'hôte ESXi. La machine virtuelle est donc verrouillée (non valide).
    Il s'agit d'une fonctionnalité de sécurité qui empêche une machine virtuelle chiffrée non autorisée d'accéder à vCenter Server.

    Solution : vous avez plusieurs options.

    • Désenregistrez la machine virtuelle et réenregistrez-la à l'aide de vSphere API. Vous pouvez effectuer cette opération dans vSphere Web Client ou vSphere API.

    • Supprimez l'hôte ESXi qui contient la machine virtuelle de vCenter Server et rajoutez-le.

  • Erreur lors de la communication avec l'hôte distant pendant la procédure de chiffrement de la machine virtuelle
    Vous effectuez une opération de chiffrement de machine virtuelle comme le chiffrement d'une machine virtuelle ou la création d'une machine virtuelle chiffrée. Votre cluster inclut un hôte ESXi déconnecté. L'erreur suivante est générée :
    « Une erreur s'est produite lors de la communication avec l'hôte distant ».

    Solution : supprimez l'hôte déconnecté de l'inventaire du cluster.

  • Le basculement automatique n'est pas effectué si les services Platform Services Controller ne sont plus disponibles
    Si vous exécutez Platform Services Controller derrière un équilibrage de charge, un basculement se produit si le nœud Platform Services Controller n'est plus disponible. Si les services de Platform Services Controller exécutés derrière le port 443 du proxy inverse échouent, le basculement automatique n'est pas effectué. Ces services incluent par exemple Security Token Service, License service, etc.

    Solution : mettez hors ligne les services Platform Services Controller avec le service ayant échoué pour déclencher le basculement.

  • Le système vCenter Server ne parvient pas à se connecter à un KMS en utilisant l'adresse IPv6
    vCenter Server peut se connecter à un KMS (Key Management Server) uniquement si ce dernier comporte une adresse IPv4 ou un nom d'hôte qui définit une adresse IPv4. Si le KMS comporte une adresse IPv6, l'erreur suivante se produit lorsque vous ajoutez le KMS au système vCenter Server.
    « Impossible d'établir une connexion de confiance ».

    Solution : configurez une adresse IPv4 pour le KMS.

  • Le démarrage sécurisé échoue après la mise à niveau à partir d'anciennes versions de ESXi
    Vous ne pouvez pas démarrer un hôte ESXi 6.5 sur lequel le démarrage sécurisé est activé dans les situations suivantes.

    • La mise à niveau de l'hôte a été effectuée à l'aide de la commande ESXCLI. La commande ne met pas à niveau le chargeur de démarrage et ne conserve pas les signatures. Lorsque vous activez le démarrage sécurisé après la mise à niveau, une erreur se produit.

    • La mise à niveau de l'hôte a été effectuée à l'aide de l'image ISO, mais les anciens VIB sont conservés après la mise à niveau. Dans ce cas, le processus de démarrage sécurisé ne peut pas vérifier les signatures de l'ancien VIB et échoue. L'image ISO doit contenir les nouvelles versions de tous les VIB installés sur l'hôte ESXi avant la mise à niveau.

    Solution : aucune. Le démarrage sécurisé ne peut pas être activé dans ces conditions. Réinstallez l'hôte ESXi pour activer le démarrage sécurisé.

  • Après une mise à niveau, SSLv3 est activé sur le port 7444 s'il était activé avant la mise à niveau
    Dans une installation propre, SSLv3 n'est pas activé sur les systèmes vCenter Server ou Platform Services Controller. Cependant, après une mise à niveau, le service est activé par défaut sur le port 7444 (le port du serveur de jetons sécurisés). Si SSLv3 est activé, le système est vulnérable face à certaines attaques.

    Solution : pour un déploiement intégré, désactivez SSLv3 dans le fichier server.xml du serveur de jetons sécurisés.

    1. Pour un déploiement avec une instance externe de Platform Services Controller, déterminez si des systèmes vCenter Server hérités sont connectés et mettez-les à niveau.

    2. Désactivez SSLv3.
      1. Ouvrez le fichier server.xml (C:\ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\conf (sur un système Windows) et /usr/lib/vmware-sso/vmware-sts/conf/ (sur un système Linux).

      2. Recherchez le connecteur pour lequel SSLEnabled=True et supprimez SSLv3 de l'attribut SSLEnabledProtocols afin que l'attribut soit le suivant :
        sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"

      3. Enregistrez et redémarrez tous les services.

  • Erreur lors du clonage d'une machine virtuelle chiffrée avec un ou plusieurs disques durs non chiffrés
    Lorsque vous clonez une machine virtuelle chiffrée, l'erreur suivante est générée si un ou plusieurs disques durs de la machine virtuelle ne sont pas chiffrés.
    « Cette opération n'est pas prise en charge sur l'objet ».
    Le processus de clonage échoue.

    Solution : dans l'écran de sélection du stockage de l'assistant de clonage d'une machine virtuelle, sélectionnez Avancé. Même si vous ne modifiez pas les paramètres avancés, le processus de clonage réussit.

Problèmes de mise en réseau
  • La connexion échoue lorsqu'une vNIC est connectée à un commutateur vSphere standard ou un vSphere Distributed Switch avec Network I/O Control désactivé
    Si une vNIC est configurée avec une réservation supérieure à 0 et que vous la connectez à un commutateur vSphere standard ou à un vSphere Distributed Switch pour lequel Network I/O Control est désactivé, la connexion échoue avec le message d'erreur suivant : Un paramètre spécifié était incorrect : spec.deviceChange.device.backing.

    Solution : aucune.

  • Le réseau devient indisponible avec les périphériques de relais intégral
    Si un pilote ntg3 natif est utilisé sur un adaptateur relais Gigabit Ethernet Broadcom, la connexion réseau devient indisponible.

    Solution :

    • Exécutez le pilote ntg3 en mode hérité :

      1. Exécutez la commande esxcli system module parameters set -m ntg3 -p intrMode=0.

      2. Redémarrez l'hôte.

    • Utilisez le pilote tg3 vmklinux comme pilote par défaut à la place du pilote ntg3 natif.

  • Une application RDMA d'espace utilisateur d'une machine virtuelle ne parvient pas à envoyer ou recevoir des données
    Si une application RDMA d'espace utilisateur invité utilise des paires en file d'attente de datagramme non fiable et un ID de groupe basé sur IP pour communiquer avec d'autres machines virtuelles, l'application RDMA ne parvient pas à envoyer ou recevoir des entrées d'exécution de données ou de travail. Toutes les demandes de travail mises en file d'attente sur les paires en file d'attente sont supprimées et ne sont pas effectuées.

    Solution : aucune.

  • Des paquets sont perdus avec des serveurs système IBM hébergeant un périphérique de carte réseau USB dans l'interface UHCI (Universal Host Controller Interface)
    Certains serveurs système IBM, tels que IBM BladeCenter HS22, qui héberge un périphérique de carte réseau USB dans l'interface UHCI, rencontrent des problèmes de réseau s'ils exécutent la pilote USB natif vmkusb. Des paquets sont perdus sur le périphérique de carte réseau USB dans l'interface UHCI si vous utilisez le pilote vmkusb pour la carte réseau USB.

    Solution : désactivez le pilote USB natif vmkusb et choisissez le pilote USB hérité vmklinux :

    1. Exécutez la commande esxcli system module set -m=vmkusb -e=FALSE pour désactiver le pilote USB natif vmkusb.

    2. Redémarrez l'hôte. Au redémarrage, le pilote USB hérité se charge.

  • Les applications du noyau invité reçoivent des entrées d'exécution inattendues pour les demandes de travail à enregistrement rapide non signalées
    La communication RDMA entre deux machines virtuelles qui résident sur un hôte avec une liaison montante RDMA active déclenche parfois des entrées d'exécution parasites dans les applications du noyau invité. Des entrées d'exécution sont déclenchées par erreur par des demandes de travail à enregistrement rapide non signalées qui sont émises par le protocole ULP de l'application RDMA au niveau du noyau. Ceci peut entraîner des dépassements de capacité de file d'attente d'exécution dans l'ULP du noyau.

    Solution : Pour éviter le déclenchement d'exécutions tierces, placez les machines virtuelles qui utiliseront des demandes de travail à enregistrement rapide sur des hôtes séparés.

  • Une machine virtuelle équipée d'un dispositif RDMA paravirtuel devient inaccessible pendant un snapshot ou une migration vMotion
    Des machines virtuelles équipées d'un dispositif RDMA paravirtuel (PVRDMA) exécutent des applications RDMA pour communiquer avec des paires en file d'attente d'homologue. Si une application RDMA tente de communiquer avec un numéro de file d'attente d'homologue qui n'existe pas, le périphérique PVRDMA peut attendre indéfiniment une réponse de l'homologue. Par conséquent, la machine virtuelle devient inaccessible pendant un snapshot ou une migration si l'application RDMA est encore simultanément en cours d'exécution .

    Solution : avant de prendre un snapshot ou d'effectuer une migration vMotion avec un périphérique PVRDMA, arrêtez les applications RDMA qui utilisent un numéro d'homologue en file d'attente qui n'existe pas.

  • Le transfert Netdump du noyau ESXi dure plusieurs heures
    Avec des hôtes qui utilisent les cartes réseau Intel X710 ou Intel X710L, le transfert du noyau ESXi vers un serveur Netdump dure environ deux heures. Le transfert est effectué, mais cette opération est beaucoup plus rapide avec d'autres cartes réseau.

    Solution : aucune.

  • Les protocoles ULP de l'application RDMA au niveau du noyau ne fonctionnent pas correctement dans une machine virtuelle invitée avec un périphérique RDMA paravirtuel
    Les protocoles ULP de l'application RDMA au niveau du noyau, tels que NFS ou iSER, tentent de créer plus de ressources que le périphérique RDMA paravirtuel (PVRDMA) ne peut fournir. Les modules du noyau ne parviennent donc pas à se charger. Toutefois, l'exécution du RDMA Connection Manager (RDMACM) se poursuit.

    Solution : aucune.

  • La commande de mise hors ligne/en ligne rétablit une carte réseau au bout de 60 secondes
    Lorsque vous configurez la technologie Virtual Extensible LAN (VXLAN), puis commencez à transférer du trafic VXLAN sur une carte réseau qui utilise le pilote nmlx4_en, il se peut que la commande esxcli network nic up ne parvienne pas à rétablir la carte réseau dans les 60 secondes. La carte réseau est opérationnelle avec un certain retard. L'exécution de la commande est plus lente si vous exécutez les commandes de mise hors ligne/en ligne et d'annulation de lien/de liaison plusieurs fois de suite.

    Solution : aucune.

  • La carte réseau nmlx4_en 40 Gigabit ne prend pas en charge la technologie Wake-On-LAN (WOL)
    La technologie WOL est prise en charge uniquement sur les cartes réseau LOM flexibles HP 10 Gigabit (cartes Mellanox de marque HP). Les cartes 40 Gigabit ne sont pas prise en charge par HP.

    Solution : si vous souhaitez utiliser la technologie WOL sur des cartes nmlx4_en, utilisez des cartes réseau LOM flexibles HP 10 Gigabit.

  • Le montage des partages NFS échoue lorsque des informations d'identification Kerberos sont utilisées pour s'authentifier auprès d'Active Directory
    Si vous joignez un système ESX à Active Directory et que vous le mettez à niveau sur la version actuelle, ESX ne parvient pas à monter correctement les partages NFS en utilisant le fichier keytab Kerberos si l'instance d'Active Directory ne prend plus en charge le chiffrement RC4. Cela se produit parce que le fichier keytab n'est inscriptible que lorsque le système ESX est joint et que la pile Likewise utilisée sur ESX ne prend pas en charge le chiffrement AES pour les versions antérieures.

    Solution : vous devez joindre à nouveau Active Directory pour que le fichier keytab système soit mis à jour.

  • Une vmnic Intel 82579LM ou I217 peut se bloquer de manière irrécupérable
    Un problème se déclenche sur une vmnic Intel 82579LM ou I217 à fort trafic, par exemple, 4 paires de machines virtuelles exécutant netperf et désactivant puis réactivant de manière répétée l'émulation logicielle VMkernel de la fonctionnalité de déchargement du matériel. Suite à plusieurs cycles de désactivation et de réactivation, le matériel se bloque.

    Solution :

    1. évitez de désactiver et de réactiver l'émulation du logiciel VMkernel des fonctionnalités de déchargement du matériel sur un adaptateur Intel 82579LM ou I217.

    2. Si ce blocage se produit, vous devez redémarrer l'hôte.

  • Une carte réseau Intel i219 peut se bloquer et perdre la connectivité réseau
    Les cartes Intel de la gamme i219, affichées « Intel Corporation Ethernet Connection I219-LM » (parfois avec le suffixe « V »), peuvent se bloquer et entraîner la perte de la connectivité réseau du système au niveau du port. Ce problème est déclenché par des opérations perturbatrices lors du routage du trafic par l'intermédiaire de la carte réseau. Par exemple, cette erreur peut se produire si vous mettez hors ligne une liaison à l'aide de la commande esxcli network nic down vmnixX lors de la copie d'un fichier sur le port i219. Ce problème peut également se déclencher avec un trafic important, par exemple, 4 paires de machines virtuelles exécutant netperf et désactivant puis réactivant de manière répétée l'émulation logicielle VMkernel de la fonctionnalité de déchargement du matériel. La carte réseau n'est pas fonctionnelle tant que vous n'avez pas redémarré l'hôte.

    Solution :

    1. Évitez d'utiliser le port de carte réseau i219 dans les tâches stratégiques.

    2. Évitez d'effectuer des opérations perturbatrices sur les ports i219.

    3. Évitez de désactiver et de réactiver l'émulation du logiciel VMkernel des fonctionnalités de déchargement du matériel sur un adaptateur Intel I219.

    4. Si un adaptateur i219 doit absolument être utilisé, configurez l'association de carte réseau de basculement avec un autre port que le port i219LM.

  • Le duplex intégral configuré sur le commutateur physique peut provoquer des erreurs de non correspondance de duplex avec le pilote igb natif Linux ne prenant en charge que le mode de négociation automatique pour les paramètres de vitesse et de duplex des cartes réseau
    Si vous utilisez le pilote igb natif sur un hôte ESXi, il fonctionne toujours en mode de négociation automatique pour les paramètres de vitesse et de duplex. Quelle que soit la configuration choisie sur cette extrémité de connexion, elle ne s'applique pas à l'hôte ESXi. La prise en charge de la négociation automatique provoque une non correspondance de duplex si un commutateur physique est défini manuellement sur un mode duplex intégral.

    Solution : Appliquez l'une des solutions suivantes :

    • Sur le port de commutateur physique, définissez la vitesse et le mode duplex sur auto avant une mise à niveau ou une installation initiale.

    • Sur l'hôte ESXi, utilisez le pilote VMklinux igb à la place du pilote igb natif. Vous pouvez passer au pilote igb en exécutant les commandes suivantes :

      1. esxcli system module set --enabled=false --module=igbn

      2. esxcli system module set --enabled=true --module=igb

  • Le pilote bnx2x déclenche l'affichage d'un écran violet avec un message d'erreur lors du basculement ou du retour arrière de la carte réseau
    Lorsque vous désactivez ou activez des ports VMkernel et modifiez l'ordre du basculement des cartes réseau, le pilote bnx2x déclenche l'affichage d'un écran violet avec un message d'erreur.

    Solution : Utilisez un pilote async.

Problèmes de stockage

Problèmes liés aux volumes VMFS

  • Après plusieurs échecs d'augmentation d'une banque de données VMFS, les informations relatives aux API VIM et aux commandes LVM sont incohérentes sur le système
    Ce problème se produit si vous tentez d'augmenter la banque de données lorsque le périphérique SCSI de sauvegarde passe à l'état APD ou PDL. Par conséquent, vous devez surveiller les informations incohérentes dans les API VIM et les commandes LVM sur l'hôte.

    Solution : effectuez la procédure suivante :

    1. Exécutez la commande vmkfstools --growfs sur l'un des hôtes connectés au volume.

    2. Exécutez l'opération rescan-vmfs sur tous les hôtes connectés au volume.

  • La banque de données VMFS6 ne prend pas en charge la combinaison de périphériques 512n et 512e dans la même banque de données
    Vous pouvez augmenter une banque de données VMFS6 uniquement avec des périphériques du même type. Si la banque de données VMFS6 est sauvegardée via un périphérique 512n, augmentez-la avec les périphériques 512n. Si la banque de données est créée sur un périphérique 512e, développez-la avec des périphériques 512e.

    Solution : aucune.

  • ESXi ne prend pas en charge la réclamation d'espace automatique sur les baies dont la granularité de démappage est supérieure à 1 Mo
    Si la granularité de démappage du périphérique de sauvegarde est supérieure à 1 Mo, les requêtes de démappage de l'hôte ESXi ne sont pas traitées. Vous pouvez voir le message Unmap not supported dans le fichier vmkernel.log.

    Solution : aucune.

  • L'utilisation de la réanalyse du stockage dans des environnements comportant un grand nombre de LUN peut provoquer des problèmes inattendus
    La réanalyse du stockage est une opération intensive E/S. Si vous l'exécutez tout en effectuant d'autres opérations de gestion de banques de données, comme la création ou l'extension d'une banque de données, vous risquez de rencontrer des retards et d'autres incidents. Les problèmes sont plus susceptibles de se produire dans les environnements comportant un nombre élevé de LUN, supérieur au 1024 LUN pris en charge dans la version de vSphere 6.5.

    Solution : généralement, les réanalyses du stockage effectuées régulièrement par les hôtes sont suffisantes. Il n'est pas nécessaire de réanalyser le stockage lorsque vous effectuez des tâches de gestion de banque de données générales. Exécutez les réanalyses du stockage lorsque cela est absolument nécessaire, particulièrement si vos déploiements incluent un ensemble important de LUN.

Problèmes de serveur NFS

  • Le client NFS 4.1 perd la synchronisation avec le serveur NFS lors de la tentative de création de nouvelles sessions
    Ce problème se produit après une période de connectivité interrompue, le serveur NFS ou les E/S NFS n'obtenant pas de réponse. Lorsque ce problème se produit, le fichier vmwarning.log contient une série de messages d'avertissement similaires au suivant :
    NFS41 CREATE_SESSION request failed with NFS4ERR_SEQ_MISORDERED

    Solution : procédez comme suit :

    1. Démontez les banques de données NFS 4.1 concernées. Si aucun fichier n'est ouvert lorsque vous procédez au démontage, cette opération réussit et le module du client NFS 4.1 remet son état interne au propre. Vous pouvez ensuite remonter les banques de données démontées et reprendre les opérations normales.

    2. Si le démontage de la banque de données ne résout pas le problème, désactivez les cartes réseau connectées aux adresses IP des partages NFS. Conservez les cartes réseau désactivées suffisamment longtemps pour que les durées de bail du serveur expirent, puis remontez-les. Les opérations normales devraient reprendre.

    3. Si les instructions précédentes ne règlent pas le problème, redémarrez l'hôte ESXi.

  • Après un redémarrage de l'hôte ESXi, le montage des banques de données NFS 4.1 exportées par le stockage EMC VNX échoue
    En raison d'un problème potentiel avec EMC VNX, les demandes de remontage NFS 4.1 risque d'échouer après un redémarrage de l'hôte ESXi. Par conséquent, toutes les banques de données NFS 4.1 existantes exportées par ce stockage sont démontées.

    Solution : attendez que les 90 secondes de la durée du bail aient expiré et remontez manuellement le volume.

  • Le montage de la même banque de données NFS avec différentes étiquettes peut déclencher des erreurs lorsque vous tentez de monter ultérieurement une autre banque de données
    Ce problème se produit lorsque vous utilisez la commande esxcli pour monter la même banque de données NFS sur des hôtes ESXi différents. Si vous utilisez des libellés différents, A et B par exemple, vCenter Server renomme B en A pour que les libellés de la banque de données soient cohérents sur les hôtes. Si vous tentez par la suite de monter une nouvelle banque de données et que vous utilisez le libellé B, l'hôte ESXi échoue. Ce problème se produit uniquement lorsque vous montez la banque de données NFS à l'aide de la commande esxcli. Cela n'a pas d'incidence sur le montage par le biais de vSphere Web Client.

    Solution : Lors du montage de la même banque de données NFS à l'aide de la commande esxcli, assurez-vous d'utiliser des étiquettes cohérentes dans l'ensemble des hôtes.

  • Une banque de données NFS 4.1 exportée d'un serveur VNX peut devenir inaccessible
    Lorsque le serveur VNX 4.1 se déconnecte de l'hôte ESXi, la banque de données NSF 4.1 peut devenir indisponible. Ce problème se produit si le serveur VNX modifie son numéro principal de manière inattendue. Cependant, la modification du numéro principal du serveur après s'être connecté à celui-ci est inattendue pour le client NFS 4.1.

    Solution : Supprimez toutes les banques de données exportées par le serveur, puis remontez-les.

Problèmes de Virtual Volumes

  • Après la mise à niveau de vSphere 6.0 vers vSphere 6.5, la stratégie de stockage Virtual Volumes peut disparaître de la liste de stratégies de stockage des machines virtuelles
    Après la mise à niveau de votre environnement vers vSphere 6.5, la stratégie de stockage Virtual Volumes que vous avez créée dans vSphere 6.0 peut ne plus apparaître dans la liste des stratégies de stockage des machines virtuelles.

    Solution : déconnectez-vous de vSphere Web Client, puis reconnectez-vous.

  • vSphere Web Client ne parvient pas à afficher les informations sur le profil par défaut d'une banque de données Virtual Volumes
    Généralement, vous pouvez vérifier les informations sur le profil par défaut associé à la banque de données Virtual Volumes. Dans vSphere Web Client, il vous suffit d'accéder à la banque de données et de cliquer sur Configurer > Paramètres > Profils par défaut.
    Cependant, vSphere Web Client ne peut pas indiquer les profils par défaut si leurs identifiants, configurés au niveau du stockage, ne sont pas uniques dans toutes les banques de données indiquées par le même fournisseur de Virtual Volumes.

    Solution : aucune.

Problèmes liés à iSCSI

  • Dans vSphere 6.5, le nom attribué à l'adaptateur iSCSI logiciel est différent de celui des versions antérieures
    Après la mise à niveau vers la version de vSphere 6.5, le nom de l'adaptateur iSCSI logiciel existant, vmhbaXX, est modifié. Cette modification affecte tous les scripts qui utilisent des valeurs codées de manière irréversible pour le nom de l'adaptateur. Étant donné que VMware ne garantit pas que le nom de l'adaptateur reste identique dans toutes les versions, ne codez pas de manière irréversible le nom dans les scripts. Le changement de nom n'affecte pas le comportement de l'adaptateur iSCSI logiciel.

    Solution : aucune.

Problèmes liés aux profils d'hôte de stockage

  • Les tentatives de définition du paramètre action_OnRetryErrors par l'intermédiaire des profils d'hôte échoue
    Ce problème se produit lorsque vous modifiez un profil d'hôte pour ajouter la règle de réclamation SATP qui active le paramètre action_OnRetryErrors pour les périphériques NMP réclamés par VMW_SATP_ALUA. Ce paramètre contrôle la possibilité pour un hôte ESXi de marquer un chemin problématique comme « mort » et de déclencher un basculement du chemin. Lors l'ajout de la règle est effectué par le profil d'hôte, le paramètre est ignoré.

    Solution : vous pouvez utiliser deux méthodes alternatives pour définir le paramètre sur un hôte de référence.

    • Utilisez la commande esxcli pour activer ou désactiver le paramètre action_OnRetryErrors :
      esxcli storage nmp satp generic deviceconfig set -c disable_action_OnRetryErrors -d naa.XXX
      esxcli storage nmp satp generic deviceconfig set -c enable_action_OnRetryErrors -d naa.XXX

    • Effectuez la procédure suivante :

      1. Ajoutez la règle de réclamation VMW_SATP_ALUA à la règle SATP :
        esxcli storage nmp satp rule add --satp=VMW_SATP_ALUA --option=enable_action_OnRetryErrors --psp=VMW_PSP_XXX --type=device --device=naa.XXX

      2. Exécutez les commandes suivantes pour redemander le périphérique :
        esxcli storage core claimrule load
        esxcli storage core claiming reclaim -d naa.XXX

Problèmes de stratégie de stockage des machines virtuelles

  • La migration à chaud d'une machine virtuelle avec vMotion dans les instances de vCenter Server peut modifier l'état de conformité d'une stratégie de stockage des machines virtuelles
    Après l'utilisation de vMotion pour effectuer une migration à chaud d'une machine virtuelle dans les instances de vCenter Server, l'état de conformité de la stratégie de stockage des VM passe à INCONNU.

    Solution : vérifiez la conformité sur la machine virtuelle migrée pour actualiser son état.

    1. Dans vSphere Web Client, accédez à la machine virtuelle.

    2. Dans le menu contextuel, sélectionnez Stratégies de VM > Vérifier la conformité de la stratégie de stockage VM.
      Le système vérifie la conformité.

Problèmes de pilote de stockage

  • Le pilote intégré bnx2x qui prend en charge l'adaptateur QLogic NetXtreme II de réseau/iSCSI/FCoE peut entraîner des problèmes dans votre environnement ESXi
    Des problèmes peuvent se produire lorsque vous désactivez ou activez les ports VMkernel et modifiez l'ordre de basculement des cartes réseau de votre configuration réseau iSCSI.

    Solution : remplacez le pilote bnx2x par un pilote asynchrone. Pour plus d'informations, consultez le site Web de VMware.

  • Des problèmes peuvent survenir au niveau de l'hôte ESXi lorsque vous utilisez des disques de stockage SATA Seagate
    Si vous utilisez l'adaptateur HBA réclamé par le pilote lsi_msgpt3, l'hôte peut rencontrer des problèmes lors de la connexion aux périphériques SATA Seagate. Le fichier vmkernel.log affiche des erreurs similaires aux suivantes :
    SCSI cmd RESERVE failed on path XXX
    et
    reservation state on device XXX is unknown

    Solution : remplacez le disque SATA Seagate par un autre disque.

  • Lorsque vous utilisez le pilote Dell lsi_mr3 version 6.903.85.00-1OEM.600.0.0.2768847, vous pouvez rencontrer des erreurs
    Si vous utilisez le pilote asynchrone Dell lsi_mr3 version 6.903.85.00-1OEM.600.0.0.2768847, les journaux de VMkernel peuvent afficher le message suivant ScsiCore: 1806: Invalid sense buffer.

    Solution : Remplacez le pilote par le pilote intégré vSphere 6.5 ou un pilote asynchrone de Broadcom.

Problèmes de démarrage à partir d'un SAN

  • L'installation d'ESXi 6.5 sur un LUN Fibre Channel ou iSCSI dont l'ID est supérieur à 255 n'est pas prise en charge
    vSphere 6.5 prend en charge les ID de LUN compris entre 0 et 16383. Cependant, en raison des limitations du BIOS de l'adaptateur, vous ne pouvez pas utiliser de LUN dont l'ID est supérieur à 255 pour le démarrage après l'installation du SAN.

    Solution : Pour l'installation d'ESXi, utilisez des LUN dont l'ID est inférieur ou égal à 255.

Problèmes de stockage divers

  • Si vous utilisez SESparse VMDK, le formatage d'une VM avec un système de fichiers Windows ou Linux prend plus de temps
    Si vous formatez une VM avec un système de fichiers Windows ou Linux, le processus peut prendre plus de temps que d'habitude. Cela se produit si le disque virtuel est SESparse.

    Solution : avant d'effectuer le formatage, désactivez l'opération UNMAP sur le système d'exploitation invité. Vous pouvez réactiver l'opération une fois le processus de formatage effectué.

  • Les tentatives d'utilisation du plug-in VMW_SATP_LOCAL pour des périphériques SAS distants peuvent déclencher des problème et des pannes
    Dans les versions antérieures à ESX 6.5, les périphériques SAS sont marqués comme étant distants même s'ils sont réclamés par le plug-in VMW_SATP_LOCAL. Dans ESX 6.5, tous les périphériques réclamés par VMW_SATP_LOCAL sont marqués comme étant locaux même s'ils sont externes. Par conséquent, lorsque vous mettez à niveau une version antérieure vers ESXi 6.5, tous vos périphériques SAS distants existants précédemment marqués comme distants passent à l'état local. Cette modification a une incidence sur les banques de données partagées sur ces périphériques et peut entraîner des problèmes et un comportement imprévisible.
    En outre, des problèmes peuvent se produire si vous utilisez de manière incorrecte les périphériques qui sont maintenant marqués comme étant locaux, mais qui sont en fait partagés et externes, pour certaines fonctionnalités. Par exemple, si vous autorisez la création du système de fichiers VFAT ou utilisez les périphériques pour Virtual SAN.

    Solution : n'utilisez pas le plug-in VMW_SATP_LOCAL pour les périphériques SAS externes distants. Assurez-vous d'utiliser un autre SATP applicable de la liste de ceux qui sont pris en charge ou un SATP unique de fournisseur.

  • La déconnexion de vSphere Web Client lors du téléchargement d'un fichier dans une banque de données annule le téléchargement et laisse un fichier incomplet
    Le téléchargement de fichiers volumineux dans une banque de données prend du temps. Si vous vous déconnectez pendant le téléchargement du fichier, le téléchargement est annulé sans avertissement. Le fichier téléchargé partiellement peut rester sur la banque de données.

    Solution : ne vous déconnectez pas lors du téléchargement de fichiers. Si la banque de données contient le fichier incomplet, supprimez-le manuellement.

Problèmes liés à Storage I/O Control

  • Vous ne pouvez pas modifier la configuration des filtres d'E/S des machines virtuelles lors du clonage
    Les modifications apportées aux stratégies des machines virtuelles lors du clonage ne sont pas prises en charge par Storage I/O Control.

    Solution : effectuez l'opération de clonage sans modifier la stratégie. Vous pouvez modifier la stratégie lorsque l'opération de clonage est terminée.

  • Les paramètres de Storage I/O Control ne sont pas respectés par VMDK
    Les paramètres de Storage I/O Control ne sont pas respectés par VMDK. Les paramètres de VMDK sont respectés au niveau des machines virtuelles.

    Solution : aucune.

Problèmes liés à Storage DRS

  • Storage DRS ne respecte pas les règles d'affinité VMDK de niveau POD si les VMDK sur une machine virtuelle sont associés à une stratégie de stockage
    Si vous définissez une stratégie de stockage sur le VMDK d'une machine virtuelle faisant partie d'un cluster de banques de données pour lequel Storage DRS est activé, Storage DRS ne respecte pas l'indicateur Conserver les VMDK ensemble pour cette machine virtuelle. Il peut recommander des banques de données différentes pour les VMDK venant d'être ajoutés ou existants.

    Solution : aucune. Ce comportement s'observe lorsque vous définissez n'importe quel type de stratégie, tel que VMCrypt ou des stratégies basées sur des balises.

  • Impossible de désactiver Storage DRS lors du déploiement d'une machine virtuelle à partir d'un modèle OVF
    Lorsque vous déployez un modèle OVF et que vous sélectionnez une banque de données à partir d'un cluster Storage DRS pour la position de la machine virtuelle, vous ne pouvez pas désactiver Storage DRS pour cette machine. Storage DRS reste activé et peut déplacer ultérieurement cette VM vers une autre banque de données.

    Solution : pour que la machine virtuelle reste définitivement sur la banque de données sélectionnée, changez manuellement le niveau d'automatisation de cette machine. Ajoutez cette machine à la liste des remplacements de machines virtuelles dans les paramètres du cluster de stockage.

Problèmes de sauvegarde et de restauration
  • Suite à la restauration basée sur des fichiers d'un dispositif vCenter Server Appliance vers une instance de vCenter Server, les opérations effectuées dans vSphere Web Client, telles que la configuration d'un cluster haute disponibilité ou l'activation de l'accès SSH sur le dispositif, peuvent échouer.
    Lors de la restauration d'une instance de vCenter Server, un nouveau dispositif vCenter Server Appliance est déployé et le serveur HTTP du dispositif démarre avec un certificat auto-signé. Le processus de restauration se termine par la récupération des certificats sauvegardés mais sans redémarrer le serveur HTTP du dispositif. Par conséquent, toutes les opérations qui nécessitent d'établir un appel d'API interne au serveur HTTP du dispositif échouent.

    Solution : Après la restauration du dispositif vCenter Server Appliance vers une instance de vCenter Server, vous devez vous connecter au dispositif et redémarrer son serveur HTTP en exécutant la commande service vami-lighttp restart.

  • Les tentatives de restauration d'un dispositif Platform Services Controller à partir d'une sauvegarde basée sur des fichiers échouent si vous avez modifié le nombre de vCPU ou la taille de disque du dispositif
    Dans vSphere 6.5, le dispositif Platform Services Controller est déployé avec 2 vCPU et une taille de disque de 60 Go. Il est impossible d'augmenter le nombre de vCPU et la taille de disque. Si vous tentez d'effectuer une restauration basée sur des fichiers d'un dispositif Platform Services Controller avec plus de 2 CPU ou une taille de disque supérieure à 60 Go, le programme d'installation de vCenter Server Appliance échoue avec l'erreur suivante : Aucune taille possible ne correspond aux conditions requises.

    Solution : ne réduisez pas le nombre de processeurs en dessous de 2 vCPU et la taille de disque en dessous de 60 Go.

  • La restauration d'une instance de vCenter Server Appliance avec un Platform Services Controller externe à partir d'une sauvegarde basée sur une image ne démarre pas tous les services vCenter Server
    Après avoir utilisé vSphere Data Protection pour restaurer vCenter Server Appliance avec un Platform Services Controller externe, vous devez exécuter le script vcenter-restore pour terminer la restauration et démarrer les services vCenter Server. L'exécution de vcenter-restore peut échouer avec le message d'erreur suivant : Operation Failed. Please make sure the SSO username and password are correct and rerun the script. If problem persists, contact VMware support.

    Solution : après l'échec de l'exécution de vcenter-restore, exécutez la commande service-control --start --all pour démarrer tous les services.

    Si l'exécution de la commande service-control --start --all échoue, vérifiez que le nom d'utilisateur et le mot de passe vCenter Single Sign-On entrés sont corrects. Vous pouvez également contacter le support VMware.

Problèmes de configuration de serveur
  • Non correspondance pour l'option de partage dans tout le cluster pendant la vérification de conformité du profil d'hôte
    Pendant la vérification de conformité d'un profil d'hôte, s'il existe une non correspondance due à l'option shared clusterwide, le nom du périphérique s'affiche pour la valeur Hôte ou pour la valeur Profil d'hôte.

    Solution : traitez le message comme étant un problème de conformité de l'option shared clusterwide.

  • Échec de la correction du profil d'hôte si le profil extrait d'un cluster vSAN est associé à un cluster vSAN différent
    Si vous extrayez un profil d'hôte d'un hôte de référence inclus dans un cluster vSAN et que vous l'associez à un autre cluster vSAN, l'opération de correction (d'application) échoue.

    Solution : avant d'appliquer le profil d'hôte, modifiez les paramètres vSAN du profil. L'UUID du cluster et le nom de la banque de données doivent correspondre aux valeurs du cluster auquel le profil est attaché.

  • Le profil d'hôte ne capture pas les paramètres du mode de verrouillage de l'hôte.
    Si vous extrayez un profil d'hôte d'un hôte ESXi sans état lorsque le mode de verrouillage est activé, les paramètres de ce mode ne sont pas capturés. Après l'application du profil d'hôte et le redémarrage de l'hôte, le mode de verrouillage est désactivé sur l'hôte.

    Solution : après avoir appliqué le profil d'hôte et après avoir redémarré l'hôte, activez manuellement le mode de verrouillage pour l'hôte.

  • Erreurs de conformité des profils d'hôtes avec des lecteurs SAS après la mise à niveau vers vSphere 6.5
    Étant donné que tous les lecteurs réclamés par SATP_LOCAL sont marqués comme étant LOCAL, les profils d'hôtes dont les lecteurs SAS ont l'option Le périphérique est partagé dans tout le cluster activée échouent à la vérification de conformité.

    Solution : avant de procéder à la correction, désactivez l'option de configuration Le périphérique est partagé dans tout le cluster pour les profils d'hôtes avec des lecteurs SAS.

  • Échec de la correction par lots des profils d'hôtes pour les hôtes qui disposent de règles d'affinité logicielle DRS
    Une correction par lots est une opération réalisée sur un groupe d'hôtes ou de clusters. Les profils d'hôtes utilisent la fonctionnalité DRS pour placer automatiquement des hôtes en mode de maintenance avant l'opération de correction. Toutefois, seuls les hôtes dans des clusters DRS entièrement automatisés qui ne disposent pas de règles d'affinité logicielle peuvent effectuer cette opération. Les hôtes qui disposent de règles d'affinité logicielle DRS ne peuvent pas être corrigés, car cette règle empêche les hôtes d'entrer en mode de maintenance, ce qui entraîne l'échec de la correction.

    Solution :

    1. Déterminez si le cluster est entièrement automatisé :

      1. Dans vSphere Web Client, accédez au cluster.

      2. Sélectionnez l'onglet Configurer, puis sélectionnez Paramètres.

      3. Développez la liste des services et sélectionnez vSphere DRS.

      4. Si le champ Automatisation DRS est défini sur Entièrement automatisé, la cluster est entièrement automatisé.

    2. Vérifiez si l'hôte comporte une règle d'affinité logicielle :

      1. Dans le cluster, sélectionnez l'onglet Configurer, puis sélectionnez Paramètres.

      2. sélectionnez Règles de VM/hôte.

      3. Examinez les règles dont le type est défini sur Exécuter les VM sur des hôtes ou Ne pas exécuter les VM sur des hôtes.

      4. Si les détails Détails de la règle de VM/hôte valables pour ces règles contiennent le mot « should » (doit), il s'agit d'une règle d'affinité logicielle ou une règle anti-affinité logicielle.

    3. Pour les hôtes comportant une règle d'affinité logicielle DRS, déplacez manuellement l'hôte en mode de maintenance, puis corrigez-le.

 Problèmes liés à vCenter Server Appliance, vCenter Server, vSphere Web Client, vSphere Client et vSphere Host Client
  • Les journaux système vSphere téléchargés ne sont pas valides
    Ce problème peut se produire si la session client expire alors que le téléchargement des journaux système est toujours en cours. Le bundle de journaux téléchargés qui en résulte devient non valide. Un message d'erreur semblable au suivant peut s'afficher dans le fichier vsphere_client_virgo.log situé dans /var/log/vmware/vsphere-client/logs/vsphere_client_virgo.log :

    com.vmware.vsphere.client.logbundle.DownloadLogController
    Error downloading logs. org.apache.catalina.connector.ClientAbortException:
    java.net.SocketException : Broken pipe (Write failed)
    at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:407)

    Solution : aucune.

  • Le correctif JRE échoue lors du démarrage des services vCenter Server sur un système Windows Server 2016
    Vous risquez de ne pas pouvoir démarrer VMware vSphere Client, et des messages d'erreur semblables au suivant s'affichent :

    2016-11-04 15:47:26.991+05:30| vcsInstUtil-4600788| I : StartStopVCSServices : En attente du démarrage des services VC...
    2016-11-04 16:09:57.652 + 05:30 | vcsInstUtil-4600788 | E : StartStopVCSServices : Impossible de démarrer les services VC
    2016-11-04 16:09:57.652+05:30| vcsInstUtil-4600788| I : Fermeture de la fonction : VM_StartVcsServices

    Solution : aucune.

  • Problèmes d'accès au dispositif vSphere Client basé sur HTML
    Lorsque vCenter Server 6.5 est installé sous le système d'exploitation Windows Server 2016 sur une configuration PSC externe avec un chemin et un port personnalisés, la connexion au dispositif vSphere Client basé sur HTML5 échoue avec le message d'erreur 503 Service non disponible.

    Solution : connectez-vous à vCenter Server à l'aide de vSphere Web Client (Flash).

  • Ralentissement de vSphere Web Client dans des environnements de grande taille lors de l'exécution d'une recherche avancée avec des balises
    vSphere Web Client peut être lent dans des environnements à grande échelle lors de l'exécution d'une recherche avancée incluant des balises. Ce problème se produit pendant la recherche et s'arrête à la fin de celle-ci. Il est possible que les services vCenter ne disposent pas de suffisamment de mémoire pendant le ralentissement.

    Solution : Attendez la fin de la recherche ou redémarrez vCenter Server en arrêtant, puis en redémarrant les services vCenter à l'aide de la commande ci-dessous si vous observez des erreurs OutOfMemory ou des erreurs de nettoyage de la mémoire dans les journaux.

    Emplacement du journal :

    • Windows : %ALLUSERSPROFILE%\VMWare\vCenterServer\logs\vsphere-client\logs\
    • vCenter Server Appliance (VCSA) : /var/log/vmware/vsphere-client/logs/

    Fichiers journaux : dataservice.log and vsphere_client_virgo.log

    Commandes de redémarrage des services :
    service-control --stop vmware-vpxd-svcs
    service-control --start vmware-vpxd-svcs

  • Ralentissement de vSphere Web Client dans des environnements de grande taille comportant plusieurs serveurs vCenter et plusieurs dispositifs PSC
    Dans les environnements de grande taille comportant un grand nombre de serveurs vCenter Server et de dispositifs PSC, le plug-in vSphere Update Manager Web Client peut subir une fuite de thread qui altère les performances de vSphere Web Client dans le temps. Cette altération se produit plus précisément dans des environnements comportant 10 serveurs vCenter Server et 4 dispositifs PSC, plus le nombre maximal de comptes utilisateur Web Client, mais elle est susceptible de se produire dans tous les environnements de grande taille, dans le temps.

    Solution : Pour désactiver le plug-in vSphere Update Manager Web Client, procédez comme suit :

    1. Dans vSphere Web Client, accédez à vSphere Web Client > Administration > Plug-ins de solutions/client.

    2. Cliquez avec le bouton droit sur le plug-in VMware vSphere Update Manager Web Client et sélectionnez Désactiver.

    Si vous ne souhaitez pas utiliser le plug-in, vous pouvez le laisser désactivé ou vous pouvez choisir de le réactiver uniquement lorsque vous en aurez besoin. Si vous subissez une altération de performances, la désactivation, puis la réactivation du plug-in devrait également permettre de réinitialiser temporairement la fuite.

  • Dans vSphere Client ou vSphere Web Client, l'actualisation instantanée des Tâches récentes et de l'état de l'objet cesse de fonctionner après que l'adresse IP de la machine client a été modifiée.
    Dans vSphere Client ou vSphere Web Client, les actions exécutées sur un objet n'apparaissent pas dans les Tâches récentes. Les arborescences et les listes d'inventaire, ainsi que les détails de l'objet ne reflètent pas le nouvel état.

    Par exemple, si vous mettez sous tension une VM, les tâches de mise sous tension n'apparaissent pas dans les tâches récentes et l'icône VM n'est pas dotée d'un badge de mise sous tension dans les arborescences d'inventaires, les listes et les détails d'objet. Le navigateur Web et vCenter Server sont connectés à l'aide de sockets Web et lorsque l'adresse IP de la machine sur laquelle se trouve le navigateur change, la connexion est interrompue.

    Solution : Actualisez la page dans le navigateur Web.

  • Impossible d'accéder à l'interface de gestion de vCenter Server Appliance à partir d'Internet Explorer
    L'interface de gestion de vCenter Server Appliance est inaccessible à partir d'Internet Explorer.

    Solution : dans les paramètres de sécurité d'Internet Explorer, activez TLS 1.0, TL 1.1 et TLS 1.2 :

    1. Dans Internet Explorer, sélectionnez le chemin de menu Outils > Options Internet.

    2. Cliquez sur l'onglet Avancé et faites défiler jusqu'à la section Paramètres de sécurité.

    3. Sélectionnez Utiliser TLS 1.0, Utiliser TLS 1.1 et Utiliser TLS 1.2.

  • Les tentatives d'importation et d'exportation des éléments de bibliothèque de contenu échouent dans les déploiements vCenter Server avec un environnement de PSC externe
    Lorsque vous êtes connecté à vSphere Web Client à l'aide de l'adresse IP dans un déploiement vCenter Server comportant un environnement PSC externe, l'importation et l'exportation d'éléments de bibliothèque de contenu échouent. Le message d'erreur suivant s'affiche :

    Raison : impossible de mettre à jour les fichiers dans l'élément de bibliothèque. La source ou la destination peut être lente ou ne pas répondre.

    Solution : connectez-vous à vSphere Web Client à l'aide d'un nom de domaine complet, et non avec une adresse IP, dans un déploiement vCenter Server avec un environnement de PSC externe.

    Si vous êtes connecté à vSphere Web Client à l'aide d'une adresse IP, acceptez le certificat émis lors de la connexion à l'aide d'un nom de domaine complet. Ouvrez la cible du nom de domaine complet pour accepter le certificat. L'acceptation du certificat de manière permanente devrait suffire.

  • L'interface utilisateur n'affiche pas les périphériques enfichés à chaud dans la liste de périphériques relais PCIe.
    Les périphériques enfichés à chaud PCIe ne sont pas disponibles pour le relais PCI.

    Solution : sélectionnez l'une des options suivantes :

    • Redémarrez hostd à l'aide de la commande suivante : /etc/init.d/hostd restart

    • Redémarrez l'hôte ESXi.

  • Impossible d'afficher l'autorisation sur une balise à partir d'un autre nœud de gestion
    Lorsque vous êtes connecté à un nœud de gestion vCenter Server dans un déploiement vCenter Server multiple, si vous créez une autorisation sur une balise, elle ne s'affiche pas lorsque vous vous connectez à un autre nœud de gestion.

    Solution : alors que les balises sont des objets globaux qui peuvent être affichés dans des nœuds, les autorisations sur des balises ne persistent que localement et ne peuvent pas être affichées de la sorte. Pour afficher une autorisation sur une balise, connectez-vous à l'instance de vCenter Server dans laquelle vous avez créé l'autorisation.

  • Erreur interne due à une connexion à vSphere Web Client en mode incognito
    Les utilisateurs peuvent se connecter à vSphere Web Client lorsque les paramètres du navigateur sont activés pour le mode incognito mais ils reçoivent l'erreur interne suivante :

    An internal error has occurred - [NetStatusEvent type="netStatus" bubbles=false cancelable=false eventPhase=2 info=[object Object]]"

    Solution : désactivez le mode incognito. vSphere Web Client ne prend pas en charge ce mode. Rechargez vSphere Web Client pour résoudre tous les problèmes et reconnectez-vous au client.

  • Les tâches de la bibliothèque de contenu ne sont pas affichées dans les Tâches récentes.
    Si vous exécutez une tâche d'une bibliothèque de contenu dans vSphere Web Client, telle que le téléchargement d'un élément dans la bibliothèque de contenu, la synchronisation d'une bibliothèque ou le déploiement d'une machine virtuelle à partir de la bibliothèque de contenu, il est possible que cette tâche ne soit pas répertoriée dans les Tâches récentes.

    Solution : aucune. Vous pouvez afficher toutes les tâches dans les listes Plus de tâches, même si elles ne figurent pas dans les Tâches récentes.

  • Échec de l'opération d'attribution d'une balise lors de tentatives simultanées de création et d'attribution d'une balise dans un environnement vCenter Server multiple
    Vous pouvez normalement affecter une balise à un objet dans vSphere Web Client à partir du paramètre Balises dans l'onglet Configurer de l'objet et affecter automatiquement la balise à l'objet sélectionné. Dans un environnement comportant plusieurs instances de vCenter Server, la balise est correctement créée, mais les options d'affectation échouent avec un message d'erreur.

    Solution : Commencez par créer la balise sur le paramètre Balises, puis affectez-la à l'objet.

  • L'onglet Solution est supprimé de la vue ESX Agent Manager.
    L'onglet Solution disponible dans la vue ESX Agent Manager dans les versions antérieures de vSphere Web Client n'est plus disponible.

    Solution : Vous pouvez obtenir le même résultat en effectuant les étapes suivantes :

    1. Dans le navigateur de vSphere Web Client, sélectionnez Administration > Extensions vCenter Server.

    2. Cliquez sur vSphere ESX Agent Manager.

    3. Sélectionnez l'une des options suivantes :

      • Sélectionnez l'onglet Configurer.

      • Cliquez sur l'onglet Surveiller, puis cliquez sur Événements.

  • Impossible d'attribuer une balise à des objets lorsque le nœud Platform Services Controller est en panne
    Lorsque le nœud vSphere Platform Services Controller est en panne, vous ne pouvez pas affecter des balises dans l'onglet Gérer > Balises d'un objet.

    Le message d'erreur suivant s'affiche : L'implémentation de la méthode du fournisseur a renvoyé une exception inattendue. Il est impossible de sélectionner des balises afin de les affecter.

    Solution : mettez le nœud Platform Services Controller sous tension. Vérifiez également que tous les services sur le nœud Platform Services Controller sont exécutés.

  • vSphere Client ne reproduit pas la boîte de dialogue de modification des paramètres lorsqu'un administrateur d'hôte ou de centre de données modifie une machine virtuelle
    vSphere Client ne reproduit pas la boîte de dialogue de modification des paramètres lorsqu'un administrateur d'hôte ou de centre de données modifie une machine virtuelle dans cet hôte ou ce centre de données. Cela est dû au fait que l'administrateur d'hôte ou de centre de données ne dispose pas de privilèges de stockage basés sur le profil.

    Solution : Créez un nouveau rôle avec des privilèges d'administrateur d'hôte ou de centre de données et des privilèges de stockage basés sur le profil. Affectez ce rôle à l'administrateur d'hôte ou de centre de données.

  • Lors de la création ou de la modification d'une machine virtuelle à l'aide de vSphere Client, l'ajout d'un huitième disque dur provoque l'échec de la tâche avec une erreur
    La création ou la modification d'une machine virtuelle à l'aide de vSphere Client provoque l'échec de la tâche avec une erreur : Un paramètre spécifié était incorrect : unitNumber. Cela est dû au fait que le contrôleur SCSI 0:7 est réservé à des fins spéciales de sorte que le système affecte SCSI 0:7 au huitième disque dur.

    Solution : L'utilisateur doit affecter manuellement SCSI 0:8 lors de l'ajout d'un huitième disque dur. L'utilisateur peut utiliser vSphere Web Client à la place.

  • vSphere Client prend en charge jusqu'à 10 000 machines virtuelles et 1 000 hôtes
    vSphere Client peut accepter 10 000 machines virtuelles et 1 000 hôtes au maximum, ce qui est inférieur aux limites de vCenter.

    Solution : Si l'utilisateur doit dépasser les limites de vSphere Client, utilisez vSphere Web Client.

  • La zone de texte Nom d'hôte apparaît en grisé dans l'interface de gestion de vCenter Server Appliance si votre système est installé sans nom d'hôte.
    Lorsque vous accédez à l'écran Mise en réseau > Gérer dans l'interface de gestion de vCenter Server Appliance et choisissez Modifier le nom d'hôte, les serveurs de nom et les passerelles, la zone de texte Nom d'hôte apparaît en grisé et ne peut pas être modifiée. Pour activer ce champ et le modifier, vous devez utiliser vSphere Client.

    Solution : Modifiez le nom d'hôte dans vSphere Client.

  • Après que vous modifiez la configuration de la machine virtuelle de vCenter Server Аppliance pour fournir un espace disque plus important en vue d'étendre la partition racine, une tentative de réclamation de ce stockage supplémentaire échoue
    Après le redimensionnement de l'espace disque pour étendre la partition racine, la commande storage.resize n'augmente pas le stockage disque pour la partition racine mais conserve sa taille actuelle. Il s'agit d'un comportement attendu. Le redimensionnement de cette partition n'est pas pris en charge.

    Solution : aucune.

  • L'interface Web de gestion de vCenter Server Appliance Management permet uniquement la configuration du serveur proxy HTTP
    Lorsque vous accédez à l'onglet Mise en réseau dans l'interface de gestion de vCenter Server Appliance et choisissez Modifier les paramètres de proxy, l'option permettant de modifier le proxy en HTTPS ou FTP n'est pas disponible. Vous pouvez uniquement spécifier les paramètres de proxy HTTP.

    Solution : Vous pouvez configurer les serveurs proxy HTTPS et FTP en utilisant l'interpréteur de ligne de commande du dispositif.

  • Après une mise à jour réussie de vCenter Server Appliance, l'exécution de la commande version.get à partir de l'interpréteur du dispositif renvoie un message d'erreur
    Après une mise à jour réussie de vCenter Server Appliance, l'exécution de la commande version.get à partir de l'interpréteur du dispositif renvoie un message d'erreur : Unknown command: 'version.get'.

    Solution : Déconnectez-vous et reconnectez-vous en tant qu'administrateur de/à une nouvelle session d'interpréteur du dispositif et exécutez la commande version.get.

  • Dans Windows Internet Explorer 11 ou versions ultérieures, la case à cocher Utiliser l'authentification de session Windows est inactive sur la page de connexion de vSphere Web Clientbr /> La case à cocher Utiliser l'authentification de session Windows est inactive sur la page de connexion de vSphere Web Client dans les navigateurs Windows Internet Explorer 11 ou versions ultérieures. Vous êtes également invité à télécharger et installer le plug-in VMware Enhanced Authentication.

    Solution : dans les options de sécurité des paramètres Windows de votre système, ajoutez le nom de domaine complet et l'adresse IP de vCenter Server à la liste des sites Intranet locaux.

  • Échec du téléchargement d'un fichier à l'aide du navigateur de banque de données lorsque le fichier dépasse 4 Go dans Internet Explorer
    Lorsque vous téléchargez un fichier de plus de 4 Go à l'aide du navigateur de banque de données dans Internet Explorer, l'erreur suivante est renvoyée :

    Failed to transfer data to URL.

    Internet Explorer ne prend pas en charge les fichiers dont la taille dépasse 4 Go.

    Solution : Utilisez Chrome ou Firefox pour télécharger les fichiers à partir du navigateur de banque de données.

Problèmes de gestion des machines virtuelles
  • Le paramètre OVF chunkSize n'est pas pris en charge dans vCenter Server 6.5.
    Le déploiement d'un modèle OVF dans vCenter Server 6.5 échoue avec l'erreur suivante :

    Le paramètre OVF chunkSize défini sur la valeur chunkSize_value n'est actuellement pas pris en charge pour l'importation de module OVF.

    Cette erreur apparaît, car chunkSize n'est pas un paramètre OVF pris en charge dans vCenter Server 6.5.

    Solution : mettez à jour le modèle OVF et supprimez le paramètre chunkSize.

    1. Pour les modèles OVA uniquement, extrayez chaque fichier à l'aide d'un utilitaire tar (par exemple, tar xvf). Cela inclut le fichier OVF (.ovf), le manifeste (.mf) et le disque virtuel (.vmdk).

    2. Associez les fragments de disque virtuel dans un seul disque à l'aide de la commande suivante :

      • Sur Linux ou Mac :
        cat vmName-disk1.vmdk.* > vmName-disk1.vmdk
      • Sur Windows :
        copy /b vmName-disk1.vmdk.000000 + vmName-disk1.vmdk.000001 + repeat until last fragment vmName-disk1.vmdk

      Remarque : s'il n'existe qu'un seul fragment de disque virtuel, renommez-le sur le disque de destination. Si plusieurs disques contiennent des fragments, associez-les individuellement sur chaque disque de destination (par exemple : disk1.vmdk, disk2.vmdk, etc.).

    3. Supprimez l'attribut chunkSize du descripteur OVF (.ovf) à l'aide d'un éditeur de texte. Par exemple :
      <File ovf:chunkSize="7516192768" ovf:href="vmName-disk1.vmdk" ovf:id="file1" ovf:size=... />
      Version corrigée :
      <File ovf:href="vmName-disk1.vmdk" ovf:id="file1" ovf:size=.../>

    4. Déployez le modèle OVF via vSphere Web Client en sélectionnant les fichiers locaux, y compris le descripteur OVF mis à jour et le disque fusionné.

    5. Pour les modèles OVA uniquement, procédez comme suit pour réassembler le fichier OVA via vSphere Web Client :

      1. Exportez le modèle OVF. L'exportation génère un fichier OVF (.ovf), un manifeste (.mf) et un disque virtuel (.vmdk). Le fichier de manifeste est différent de celui mentionné à l'étape 1.

      2. Associez les fichiers dans un seul modèle OVA en utilisant un utilitaire tar (par exemple, tar cvf). Sous Linux, par exemple :
        tar cvf vm.ova vm.ovf vm.mf vm.disk1.vmdk

  • De nouveaux onglets Internet Explorer s'ouvrent lors de l'exportation d'un modèle OVF ou de l'exportation d'éléments à partir de la bibliothèque de contenu.
    Si vous utilisez vSphere Web Client avec Internet Explorer pour exporter un modèle OVF ou pour exporter un élément à partir d'une bibliothèque de contenu, de nouveaux onglets s'ouvrent dans le navigateur pour chaque fichier de l'élément de la bibliothèque de contenu ou du modèle OVF. Pour chaque nouvel onglet, un message peut vous inviter à accepter un certificat de sécurité.

    Solution : acceptez chaque certificat de sécurité, puis enregistrez chaque fichier.

  • vCenter Server ne supprime pas OpaqueNetwork de l'inventaire vCenter.
    Si une machine virtuelle est connectée à un réseau opaque et que cette machine virtuelle est convertie en modèle, vCenter Server ne supprimera pas OpaqueNetwork de l'inventaire vCenter Server, même si l'hôte ESXi est supprimé du réseau opaque et qu'aucune machine virtuelle n'y est connectée. Cela est dû au fait que des modèles sont toujours attachés au réseau opaque.

    Solution : aucune.

  • Le déploiement d'un modèle OVF génère l'erreur error.mutationService.ProviderMethodNotFoundError dans certains affichages
    Vous obtenez une erreur error.mutationService.ProviderMethodNotFoundError lorsque vous déployez un modèle OVF et que toutes les conditions suivantes sont réunies :

    • Vous sélectionnez un fichier OVF dans votre système de fichiers local, puis cliquez sur Suivant dans l'assistant Déployer un modèle OVF.

    • La taille du fichier OVF est inférieure à 1,5 Mo.

    • Vous déployez le modèle OVF sans sélectionner l'objet. Par exemple, dans l'affichage de la liste des machines virtuelles.

    Solution : Déployez un modèle OVF en sélectionnant l'objet, puis en choisissant l'option Déployer OVF.

  • Le déploiement d'un modèle OVF ou OVA contenant des disques delta dans vSphere Web Client à partir d'un fichier local peut échouer
    Lorsque vous déployez un modèle OVF ou OVA contenant des disques delta (ovf:parentRef dans le fichier OVF), l'opération peut échouer ou se figer pendant le processus.

    Un exemple d'éléments OVF dans le descripteur OVF est présenté ci-après :

     <References>
      <File ovf:href="Sugar-basedisk-1-4.vmdk" ovf:id="basefile14" ovf:size="112144896"/>
      <File ovf:href="Sugar-disk1.vmdk" ovf:id="file1" ovf:size="44809216"/>
      <File ovf:href="Sugar-disk4.vmdk" ovf:id="file4" ovf:size="82812928"/>
     </References>

     <DiskSection>
      <Info>Meta-information about the virtual disks</Info>
      <Disk ovf:capacity="1073741824"
       ovf:diskId="basedisk14"
       ovf:fileRef="basefile14"
       ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
      <Disk ovf:capacity="1073741824"
       ovf:diskId="vmdisk1"
       ovf:fileRef="file1"
      ovf:parentRef="basedisk14"
       ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" />
      <Disk ovf:capacity="1073741824"
      ovf:diskId="vmdisk4"
      ovf:fileRef="file4"
      ovf:parentRef="basedisk14"
      ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized"/>
     </DiskSection>

    Solution : pour déployer le modèle OVF ou OVA, hébergez-le sur un serveur HTTP. Déployez ensuite le modèle à partir de l'URL HTTP pointant vers ce modèle.

  • Aucune option de mise sous tension disponible lors de la finalisation du déploiement OVF
    Pendant un déploiement OVF ou OVA, l'assistant de déploiement n'offre aucune option de mise sous tension automatique de la machine virtuelle lorsque le déploiement prend fin.

    Solution : cette option n'est pas disponible dans vSphere 6.5 lors de l'utilisation de l'assistant de déploiement OVF. Mettez la machine sous tension manuellement une fois le déploiement terminé.

  • Lorsque l'assistant de déploiement OVF est démarré depuis la liste d'inventaires globaux, le message d'erreur approprié ne s'affiche pas sur la page d'emplacement de l'assistant
    Cette erreur se produit lorsque vous déployez un modèle OVF à partir de l'une des listes d'inventaires globaux (par exemple, liste d'inventaires de la machine virtuelle) dans vSphere Web Client et que vous accédez à la page Sélectionner un nom et un emplacement de l'assistant. Si vous ne choisissez pas un emplacement valide, au lieu du message d'erreur approprié, les boutons de navigation sont désactivés et vous ne pouvez pas poursuivre l'exécution de l'assistant.

    Solution : annulez l'exécution de l'assistant, ouvrez-le de nouveau et choisissez un emplacement valide.

  • L'assistant de déploiement OVF ne peut pas déployer un modèle OVF ou OVA local contenant des groupes de messages externes
    Lorsqu'un modèle OVF ou OVA contient des références à des groupes de messages externes, il ne peut pas être déployé à partir d'un fichier local.

    Solution : pour déployer le modèle OVF ou OVA, procédez de l'une des manières suivantes :

    • Déployez le modèle OVF ou OVA à partir d'une adresse URL.

    • Modifiez le fichier OVF pour remplacer la balise qui pointe vers le fichier de message externe (la balise <Strings ovf:fileRef />) par le contenu réel du fichier de message externe.

  • Impossible de créer ou de cloner une machine virtuelle sur un cluster de banque de données sur lequel SDRS est désactivé
    Ce problème se produit lorsque vous sélectionnez une banque de données incluse dans un cluster de banques de données sur lequel SDRS est désactivé dans un Assistant Nouvelle machine virtuelle, Cloner une machine virtuelle (vers une machine virtuelle ou vers un modèle) ou Déployer depuis un modèle. Lorsque vous accédez à la page Prêt à terminer et que vous cliquez sur Terminer, l'assistant reste ouvert et il semble que rien ne se passe. La valeur Banque de données de la machine virtuelle peut afficher l'état « Récupération des données en cours » sans que rien ne change.

    Solution : utilisez vSphere Web Client pour positionner des machines virtuelles sur des clusters de banque de données sur lesquels SDRS est désactivé.

  • Le déploiement d'un modèle OVF ou OVA échoue pour des descripteurs spécifiques
    Le déploiement d'un modèle OVF ou OVA à partir de vSphere Web Client échoue si le descripteur dans le modèle contient l'une des valeurs suivantes avec le message d'erreur correspondant :

    • Nombre négatif comme valeur du paramètre de taille dans l'élément fileref. Exemple de message d'erreur :
      VALUE_ILLEGAL: Illegal value ";-2&" for attribute "size". Must be positive.

    • L'attribut de réservation facultatif est spécifié mais aucun paramètre n'est fourni dans la section Matériel VM. Par exemple : <Reservation />. Exemple de message d'erreur :
      VALUE_ILLEGAL: Illegal value "" for element "Reservation". Not a number.

    • Élément vssd VirtualHardwareSection.System.InstanceID manquant. Exemple de message d'erreur :
      ELEMENT_REQUIRED: Element "InstanceID" expected.

    • La section internationalisation Strings fait référence à un fichier manquant. Exemple de message d'erreur :
      VALUE_ILLEGAL: Illegal value "eula" for attribute "fileRef".

    • Préfixe inconnu ajouté à la section internationalisation Strings. Par exemple : <ovfstr:Strings xml:lang="de-DE"> Exemple de message d'erreur :
      PARSE_ERROR: Parse error: Undeclared namespace prefix "ovfstr" at [row,col,system-id]: [41,39,"descriptor.ovf"].

    • OVF contient des éléments de spécification OVF version 0.9. Exemple de message d'erreur :
      VALUE_ILLEGAL: OVF 0.9 is not supported. Invalid name space: "http://www.example.com/schema/ovf/1/envelope".

    Solution : modifiez le descripteur de façon à être valide conformément à la spécification OVF version 1.1.

  • Un périphérique USB activé via vMotion et connecté à une machine virtuelle n'est pas visible dans vSphere Web Client
    Si vous connectez un périphérique USB activé via vMotion à une machine virtuelle exécutée sur ESXi 6.5, le périphérique n'est pas visible dans vSphere Web une fois que vous avez interrompu, puis relancer la machine virtuelle. Ce problème se produit lorsque le périphérique se reconnecte correctement à la machine virtuelle. Par conséquent, vous ne pouvez pas déconnecter le périphérique.

    Solution : utilisez l'une des solutions suivantes :

    • Essayez de connecter un autre périphérique USB à cette machine virtuelle. Les deux périphériques sont visibles dans vSphere Web Client, ce qui vous permet de déconnecter le premier périphérique USB.

    • Mettez la machine virtuelle hors tension, puis rallumez-la. Le périphérique est visible dans vSphere Web Client.

  • Échec possible du téléchargement de fichiers à l'aide d'une bibliothèque de contenu, d'une banque de données ou d'un déploiement OVF/OVA
    Si vous tentez de télécharger un fichier à l'aide d'une bibliothèque de contenu, d'une banque de données ou d'un déploiement OVA/OVF dans vSphere Web Client, l'opération peut échouer avec le message d'erreur suivant : L'opération a échoué pour une raison indéterminée.

    L'échec se produit car les certificats ne sont pas approuvés. Si l'URL en cours de traitement pour l'opération de téléchargement du fichier n'est pas déjà approuvée, le téléchargement échoue.

    Solution : copiez l'URL à partir de l'erreur, ouvrez un nouvel onglet du navigateur et visitez la cible de l'URL. Vous êtes normalement invité à accepter le certificat associé à cette URL. Approuvez et acceptez le nouveau certificat, puis réitérez l'opération. Reportez-vous à l'article 2147256 de la base de connaissances VMWare pour obtenir plus de détails.

  • Le déploiement d'un modèle OVA à partir d'une adresse URL contenant un fichier de manifeste ou de certificat à la fin peut échouer dans un environnement réseau lent
    Lorsque vous déployez un modèle OVA de grande taille contenant un ou plusieurs fichiers de manifeste ou de certificat à la fin, le déploiement peut échouer dans un environnement réseau lent avec l'erreur suivante :
    Impossible de récupérer le fichier de manifeste ou de certificat.

    Un exemple d'un modèle OVA contenant des fichiers de manifeste ou de certificat à la fin est présenté ci-après :

    example.ova:

    • example.ovf
    • example-disk1.vmdk
    • example-disk2.vmdk
    • example.mf
    • example.cert

    Cette erreur se produit, car les fichiers de manifeste ou de certificat sont nécessaires pour le processus de déploiement. C'est pourquoi, il faut que ces fichiers apparaissent au début du fichier OVA pour assurer la rapidité du processus.

    Solution : mettez en œuvre l'une des solutions suivantes pour déployer le modèle OVA :

    • Téléchargez le modèle OVA sur votre système local et déployez-le à partir d'un fichier OVA local.

    • Convertissez le modèle OVA en plaçant les fichiers de manifeste ou de certificat au début du fichier de modèle OVA. Pour convertir le modèle example.ova, procédez comme suit :

      1. Connectez-vous au serveur HTTP et accédez au dossier contenant le modèle OVA.

      2. Extrayez les fichiers du modèle OVA :
        tar xvf example.ova

      3. Pour recréer le modèle OVA, exécutez les commandes suivantes dans l'ordre :

        tar cvf example.ova example.ovf
        tar uvf example.ova example.mf
        tar uvf example.ova example.cert
        tar uvf example.ova example-disk1.vmdk
        tar uvf example.ova example-disk2.vmdk

      4. Redéployez le modèle OVA à partir de l'adresse URL HTTP.

  • Les modèles OVF exportées vers vSphere 6.5 qui contiennent ne peuvent pas être déployés dans vSphere 5.5 ou vSphere 6.0
    Si un modèle OVF qui contient dans le descripteur OVF est exporté depuis vSphere Web Client 6.5, il ne peut pas être déployé à partir de vSphere Web Client 5.5 ou vSphere Web Client 6.0. Un exemple d'un élément OVF dans le descripteur OVF est présenté ci-après :

    <Annotation>--- This is a sample annotation for this OVF template ---</Annotation>

    Solution : Supprimez du descripteur OVF :

    1. Supprimez toutes les instances de du descripteur OVF.

    2. Si le modèle OVA ou OVA est un fichier de manifeste, recalculez le total de contrôle en fonction du descripteur OVF mis à jour et mettez à jour le fichier de manifeste. Si un fichier de certificat existe, mettez-le à jour pour remplacer le total de contrôle pour le fichier de manifeste mis à jour.

  • vSphere Web Client ne prend pas en charge l'exportation de machines virtuelles ou de vApp en tant que modèles OVA
    Dans des versions antérieures à vSphere 6.5, vous pouviez exporter des machines virtuelles ou des vApp en tant que modèles OVA sur vSphere Web Client. Cette fonctionnalité n'est pas disponible dans vSphere 6.5.

    Solution : exportez la machine virtuelle en tant que modèle OVF, puis créez un modèle OVA à partir des fichiers de modèle OVF. La procédure suivante décrit ce processus à l'aide des commandes Linux sous Mac. Les systèmes Windows nécessitent l'installation d'un utilitaire compatible TAR.

    1. Utilisez vSphere Web Client pour exporter la VM ou la vApp en tant que modèle OVF vers la machine locale.

    2. Recherchez les fichiers de modèle OVF téléchargés et déplacez-les dans un nouveau dossier vide.

    3. Effectuez l'une des tâches suivantes pour créer un modèle OVA à partir d'un modèle OVF.

      • Accédez au nouveau dossier et créez un modèle OVA à l'aide de la commande tar pour combiner les fichiers :
        cd folder
        tar cvf ova-template-name.ova ovf-template-name.ovf
        tar uvf ova-template-name.ova ovf-template-name.mf
        tar uvf ova-template-name.ova ovf-template-name-1.vmdk
        ...
        tar uvf ova-template-name.ova ovf-template-name-n.vmdk

        n fait référence au nombre de disques que contient la VM. ova-template-name.ova est le modèle OVA final. Exécutez les commandes dans l'ordre exact de façon à créer le modèle OVA de façon conforme.

        Remarque : la commande tar doit utiliser le format TAR et être conforme au format USTAR (Uniform Standard Tape Archive), comme défini par le groupe de normes POSIX IEEE 1003.1.

      • Si l'outil OVF est installé sur votre système, exécutez la commande suivante :
        cd downloaded-ovf-template-folder
        path-to-ovf-tool\ovftool.exe ovf-template-name.ovf ova-template-name.ova

  • Le déploiement d'un modèle OVF contenant des références à des fichiers compressés peut échouer
    Lorsque vous déployez un modèle OVF contenant des références à des fichiers compressés (généralement à l'aide de gzip), l'opération échoue.

    Un exemple d'un élément OVF dans le descripteur OVF est présenté ci-après :
    <References>
       <File ovf:size="458" ovf:href="valid_disk.vmdk.gz" ovf:compression="gzip" ovf:id="file1"></File>
    </References>

    Solution : si l'outil OVF est installé sur votre système, exécutez la commande suivante pour convertir le modèle OVF ou OVA. Le nouveau modèle ne doit pas comporter de disques compressés.

    1. Accédez au dossier contenant le modèle :
      cd template-folder

    2. Convertissez le modèle.

      • Conversion du modèle OVA :
        path-to-ovf-tool\ovftool.exe ova-template-name.ova newova-template-name.ova

      • Conversion du modèle OVF :
        path-to-ovf-tool\ovftool.exe ovf-template-name.ovf new-ovf-template-name.ovf

  • Le déploiement d'un modèle OVF ou OVA contenant des URL HTTP dans les références aux fichiers échoue
    Lorsque vous tentez de déployer un modèle OVF ou OVA contenant une URL HTTP dans les références aux fichiers, l'opération échoue avec l'erreur suivante :
    Invalid response code: 500

    Par exemple :
    <References>
      <File ovf:size="0" ovf:href="http://www.example.com/dummy.vmdk" ovf:id="file1"></File>
    </References>

    Solution : pour télécharger les fichiers à partir du serveur HTTP et mettre à jour le modèle OVF ou OVA, effectuez les étapes suivantes :

    1. Ouvrez le descripteur OVF et recherchez les références aux fichiers avec les URL HTTP.

      Pour les modèles OVA, extrayez les fichiers à partir du modèle OVA pour ouvrir le descripteur OVF. Par exemple, exécutez la commande suivante :
      tar xvf ova-template-name&.ova

      Remarque : cette commande est destinée à un système Linux ou Mac. Les systèmes Windows nécessitent l'installation d'un utilitaire tar.

    2. Téléchargez les fichiers à partir des URL HTTP vers une machine locale et copiez ces fichiers dans le même dossier que le modèle OVF ou OVA.

    3. Remplacez les URL HTTP dans le descripteur OVF par les noms de fichiers réels qui sont téléchargés vers le dossier. Par exemple :
      <File ovf:size="actual-downloaded-file-size" ovf:href="dummy.vmdk" ovf:id="file1"></File>

    4. Si le modèle contient un fichier de manifeste (.mf) et un fichier de certificat (.cert), regénérez ces fichiers en recalculant les totaux de contrôle des fichiers pertinents. Autrement, ignorez ces fichiers pendant l'opération de déploiement OVF.

      Pour le modèle OVA et uniquement pour ce modèle, recréez ce modèle selon l'une des méthodes suivantes :

      • Utilisez la commande tar pour recréer le modèle :
        cd folder/ tar cvf ova-template-name.ova ovf-name.ovf
        tar uvf ova-template-name.ova manifest-name.mf
        tar uvf ova-template-name.ova cert-name.cert
        tar uvf ova-template-name.ova disk-name.vmdk

        Répétez l'opération pour d'autres disques ou références de fichiers.

        Remarque : La commande tar utilise le format TAR et doit respecter le format USTAR (Uniform Standard Tape Archive), comme le stipule le groupe de normes POSIX IEEE 1003.1.

      • Utilisez l'outil OVF pour recréer le modèle (Windows) :
        cd folder
        path-to-ovf-tool\ovftool.exe ovf-name.ovf ova-template-name.ova

  • Échec du déploiement de modèles OVF ou OVA à partir d'URL HTTP ou HTTPS qui requièrent une authentification
    Lorsque vous tentez d'utiliser vSphere Web Client pour déployer un modèle OVF ou OVA à partir d'une URL HTTP ou HTTPS qui requiert une authentification, l'opération échoue. Vous recevez le message d'erreur suivant :
    Échec du transfert : Code de réponse 401 non valide.

    La tentative de déploiement du modèle OVF ou OVA échoue, car vous ne pouvez pas entrer vos informations d'identification.

    Solution : téléchargez les fichiers et déployez le modèle localement comme suit :

    1. Téléchargez le modèle OVF ou OVA manuellement à partir de l'URL HTTP ou HTTPS, vers un dossier accessible de votre machine locale.

    2. Déployez une machine virtuelle à partir du modèle OVF ou OVA téléchargé sur la machine locale.

  • Le déploiement d'un modèle OVF ou OVA avec les options de démarrage EFI/UEFI n'est pas pris en charge dans vSphere Web Client.
    Lorsque vous déployez un modèle OVF ou OVA dans vSphere Web Client avec l'option de démarrage EFI et que vous incluez un fichier NVRAM, l'opération échoue.

    Solution : Déployez le modèle OVF avec l'option de démarrage EFI à l'aide d'OvfTool 4.2.0.

  • Le profil de protocole réseau existant n'est pas rempli et ne met pas à jour la page Personnaliser un modèle de l'assistant Déployer un modèle OVF
    Sur la page Personnaliser un modèle OVF de l'assistant Déployer un modèle OVF, les propriétés personnalisées suivantes sont reconnues et affichées :
    gateway, netmask, dns, searchPath, domainName, hostPrefix, httpProxy et subnet

    Si aucun profil de protocole réseau n'existe pour le réseau sélectionné, un nouveau profil de protocole réseau est automatiquement créé si aucune des propriétés personnalisées n'est définie. Chaque propriété contient les valeurs entrées.

    Si un profil de protocole réseau existe déjà pour le réseau sélectionné, le nouvel assistant ne pré-remplit pas ces propriétés personnalisées, et tous les changements apportés à ces champs sont ignorés.

    Solution : si vous avez besoin de paramètres personnalisés autres que les paramètres de profil de protocole réseau existants, assurez-vous qu'aucun profil de protocole réseau n'existe sur le réseau sélectionné. Supprimez le profil ou supprimez le mappage réseau dans le profil.

  • Le modèle sélectionné n'est pas conservé lors de la réduction de l'assistant Déployer le modèle OVF, de l'actualisation de vSphere Web Client, puis de la restauration de l'assistant
    Lors du déploiement d'un modèle OVF avec l'assistant Déployer le modèle OVF, procédez comme suit :

    1. Naviguez dans toutes les pages de l'assistant Déployer le modèle OVF jusqu'à la dernière étape.

    2. Réduisez l'assistant au panneau Travail en cours.

    3. Cliquez sur Actualisation globale en haut près du nom d'utilisateur.

    4. Restaurez l'assistant à partir du panneau Travail en cours.

    Cette procédure génère deux problèmes :

    • La valeur Nom de la VM source est identique à la valeur du champ Nom.

    • Si vous accédez à la page Choisir le modèle, le modèle sélectionné est vide, ce qui indique qu'il n'a pas été conservé.

    Bien que le modèle sélectionné ne s'affiche pas, l'assistant peut être exécuté et le modèle se déploie correctement. Ce problème survient uniquement dans l'interface vSphere Web Client pour l'affichage des deux valeurs ci-dessus.

    Solution : évitez d'utiliser le bouton Actualisation globale lors du déploiement d'un modèle OVF.

  • Le déploiement d'un modèle OVF échoue pour l'utilisateur qui ne dispose pas de l'autorisation Datastore.Allocate Space
    Lorsque vous déployez un modèle OVF sans autorisation Datastore.Allocate Space, l'opération échoue.

    Solution : attribuez l'autorisation Banque de données.Allouer l'espace à l'utilisateur.

  • Le déploiement OVF d'un vApp échoue dans un cluster non-DRS
    Lorsque vous tentez de déployer un OVF contenant un vApp dans un cluster non-DRS, l'opération échoue. Dans vSphere 6.5, l'assistant de déploiement d'OVF permet de sélectionner un cluster non DRS qui réussit les tests de compatibilité. Toutefois, la tentative de déploiement échoue.

    Solution : activez DRS pour le cluster choisi ou sélectionnez un autre emplacement de déploiement.

  • Si vous utilisez l'option LimitVMsPerESXhost, il est possible que l'équilibrage de DRS charge soit désactivé et qu'aucune recommandation ne soit générée.
    L'option LimitVMsPerESXhost est mise en œuvre dans le cadre du contrôle de contraintes DRS. Si le nombre de machines virtuelles sur l'hôte dépasse la limite spécifiée par l'option LimitVMsPerESXhost, aucune autre machine virtuelle ne peut être mise sous tension ou migrée vers l'hôte par DRS.

    Solution : vous pouvez utiliser une nouvelle option avancée TryBalanceVmsPerHost pour remplacer l'option LimitVMsPerESXhost dans cette version, ce qui permet d'éviter l'échec potentiel de DRS. Le problème de déséquilibre du cluster peut se produire lorsque vous configurez manuellement l'option LimitVMsPerESXhost sur une faible valeur (par exemple, 0).

  • La barre de progression de la tâche pour certaines opérations de la bibliothèque de contenu ne change pas
    La barre de progression de la tâche pour certaines opérations de la bibliothèque de contenu affiche 0 % lors de la progression de la tâche. Ces opérations sont :

    • Déployez une machine virtuelle à partir d'un modèle VM et à partir d'une bibliothèque de contenu.

    • Clonage d'un élément de bibliothèque d'une bibliothèque vers une autre bibliothèque.

    • Synchronisation d'une bibliothèque abonnée.

    Solution : aucune.

  • La version initiale d'un élément de bibliothèque de contenu récemment créé est 2
    La version initiale d'un élément de bibliothèque de contenu récemment créé est 2 au lieu de 1. Vous pouvez afficher la version d'un élément de bibliothèque de contenu dans la colonne Version de la liste des éléments de bibliothèque de contenu.

    Solution : aucune.

  • Si votre nom d'utilisateur contient des caractères non ASCII, vous ne pouvez pas importer d'éléments dans une bibliothèque de contenu depuis votre système local
    Si votre nom d'utilisateur contient des caractères non ASCII, il se peut que vous ne puissiez pas importer d'éléments dans une bibliothèque de contenu depuis votre système local.

    Solution : pour importer un élément dans une bibliothèque de contenu, utilisez un lien URL tel qu'un lien HTTP, NFS ou SMB.

  • Si votre nom d'utilisateur contient des caractères non ASCII, vous ne pouvez pas exporter d'éléments d'une bibliothèque de contenu vers votre système local
    Si votre nom d'utilisateur contient des caractères non ASCII, il se peut que vous ne puissiez pas exporter d'éléments d'une bibliothèque de contenu vers votre système local.

    Solution : aucune.

  • Lorsque vous synchronisez un élément de bibliothèque de contenu dans une bibliothèque de contenu abonnée, certaines balises de l'élément peuvent ne pas apparaître
    Certaines balises d'un élément d'une bibliothèque de contenu publiée peuvent ne pas apparaître dans votre bibliothèque de contenu abonnée une fois que vous avez synchronisé l'élément.

    Solution : aucune.

  • La barre de progression de la tâche Déployer un OVF reste à 0 %
    Lorsque vous déployez un modèle OVF à partir du système local, la barre de progression de l'assistant Déployer un modèle OVF reste à 0 %. Cependant, les tâches Déployer un modèle OVF et Importer un module OVF sont créées.

    Solution : lorsque vous sélectionnez un modèle OVF local, assurez-vous de sélectionner tous les fichiers référencés, y compris le fichier OVF et les fichiers VMDK qui sont définis dans le fichier du descripteur OVF.

  • L'opération de déploiement échoue si un modèle de machine virtuelle (OVF) inclut une stratégie de stockage avec réplication.
    Si une machine virtuelle comporte une stratégie de stockage avec un groupe de réplication de stockage et est capturée comme modèle dans une bibliothèque, ce modèle entraîne l'échec du déploiement de la machine virtuelle. Ce phénomène se produit car il est impossible de sélectionner un groupe de réplication lors du déploiement à partir d'un modèle de bibliothèque de contenu. La sélection d'un groupe de réplication est requise pour ce type de modèle. Vous recevrez un message d'erreur et devrez fermer l'assistant manuellement. Il ne se fermera pas automatiquement malgré l'échec de l'opération.

    Solution : supprimez la stratégie de la machine virtuelle d'origine et créez un nouveau modèle de machine virtuelle. Vous pouvez ajouter une stratégie à une nouvelle machine virtuelle une fois le nouveau modèle créé et déployé.

  • Si vous sélectionnez une stratégie de stockage lors du déploiement d'un modèle de bibliothèque de contenu, une sélection de banque de données ou de cluster de banques de données est ignorée
    Si vous sélectionnez une stratégie de stockage, une sélection de banque de données ou de cluster de banques de données est ignorée La machine virtuelle est déployée sur le profil de stockage sélectionné, mais elle n'est pas déployée sur la banque de données ou le cluster de banques de données sélectionné.

    Solution : si la machine virtuelle doit être déployée sur la banque de données ou le cluster de banques de données sélectionné, assurez-vous que la stratégie de stockage est définie sur « Aucune » lorsque vous déployez un modèle de bibliothèque de contenu. Cela permet de garantir que la machine virtuelle est stockée sur la banque de données ou le cluster de banques de données. Après le déploiement réussi de la machine virtuelle, vous pouvez appliquer une stratégie de stockage en accédant à la page de la machine virtuelle déployée et en modifiant la stratégie.

  • Le téléchargement d'éléments vers une bibliothèque s'arrête lorsque tous les hôtes associés à la banque de données de sauvegarde sont en mode maintenance
    Vous ne pouvez pas télécharger d'éléments vers une bibliothèque lorsque tous les hôtes associés à la banque de données de sauvegarde de cette bibliothèque sont en mode maintenance. Si vous le faites, le processus cesse de répondre.

    Solution : assurez-vous qu'au moins un hôte associé à la banque de données de sauvegarde de la bibliothèque est disponible lors du téléchargement.

  • Lors du montage d'un fichier ISO d'une bibliothèque de contenu vers une machine virtuelle non associée, une boîte de dialogue vide s'affiche
    Vous pouvez uniquement monter un fichier ISO d'une bibliothèque de contenu vers une machine virtuelle si la banque de données ou le dispositif de stockage sur lequel réside le fichier ISO est accessible depuis l'hôte de la machine virtuelle. Si la banque de données ou le dispositif de stockage n'est pas accessible, l'interface affiche une boîte de dialogue vide.

    Solution : rendez le dispositif de stockage sur lequel réside le fichier ISO accessible à l'hôte sur lequel les machines virtuelles résident. Si des stratégies vont à l'encontre de cela, vous pouvez copier le fichier ISO dans une bibliothèque sur une banque de données accessible à la machine virtuelle.

  • Une recherche avancée des bibliothèques de contenu ayant pour propriété « Bibliothèque de contenu publié » échoue
    Le processus de « Recherche avancée » de bibliothèques de contenu dont la valeur de propriété est « Bibliothèque de contenu publié » entraîne l'échec de la recherche.

    Solution : recherchez manuellement des bibliothèques publiées.

Problèmes de migration
  • Les tentatives de migration d'une installation Windows de vCenter Server ou de Platform Services Controller vers un dispositif peuvent échouer avec un message d'erreur concernant les paramètres de configuration DNS si l'installation Windows source est définie avec une configuration IPv4 et IPv6 statique.
    La migration d'une installation Windows configurée avec des adresses IPv4 et IPv6 statiques peut échouer avec le message d'erreur suivant : Erreur lors de la définition de la configuration du DNS. Détails : l'opération a échoué. Code : com.vmware.applmgmt.err_operation_failed.

    Le fichier journal /var/log/vmware/applmgmt/vami.log du dispositif récemment déployé contient les entrées suivantes :
    INFO:vmware.appliance.networking.utils:Running command: ['/usr/bin/netmgr', 'dns_servers', '--set', '--mode', 'static', '--servers', 'IPv6_address,IPv4_address']
    INFO:vmware.appliance.networking.utils:output:
    error:
    returncode: 17
    ERROR:vmware.appliance.networking.impl:['/usr/bin/netmgr', 'dns_servers', '--set', '--mode', 'static', '--servers', 'IPv6_address,IPv4_address'] error , rc=17

    Solution :

    1. Supprimez le dispositif récemment déployé et restaurez l'installation Windows source.

    2. Sur l'installation Windows source, désactivez la configuration IPv6 ou IPv4.

    3. À partir du serveur DNS, supprimez l'entrée de l'adresse IPv6 ou IPv4 que vous avez désactivée.

    4. Recommencez la migration.

    5. (Facultatif) Une fois la migration terminée, ajoutez à nouveau l'entrée DNS, puis, sur le dispositif migré, définissez l'adresse IPv6 ou IPv4 que vous avez désactivée.

  • Échec de l'initialisation de VMware Migration Assistant lors de la migration de vCenter Server 6.0 avec SQL externe avec le mode Authentification Windows intégrée
    En tant qu'utilisateur sans le privilège « Remplacer un jeton de niveau processus », lorsque vous migrez à partir de vCenter Server sous Windows avec une base de données Microsoft SQL Server configurée avec « Authentification Windows intégrée », l'initialisation de l'assistant de migration VMware échoue avec un message d'erreur vague qui n'indique pas la cause de l'échec.

    Par exemple : Échec d'exécution des contrôles de prémigration

    La base de données vCenter Server collecte des exigences dans un journal situé sous :
    %temp/vcsMigration/CollectRequirements_com.vmware.vcdb_2016_02_04_17_50.log

    Le journal contient l'entrée :
    2016-02-04T12:20:47.868Z ERROR vcdb.const Error while validating source vCenter Server database: "[Error 1314] CreateProcessAsUser: 'A required privilege is not held by the client.' "

    Solution : vérifiez que vous avez défini le privilège « Remplacer un jeton de niveau processus » pour l'utilisateur exécutant la migration. Un guide pour vous aider à personnaliser les paramètres est disponible dans la documentation Microsoft en ligne. Vous pouvez exécuter de nouveau la migration après avoir vérifié que les autorisations sont correctes.

Problèmes de vSphere HA et Fault Tolerance
  • Échec de la réplication de vCenter High Availability lors de l'expiration du mot de passe utilisateur
    Lorsque le mot de passe utilisateur de vCenter High Availability expire, la réplication de vCenter High Availability échoue avec plusieurs messages d'erreur. Pour plus d'informations sur les erreurs et la cause, reportez-vous à l'article http://kb.vmware.com/kb/2148675.

    Solution : réinitialisez le mot de passe utilisateur de vCenter High Availability sur chacun des 3 nœuds de vCenter High Availability : actif, passif et témoin. Reportez-vous à l'article http://kb.vmware.com/kb/2148675 pour obtenir des instructions sur la réinitialisation des mots de passe des utilisateurs.

  • Le déploiement de vCenter High Availability avec une adresse IP de basculement de remplacement pour le nœud passif sans spécifier une adresse IP de passerelle entraîne l'échec de vCenter
    vCenter High Availability exige que vous spécifiez une adresse IP de passerelle si une adresse IP de remplacement et un masque de réseau sont définis pour le nœud passif dans un déploiement de vCenter High Availability. Si cette adresse IP de passerelle n'est pas spécifiée lorsque vous utilisez une adresse IP de remplacement pour le déploiement du nœud passif, vCenter Server échoue.

    Solution : vous devez spécifier une adresse IP de passerelle si vous utilisez une adresse IP de remplacement pour le nœud passif dans un déploiement de VCHA.

  • Le déploiement de vCenter High Availability peut échouer si le dispositif a un nom d'hôte comprenant des minuscules et des majuscules lorsque vous configurez le dispositif
    Si un VCSA est installé avec un nom de domaine complet comprenant des minuscules et des majuscules, une nouvelle tentative de déploiement de vCenter High Availability peut échouer. Cela est dû au fait que la validation du nom d'hôte lors du déploiement de vCenter High Availability est sensible à la casse.

    Solution : vous devez utiliser un nom d'hôte comprenant uniquement des minuscules ou des majuscules lorsque vous configurez le dispositif.

  • SSH doit être activé sur vCenter Server Appliance pour configurer vCenter HA
    Si SSH est désactivé pendant l'installation d'un nœud de gestion (avec PSC externe) et pendant la configuration de vCenter HA à partir d'une instance de vSphere Web Client, le déploiement de vCenter HA échoue avec le message : SSH n'est pas activé. Vous pouvez activer SSH sur vCenter Server Appliance à l'aide de vSphere Web Client ou de l'interface utilisateur de gestion des dispositifs (VAMI) pour activer SSH, puis configurer vCenter HA à partir de vSphere Web Client.

    Solution : aucune. Vous devez activer SSH sur vCenter Server Appliance pour que vCenter HA fonctionne.

  • Impossible de configurer vCenter HA depuis l'interface utilisateur de vSphere Web Client lorsqu'une adresse IP est utilisée au lieu d'un nom de domaine complet lors du déploiement
    Lorsque vous effectuez les étapes suivantes, une erreur se produit :

    1. Lors du déploiement de vCenter Server, dans la zone de texte Nom du système de l'interface utilisateur du déploiement, entrez une adresse IP au lieu d'un nom de domaine complet et procédez à l'installation.

    2. Une fois le déploiement effectué correctement, vous exécutez toutes les étapes requises pour configurer vCenter HA.

    3. La configuration de vCenter HA échoue dans l'interface utilisateur de vSphere Web Client avec le message d'erreur suivant :
      Les informations de Platform Services Controller ne peuvent pas être récupérées. Assurez-vous que le service de gestion des applications est en cours d'exécution et que vous faites partie d'un groupe d'administrateurs de configuration de système Single Sign-On. Les informations réseau du système d'exploitation invité relatives à la machine virtuelle vCenter ne peuvent pas être récupérées. Assurez-vous que le service de gestion des applications est en cours d'exécution.

    Solution : fournissez un nom de domaine complet dans le champ Nom du système lorsque vous déployez vCenter (et/ou PSC).

  • vSphere HA risque de ne pas parvenir à redémarrer des VM dépendantes et d'autres VM dans un niveau inférieur
    Actuellement, le temporisateur pour le remplacement des VM est démarré pour un placement des VM adéquat. S'il existe une dépendance entre des VM dans le même niveau et si le redémarrage d'une VM échoue, toutes les VM dépendantes et les VM dans un niveau inférieur ne peuvent pas être redémarrées. Toutefois, si des VM sont présentes dans différents niveaux sans dépendance à une VM dans le même niveau, le délai de temporisation du niveau est respecté et les VM dans un niveau inférieur basculent après la temporisation.

    Solution : ne créez pas de dépendances de VM dans le même niveau.

  • La création d'un cluster vSphere HA active VM Component Protection par défaut et les hôtes ESXi 5.5 ne peuvent pas être ajoutés au cluster
    La tentative d'ajouter un hôte ESXi 5.5 à un nouveau cluster vSphere HA ou l'activation de vSphere HA sur un cluster récemment créé ayant des hôtes ESXi 5.5 échoue du fait que VM Component Protection est activé par défaut. Le message d'erreur suivant s'affiche : Impossible d'activer vSphere HA VM Component Protection pour le cluster spécifié, car il contient un hôte avec « Mettre à niveau l'hôte vers la version 6.0 ou une version ultérieure ». Cela n'a pas d'incidence sur les hôtes ESXi 6.0 ou version ultérieure.

    Solution : accédez aux paramètres vSphere HA du cluster récemment créé. Dans l'onglet Pannes et réponses, vérifiez que les options Banque de données avec PDL et Banque de données avec APD sont définies sur Désactivé. Après avoir enregistré ces paramètres, vous pouvez ajouter les hôtes ESXi 5.5 au cluster.

  • Si un nœud actif redémarre au cours de la suppression d'une configuration de cluster vCenter HA, vous devrez peut-être démarrer ce nœud manuellement.
    La suppression d'une configuration de cluster vCenter HA est un processus en plusieurs étapes qui met à jour la configuration de vCenter Appliance. Vous devez marquer le dispositif afin qu'il démarre en tant que vCenter Server Appliance autonome. Si le dispositif actif se bloque ou redémarre au cours d'une opération clé de suppression de configuration de vCenter HA, le nœud actif peut redémarrer dans un mode où votre intervention est requise pour démarrer tous les services sur le dispositif.

    Solution : pour démarrer tous les services sur le dispositif actif, procédez comme suit :

    1. Connectez-vous à la console du dispositif vCenter Appliance actif.

    2. Activez l'interpréteur de commandes de dépistage sur l'invite du dispositif.

    3. Exécutez la commande : destroy-vcha -f

    4. Redémarrez le dispositif.

  • Si vous tentez de redémarrer un nœud actif au cours d'un basculement, il peut toujours être actif après le redémarrage.
    Dans un cluster vCenter HA, lorsqu'un nœud actif passe par un cycle de redémarrage, le nœud passif détecte l'indisponibilité temporaire du nœud actif dans le cluster vCenter HA. Par conséquent, il tente de se convertir en nœud actif. Si le nœud actif redémarre lorsque l'état d'un dispositif est modifié sur ce nœud, le basculement vers le nœud passif peut ne pas être effectué. Si cette situation se produit, le nœud actif continue en tant que nœud actif à l'issue du cycle de redémarrage.

    Solution : si vous redémarrez le nœud actif pour entraîner un basculement vers le nœud passif, vous devez suivre le workflow « Initier le basculement » à partir de l'interface utilisateur ou exécuter la commande Initiate Failover API. Cela permet de vous assurer que le nœud passif devient le nœud actif.

Auto Deploy et Image Builder
  • Impossible d'appliquer une clé SSH d'utilisateur racine à partir d'un profil d'hôte ESXi 6.0 sur ESXi 6.5
    Dans ESXi 6.5, la fonctionnalité de profil d'hôte des clés autorisées permettant de gérer les clés SSH d'utilisateur racine est désapprouvée. Cependant, la version 6.0 a été définie comme désapprouvée au lieu de la version 6.5. Par conséquent, vous ne pouvez pas appliquer la clé SSH d'utilisateur racine pour un profil d'hôte 6.0 sur un hôte utilisant la version 6.5.

    Solution : pour pouvoir utiliser un profil d'hôte et configurer la clé SSH pour l'utilisateur racine, vous devez créer un nouveau profil d'hôte 6.5.

  • L'application du profil d'hôte par redémarrage de l'hôte ESXi cible sans état entraîne l'affichage d'un message d'erreur de chemin de fichier non valide.
    Lorsque vous extrayez pour la première fois un profil d'hôte à partir d'un hôte sans état, modifiez-le pour créer un rôle comportant une entrée utilisateur pour la stratégie de mot de passe et sur lequel la mise en cache sans état est activée, puis attachez ce profil à l'hôte, mettez à jour le mot de passe de l'utilisateur et le rôle de la configuration, le redémarrage de l'hôte pour appliquer le profil d'hôte échoue avec le message suivant :

    ERROR: EngineModule::ApplyHostConfig. Exception: Chemin de fichier incorrect

    Solution : vous devez appliquer le profil d'hôte directement à l'hôte :

    1. Arrêtez le service Auto Deploy et redémarrez l'hôte.

    2. Après le démarrage de l'hôte, vérifiez que l'utilisateur local et le rôle sont présents sur l'hôte.

    3. Connectez-vous avec les informations d'identification fournies dans la configuration.

  • Échec du démarrage d'un hôte sans état à l'aide d'Auto Deploy
    Un délai d'environ 11 à 16 secondes se produit pour le traitement de la demande getnameinfo et entraîne l'échec du démarrage des hôtes sans état effectué via Auto Deploy lorsque les conditions suivantes sont remplies :

    • Une mise en cache DNS locale est activée pour un hôte sans état en ajoutant le paramètre resolve dans l'entrée des hôtes hosts: files resolve dns. L'entrée hosts: files resolve dns fait partie du fichier de configuration Photon /etc/nsswitch.conf.
    • Une carte réseau sur l'hôte obtient son adresse IP de DHCP et cette même adresse IP n'est pas présente sur le serveur DNS.

    Solution : dans le fichier de configuration de la carte réseau de vCenter Server, qui obtient l'adresse IP de DHCP, définissez la clé UseDNS sur false :

    [DHCP] UseDNS=false

  • Un hôte ESXi sans état peut rester en mode de maintenance lorsque vous le déployez à l'aide de vSphere Auto Deploy et que la propriété vSphere Distributed Switch est spécifiée dans le profil d'hôte
    Lorsque vous déployez un hôte ESXi sans état à l'aide de vSphere Auto Deploy et que la propriété vSphere Distributed Switch est spécifiée dans le profil d'hôte, l'hôte entre en mode de maintenance tandis que le profil d'hôte est appliqué. Si le processus échoue, le profil d'hôte risque de ne pas être appliqué et l'hôte risque de ne pas sortir du mode maintenance.

    Solution : sur la page du profil d'hôte, retirez manuellement l'hôte déployé du mode de maintenance et corrigez-le.

  • Le processus de correction nécessaire pour appliquer les paramètres du profil d'hôte sur le cluster iSCSI provoque une erreur dans vSphere Web Client
    Après avoir attaché un profil d'hôte extrait d'un hôte configuré avec un grand nombre de LUN à un cluster comprenant des hôtes iSCSI et après avoir corrigé ce cluster, le processus de correction déclenche le message d'erreur suivant dans l'interface de vSphere Web Client :

    L'opération d'application de profils d'hôtes a échoué. com.vmware.vim.vmomi.client.exception.TransportProtocolException:org.apache.http.client.ClientProtocolException
    L'erreur suivante peut également apparaître dans le fichier vpxd.log :
    2016-07-25T12:06:01.214Z error vpxd[7FF1FE8FB700] [Originator@6876 sub=SoapAdapter] length of HTTP request body exceeds configured maximum 20000000
    Lorsque vous corrigez un cluster, vSphere Web Client effectue une demande API avec des données pour tous les hôtes de ce cluster. Cette demande excède la taille maximale de la demande HTTP prise en charge par VPXD.

    Solution : procédez comme suit :

    1. Sélectionnez un nombre inférieur d'hôtes dans l'assistant de correction.

    2. Démarrez un autre assistant pour les hôtes restants uniquement lorsque la correction est terminée.

  • L'option Auto Deploy n'est pas présente dans vSphere Web Client après une mise à niveau ou une migration du système vCenter Server de la version 5.5 ou 6.0 vers la version 6.5
    Après avoir mis à niveau ou migré le système vCenter Server des versions 5.5 et 6.0 vers la version 6.5, l'option Auto Deploy n'est pas présente sur l'écran Configurer > Paramètres de vSphere Web Client. Le service vSphere Auto Deploy ainsi que le service Image Builder sont installés, mais ne sont pas démarrés automatiquement.

    Solution : procédez comme suit :

    1. Démarrez le service Image Builder manuellement.

    2. Déconnectez-vous et reconnectez-vous à vSphere Web Client

    3. Sur la page d'accueil de vSphere Web Client, accédez au système vCenter Server et sélectionnez Configurer > Paramètres pour rechercher le service Auto Deploy.

  • Si vous attachez plus de 63 hôtes à un profil d'hôte, la page de personnalisation de l'hôte se charge avec une erreur
    Si vous extrayez un profil d'hôte de l'hôte de référence et lui attachez plus de 63 hôtes, la charge du système vCenter Server devient lourde et la génération d'un fichier de réponse propre à un hôte peut dépasser la limite de 120 secondes. La page de personnalisation se charge avec une erreur :

    Le délai d'exécution de la requête a expiré, car le fournisseur de propriétés principal a nécessité plus de 120 secondes

    Solution : attachez le profil d'hôte au cluster ou à l'hôte sans générer les données de personnalisation :

    1. Cliquez avec le bouton droit sur le cluster ou l'hôte, et sélectionnez Profils d'hôte > Attacher un profil d'hôte.

    2. Sélectionnez le profil à attacher.

    3. Cochez la case Ignorer la personnalisation de l'hôte. L'interface de vSphere Web Client n'appelle pas RetrieveHostCustomizationsForProfile pour générer les données de personnalisation.

    4. Remplissez les données de personnalisation :

    5. Cliquez avec le bouton droit sur le profil d'hôte attaché au cluster ou à l'hôte, et sélectionnez Exporter les personnalisations de l'hôte. Un fichier CSV avec une entrée de personnalisation pour chaque hôte est ainsi généré.

    6. Remplissez les données de personnalisation dans le fichier CSV.

    7. Cliquez avec le bouton droit sur le profil d'hôte, sélectionnez Modifier les personnalisations de l'hôte et importez le fichier CSV.

    8. Cliquez sur Terminer pour enregistrer les données de personnalisation.

  • L'option Auto Deploy avec démarrage PXE du programme d'installation ESXi sur les cartes réseau Intel XL710 (40GB) provoque un échec
    Lorsque vous utilisez l'environnement PXE (Preboot Execution Environment) pour démarrer le programme d'installation ESXi à partir du périphérique réseau Intel XL710 sur un hôte, le processus de copie de l'image ESXi échoue avant que le contrôle soit transféré au noyau ESXi. L'erreur suivante s'affiche :

    Decompressed MD5: 000000000000000000000
    Fatal error : 34(Unexpected EOF)
    serial log:
    ******************************************************************
    * Booting through VMware AutoDeploy...
    *
    * Machine attributes:
    * . asset=
    * . domain=eng.vmware.com
    * . hostname=prme-hwe-drv-8-dhcp173
    * . ipv4=10.24.87.173
    * . ipv6=fe80::6a05:caff:fe2d:5608
    * . mac=68:05:ca:2d:56:08
    * . model=PowerEdge R730
    * . oemstring=Dell System
    * . oemstring=5[0000]
    * . oemstring=14[1]
    * . oemstring=17[04C4B7E08854C657]
    * . oemstring=17[5F90B9D0CECE3B5A]
    * . oemstring=18[0]
    * . oemstring=19[1]
    * . oemstring=19[1]
    * . serial=3XJRR52
    * . uuid=4c4c4544-0058-4a10-8052-b3c04f523532
    * . vendor=Dell Inc.
    *
    * Image Profile: ESXi-6.5.0-4067802-standard
    * VC Host: Aucun
    *
    * Bootloader VIB version: 6.5.0-0.0.4067802
    ******************************************************************
    /vmw/cache/d6/b46cc616433e9d62ab4d636bc7f749/mboot.c32.f70fd55f332c557878f1cf77edd9fbff... ok

    Scanning the local disk for cached image.
    If no image is found, the system will reboot in 20 seconds......
    <3>The system on the disk is not stateless cached.
    <3>Rebooting...

    Solution : aucune.

Problèmes divers
  • Le plug-in lsu-hpsa ne fonctionne pas avec le pilote hpsa natif (nhpsa)
    Le plug-in lsu-hpsa ne fonctionne pas avec le pilote hpsa natif (nhpsa), car le pilote nhpsa n'est pas compatible avec l'outil de gestion HPSA actuel (hpssacli), qui est utilisé par le plug-in lsu-hpsa. Les messages d'erreur suivants peuvent s'afficher :

    # esxcli storage core device set -d naa.600508b1001c7dce62f9307c0604e53b -l=locator
    Unable to set device's LED state to locator. Error was: HPSSACLI call in HPSAPlugin_SetLedState exited with code 127! (from lsu-hpsa-plugin)

    # esxcli storage core device physical get -d naa.50004cf211e636a7
    Plugin lsu-hpsa-plugin cannot get information for device with name naa.50004cf211e636a7. Error was: HPSSACLI call in Cache_Update exited with code 127!

    # esxcli storage core device raid list -d naa.600508b1001c7dce62f9307c0604e53b
    Plugin lsu-hpsa-plugin cannot get information for device with name naa.600508b1001c7dce62f9307c0604e53b. Error was: HPSSACLI call in Cache_Update exited with code 127!

    Solution : remplacez le pilote hpsa natif (nhpsa) par le pilote vmklinux.

Réduire la liste des problèmes détectés précédemment