vCenter Server 7.0 Update 1 | 6 octobre 2020 | Build ISO 16860138

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

  • Prise en charge de NSX-T 3.1.0 avec vSphere Lifecycle Manager : vCenter Server 7.0 Update 1 prend en charge NSX-T 3.1.0, ce qui permet d'intégrer NSX-T à l'aide d'images de cluster vSphere Lifecycle Manager. Pour plus d'informations, reportez-vous à la section vSphere Lifecycle Manager avec NSX-T du Guide d'installation de NSX-T Data Center.
  • Terminologie inclusive : dans vCenter Server 7.0 Update 1, dans le cadre d'un effort à l'échelle de l'entreprise de supprimer les instances de langage non inclusif dans nos produits, l'équipe vSphere a apporté des modifications à certains des termes utilisés dans vSphere Client. Les API et les interfaces de ligne de commande utilisent toujours des termes hérités, mais les mises à jour sont en attente d'une prochaine version.
  • Améliorations de l'accessibilité à vSphere : vCenter Server 7.0 Update 1 obtient d'importantes améliorations d'accessibilité apportées en fonction des recommandations du rapport de conformité d'accessibilité (ACR), qui est la norme acceptée à l'échelle internationale. Voici quelques-unes des améliorations de l'accessibilité à l'interface utilisateur :
    • Conformité de l'accessibilité de l'interface de gestion de vCenter Server Appliance
    • Conformité de l'accessibilité de l'interface utilisateur de gestion du stockage, telle que la banque de données et l'explorateur de fichiers
    • Capacités des plug-ins pour créer une interface utilisateur accessible, telle que la structure améliorée des écrans de dialogue
    • Amélioration de l'accessibilité des autres composants de l'interface utilisateur, comme la bibliothèque de contenu, la gestion des hôtes et des clusters, la configuration de machine virtuelle, les tâches, les événements et les alarmes, la gestion du réseau et la gestion de la charge de travail
  • Portail des idées vSphere : avec vCenter Server 7.0 Update 1, tout utilisateur disposant d'un compte my.vmware.com valide peut envoyer des demandes de fonctionnalités à l'aide du portail des idées vSphere. Toutes les idées publiées sont disponibles au vote et les plus populaires pourraient devenir des fonctionnalités vSphere. Vous pouvez accéder au portail des idées vSphere à l'adresse https://vsphere.ideas.aha.io/ ou à partir de l'onglet Idée sous la section Commentaires de vSphere Client. Lorsque vous vous connectez au portail des idées, vous êtes automatiquement redirigé vers la page de connexion my.vmware.com pour l'authentification utilisateur. Une fois que vous vous êtes connecté sur my.vmware.com, vous revenez à la session active dans le portail des idées vSphere. Lorsque vous vous déconnectez du portail des idées, vous êtes redirigé vers my.vmware.com pour fermer la session.
  • Amélioration des vérifications préalables de compatibilité matérielle de vSphere Lifecycle Manager pour les environnements vSAN : vCenter Server 7.0 Update 1 ajoute des vérifications préalables de compatibilité matérielle de vSphere Lifecycle Manager. Les vérifications préalables de la compatibilité matérielle de vSphere Lifecycle Manager qui se déclenchent automatiquement après certains événements de modification, comme le changement de l'image souhaitée du cluster ou l'ajout d'un nouvel hôte ESXi dans les environnements vSAN. En outre, l'infrastructure de compatibilité matérielle interroge automatiquement la base de données de la liste de compatibilité matérielle à des intervalles prédéfinis pour les modifications qui déclenchent des vérifications préalables si nécessaire.
  • Augmentation de l'évolutivité avec vSphere Lifecycle Manager : avec vCenter Server 7.0 Update 1, l'évolutivité des opérations vSphere Lifecycle Manager avec des hôtes et des clusters ESXi a augmenté comme suit :
    • De 15 à 64 clusters pris en charge
    • De 64 à 96 hôtes ESXi pris en charge dans un cluster. Pour les environnements vSAN, la limite est toujours de 64
    • De 150 à 280 hôtes ESXi gérés par une image de Lifecycle Manager vSphere
    • De 15 à 64 clusters sur lesquels vous pouvez exécuter la correction en parallèle, si vous lancez la correction au niveau d'un centre de données.
  • Prise en charge de vSphere Lifecycle Manager pour les mises à niveau coordonnées entre les zones de disponibilité : Avec vCenter Server 7.0 Update 1, pour empêcher le chevauchement des opérations, vSphere Lifecycle Manager met à jour les domaines de pannes dans les clusters vSAN de manière séquentielle. Les hôtes ESXi dans chaque domaine de pannes sont toujours mis à jour de manière linéaire. Pour les clusters étendus vSAN, le premier domaine de pannes est toujours le site préféré.
  • Liste étendue des versions de Red Hat Enterprise Linux et d'Ubuntu prises en charge pour VMware vSphere Update Manager Download Service (UMDS) : vCenter Server 7.0 Update 1 ajoute de nouvelles versions de Red Hat Enterprise Linux et d'Ubuntu qu'UMDS prend en charge. Pour obtenir la liste complète des versions prises en charge, reportez-vous à la section Systèmes d'exploitation Linux pris en charge pour l'installation d'UMDS.
  • Bouton Ignorer les alertes dans VMware Skyline Health : avec vCenter Server 7.0 Update 1, vous pouvez arrêter les alertes pour certains contrôles de santé, comme les notifications de problèmes connus, à l'aide du bouton Ignorer les alertes. Par exemple, si vous ne souhaitez pas recevoir de notifications de certains des contrôles de santé de calcul, accédez à Skyline Health > Contrôles de santé de calcul > nom du contrôle de Santé, puis cliquez sur le bouton Ignorer les alertes. Dans la fenêtre contextuelle, sélectionnez OUI pour désactiver les notifications. Utilisez le bouton Restaurer l'alerte pour réactiver les alertes.
  • Configurer l'authentification SMTP : vCenter Server 7.0 Update 1 ajoute la prise en charge de l'authentification SMTP dans vCenter Server Appliance pour permettre l'envoi d'alertes et d'alarmes par e-mail en mode sécurisé. Vous pouvez choisir d'envoyer des alertes par e-mail de manière anonyme et authentifiée. Pour configurer l'authentification SMTP, reportez-vous à la section Configurer les paramètres de l'expéditeur d'e-mail.
  • Machines virtuelles système pour les services de cluster vSphere : Dans vCenter Server 7.0 Update 1, la fonctionnalité de services de cluster vSphere ajoute un ensemble de machines virtuelles système dans chaque cluster vSphere pour garantir le bon fonctionnement de VMware vSphere Distributed Resource Scheduler. Pour plus d'informations, reportez-vous aux articles 80472, 79892 et 80483 de la base de connaissances VMware.
  • Attribution de licences pour VMware Tanzu Basic : Avec vCenter Server 7.0 Update 1, l'attribution des licences pour VMware Tanzu Basic couvre plusieurs clés de licence pour vSphere 7 Enterprise Plus et VMware Tanzu Basic. Dans vCenter Server 7.0 Update 1, vous devez fournir une clé de licence vSphere 7 Enterprise Plus ou une clé de licence vSphere 7 Enterprise Plus avec un module complémentaire pour la clé de licence Kubernetes afin d'activer la fonctionnalité Enterprise Plus pour les hôtes ESXi. En outre, vous devez fournir une clé de licence VMware Tanzu Basic pour activer la fonctionnalité Kubernetes pour tous les hôtes ESXi que vous souhaitez utiliser dans le cadre d'un cluster superviseur.
    Lorsque vous mettez à niveau un déploiement 7.0 vers 7.0 Update 1, les clusters superviseurs existants démarrent automatiquement un mode d'évaluation de 60 jours. Si vous n'installez pas une clé de licence VMware Tanzu Basic et que vous ne l'attribuez pas à des clusters superviseurs existants dans les 60 jours, vous pouvez voir certaines limitations dans la fonctionnalité Kubernetes. Pour en savoir plus, consultez l'article Licensing for vSphere with Tanzu et l'article de la base de connaissances VMware 80868.

Versions précédentes de vCenter Server 7.0

Les fonctionnalités et les problèmes résolus et 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 7.0 :

Pour plus d'informations sur l'internationalisation, la compatibilité et les composants open source, consultez les Notes de mise à jour de VMware vSphere 7.0.

Correctifs contenus dans cette version

Cette version de vCenter Server 7.0 Update 1 fournit le correctif suivant. Pour plus d'informations sur le téléchargement des correctifs, consultez le Centre de téléchargement des correctifs de VMware.

Correctif pour VMware vCenter Server Appliance 7.0 Update 1

Correctif de produit pour vCenter Server contenant des correctifs logiciels et de sécurité VMware, ainsi que des correctifs de produits tiers.

Ce correctif s'applique à vCenter Server.

Nom de fichier de téléchargement VMware-vCenter-Server-Appliance-7.0.1.00000-16860138-patch-FP.iso
Build 16860138
Taille du téléchargement 5 902,8 Mo
md5sum 30975695fcc1d4b1c169ffa7132a77f5
sha1checksum d5ecb95189e40657be1fb9b0871824b501041f18

Téléchargement et installation

Vous pouvez télécharger ce correctif en accédant au Centre de téléchargement des correctifs de VMware et en sélectionnant VC dans le menu déroulant Sélectionner un produit.

  1. Attachez le fichier VMware-vCenter-Server-Appliance-7.0.1.00000-16860138-patch-FP.iso au lecteur de CD ou de DVD de vCenter Server.
  2. Connectez-vous à l'interpréteur de commandes du dispositif en tant qu'utilisateur disposant de privilèges de super administrateur (par exemple, racine) et exécutez les commandes suivantes :
    • Pour transférer l'image ISO :
      software-packages stage --iso
    • Pour voir le contenu transféré :
      software-packages list --staged
    • Pour installer les RPM transférés :
      software-packages install --staged

Pour plus d'informations sur l'utilisation des interpréteurs de commandes vCenter Server, consultez l'article 2100508 de la base de connaissances VMware.

Pour plus d'informations sur l'application de correctifs sur vCenter Server, consultez Correction de vCenter Server Appliance.

Pour plus d'informations sur le transfert de correctifs, consultez Transférer les correctifs vers vCenter Server Appliance.

Pour plus d'informations sur l'installation de correctifs, consultez Installation de correctifs vCenter Server Appliance.

Pour plus d'informations sur l'application de correctifs à l'aide de l'interface de gestion des dispositifs, consultez la section Correction de vCenter Server à l'aide de l'interface de gestion de dispositifs.

Notes d'installation et de mise à niveau pour cette version

Avant d'effectuer la mise à niveau vers vCenter Server 7.0 Update 1, vous devez confirmer que le mode LACP (Link Aggregation Control Protocol) est défini sur enhanced, qui active le protocole de contrôle d'agrégation de liaisons multiples (paramètre multipleLag) sur VMware vSphere Distributed Switch (VDS) dans votre système vCenter Server.

Si le mode LACP est défini sur basic, indiquant le protocole de contrôle d'agrégation d'une liaison unique (singleLag), les groupes de ports virtuels distribués sur vSphere Distributed Switch peuvent perdre la connexion après la mise à niveau et affecte la vmknic de gestion, s'il se trouve sur l'un des ports dvPort. Lors de la vérification préalable de la mise à niveau, une erreur similaire au message suivant s'affiche : La source vCenter Server contient une ou plusieurs instances de Distributed Virtual Switch avec une version lacpApiVersion non prise en charge.
Pour plus d'informations sur la conversion vers la prise en charge étendue du protocole LACP sur un dispositif vSphere Distributed Switch, reportez-vous à l'article de la base de connaissances VMware 2051311. Pour en savoir plus sur les limitations du protocole LACP dans vSphere, consultez l'article de la base de connaissance VMware 2051307.

Remarques relatives à la prise en charge du produit

  • Désapprobation future de SHA-1
    l'algorithme de hachage de chiffrement SHA-1 sera déconseillé dans une future version de vSphere. SHA-1 et l'algorithme MD5 déjà déconseillé ont des faiblesses connues et ont fait l'objet d'attaques pratiques.
  • vCenter Server 7.0 Update 1 ne prend pas en charge VMware Site Recovery Manager 8.3.1.
  • Désapprobation de la version 1.0 du protocole SMB (Server Message Block)
    La sauvegarde et la restauration basées sur des fichiers de vCenter Server à l'aide du protocole SMB (Server Message Block) version 1.0 sont obsolètes dans vCenter Server 7.0 Update 1. La suppression de SMBv.1 doit se produire dans une future version de vSphere.
  • Fin de la prise en charge générale de VMware Tools 9.10.x et 10.0.x
    VMware Tools 9.10.x et 10.0.x ont atteint la fin du support général. Pour plus d'informations, reportez-vous aux outils VMware Tools répertoriés sous Matrice de cycle de vie des produits VMware.
  • Désapprobation de VMware Service Lifecycle Manager API 
    VMware prévoit de déconseiller VMware Service Lifecycle Manager API (service vmonapi) dans une version ultérieure. Pour plus d'informations, reportez-vous à l'article 80775 de la base de connaissances VMware.
  • Fin de la prise en charge d'Internet Explorer 11
    La suppression d'Internet Explorer 11 de la liste de navigateurs pris en charge pour vSphere Client aura lieu dans une future version de vSphere.
  • VMware Host Client en mode de maintenance 
    VMware Host Client est en mode de maintenance jusqu'à la publication d'un nouveau client.

Problèmes résolus

Les problèmes résolus sont regroupés comme suit :

Problèmes de sauvegarde et de restauration
  • NOUVEAU : Si SSH est désactivé sur un système vCenter Server, les opérations de restauration basée sur des fichiers peuvent échouer

    Si une sauvegarde basée sur des fichiers d'un système vCenter Server est effectuée alors que SSH est désactivé, l'opération de restauration à partir de cette sauvegarde peut échouer au redémarrage du service SSH après la restauration. Dans vSphere Client, le message suivant peut s'afficher : ERREUR : Échec du redémarrage de sshd.service : L'unité sshd.service est masquée.

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

Problèmes liés à vSphere Lifecycle Manager
  • Lors de la correction d'un cluster sur lequel vSphere HA est activé dans vSphere Lifecycle Manager, l'ajout d'hôtes provoque un état d'erreur de vSphere HA

    L'ajout d'un ou de plusieurs hôtes ESXi lors d'un processus de correction d'un cluster activé pour vSphere HA génère le message d'erreur suivant : Une erreur s'est produite lors de l'application de VIB HA sur le cluster.

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

  • L'importation d'une image sans complément fournisseur, composant ou complément de microprogramme et de pilotes dans un cluster sur lequel l'image contient ces éléments ne supprime pas les éléments d'image de l'image existante.

    Seule l'image de base ESXi est remplacée par celle de l'image importée.

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

  • Les hôtes ESXi 7.0 ne peuvent pas être ajoutés à un cluster que vous gérez avec une seule image à l'aide de vSphere Auto Deploy.

    La tentative d'ajouter des hôtes ESXi à un cluster que vous gérez avec une seule image à l'aide du workflow Ajouter à l'inventaire dans vSphere Auto Deploy échoue. L'échec se produit, car aucun modèle ne correspond à un ensemble de règles Auto Deploy existant. La tâche échoue en silence et les hôtes restent dans l'onglet Hôtes découverts.

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

Problèmes vCenter Server et vSphere Client
  • Les instances de vCenter Server SDDC (Software-Defined Data Center) s'affichent dans l'instance sur site de vSphere Client si une instance de vCenter Cloud Gateway est liée au SDDC.

    Lorsqu'une instance de vCenter Cloud Gateway est déployée dans le même environnement qu'une instance sur site de vCenter Server, et est liée à un SDDC, l'instance de vCenter Server SDDC s'affiche dans l'instance sur site de vSphere Client. Ce comportement est inattendu et l'instance liée de vCenter Server SDDC doit être ignorée. Toutes les opérations impliquant l'instance liée de vCenter Server SDDC doivent être effectuées sur vSphere Client exécuté dans vCenter Cloud Gateway.

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

Problèmes de sécurité
  • Mise à jour vers la base de données SQLite

    La base de données SQLite est mise à jour vers la version 3.32.2.

    • Mise à jour du serveur Apache Tomcat

      Le serveur Apache Tomcat a été mis à jour vers la version 8.5.55/9.0.35.

    • Mise à jour vers cURL

      cURL dans vCenter Server a été mis à jour vers la version 7.70.0.

    • Mise à jour vers VMware PostgreSQL

      VMware PostgreSQL a été mis à jour vers la version 11.8.

    • Mise à jour d'OpenJDK 1.8.0.252

      JDK open source a été mis à jour vers la version 1.8.0.252.

    • Mise à jour du module Jackson

      Le module Jackson a été mis à jour vers la version 2.10.3.

    • Mise à niveau d'Eclipse Jetty

      Eclipse Jetty est mis à niveau vers la version 9.4.28.

    • Mise à jour du framework Spring

      Framework Spring a été mis à jour vers la version 4.3.27/5.2.5.

Problèmes de stockage
  • Les tentatives d'attachement de plusieurs volumes de stockage cloud natif au même espace peuvent parfois échouer avec une erreur

    Lorsque vous attachez plusieurs volumes simultanément au même espace, l'opération d'attachement peut éventuellement choisir le même emplacement de contrôleur. Par conséquent, une seule des opérations réussit, alors que d'autres montages de volume échouent.

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

  • NOUVEAU : un problème de mémoire de segment dans les banques de données VMFS6 entraîne différents problèmes avec les machines virtuelles

    Dans certains workflows, les banques de données VMFS6 peuvent allouer de la mémoire, mais ne pas la libérer, ce qui entraîne l'épuisement de la mémoire du segment VMFS. Cela peut entraîner les problèmes suivants :

    • Les banques de données VMFS6 sont affichées comme « Non consommé » sur les hôtes ESXi.
    • Les opérations vSphere vMotion avec des machines virtuelles échouent.
    • Les machines virtuelles deviennent inactives lorsqu'elles sont hors tension.
    • Les sauvegardes basées sur un snapshot échouent.
    • La création ou la consolidation de snapshots dans le système vCenter Server ou l'hôte ESXi échoue avec une erreur telle que :
      Échec de la consolidation pour le nœud de disque « scsi0:1 » : 12 (Impossible d'allouer de la mémoire).

    Dans les fichiers vmkwarning.*, vous voyez des erreurs telles que :
    vmkwarning.0:2020-06-16T13:28:23.291Z cpu48:3479102)WARNING: Heap: 3651: Le segment de mémoire VMFS vmfs3 a déjà atteint sa taille maximale. Cannot expand.

    Dans les journaux vmkernel.*, vous voyez des erreurs telles que :
    2020-06-29T14:59:36.351Z cpu21:5630454)WARNING: HBX: 2439: Failed to initialize VMFS distributed locking on volume 5eb9e8f1-f4aeef84-4256-1c34da50d370: Out of memory
    020-06-29T14:59:36.351Z cpu21:5630454)Vol3: 4202: Failed to get object 28 type 1 uuid 5eb9e8f1-f4aeef84-4256-1c34da50d370 FD 0 gen 0 :Out of memory
    2020-06-29T14:59:36.351Z cpu21:5630454)Vol3: 4202: Failed to get object 28 type 2 uuid 5eb9e8f1-f4aeef84-4256-1c34da50d370 FD 4 gen 1 :Out of memory
    2020-06-29T14:59:36.356Z cpu21:5630454)WARNING: HBX: 2439: Failed to initialize VMFS distributed locking on volume 5eb9e8f1-f4aeef84-4256-1c34da50d370: Out of memory
    2020-06-29T14:59:36.356Z cpu21:5630454)Vol3: 4202: Failed to get object 28 type 1 uuid 5eb9e8f1-f4aeef84-4256-1c34da50d370 FD 0 gen 0 :Out of memory
    2020-06-29T14:59:36.356Z cpu21:5630454)Vol3: 4202: Failed to get object 28 type 2 uuid 5eb9e8f1-f4aeef84-4256-1c34da50d370 FD 4 gen 1 :Out of memory

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

Problèmes d'installation, de mise à niveau et de migration
  • Échec de la génération d'un rapport d'interopérabilité pour vCenter Server 7.0 Update 1 avec une erreur

    Dans vSphere Client, lorsque vous accédez à Mises à jour > Planificateur de mise à jour et que vous sélectionnez 7.0.1 comme instance de vCenter Server cible pour générer un rapport d'interopérabilité, l'erreur suivante s'affiche :
    La version du produit cible fournie n'est pas valide. Indiquez une version valide pour le produit cible.

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

Problèmes connus

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

Problèmes de gestion des machines virtuelles
  • Vous ne pouvez pas ajouter ou modifier un adaptateur réseau existant sur une machine virtuelle

    Si vous tentez d'ajouter ou de modifier un adaptateur réseau existant sur une machine virtuelle, la tâche de reconfiguration de la machine virtuelle peut échouer avec une erreur telle que Impossible de terminer l'opération en raison d'une modification simultanée par une autre opération dans vSphere Client. Le fichier /var/log/hostd.log de l'hôte ESXi sur lequel la machine virtuelle s'exécute comporte des journaux tels que :
    2020-07-28T07:47:31.621Z verbose hostd[2102259] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/vsan:526bc94351cf8f42-41153841cab2f9d9/bad71f5f-d85e-a276-4cf6-246e965d7154/interop_l2vpn_vmotion_VM_1.vmx] NIC: connection control message: Failed to connect virtual device 'ethernet0'.
    Le fichier vpxa.log comporte des entrées telles que : 2020-07-28T07:47:31.941Z info vpxa[2101759] [Originator@6876 sub=Default opID=opId-59f15-19829-91-01-ed] [VpxLRO] -- ERROR task-138 -- vm-13 -- vim.VirtualMachine.reconfigure: vim.fault.GenericVmConfigFault: 

    Solution : pour chaque hôte ESXi dans votre cluster, procédez comme suit :

    1. Connectez-vous à l'hôte ESXi à l'aide de SSH et exécutez la commande
      esxcli system module parameters set -a -p dvfiltersMaxFilters=8192 -m dvfilter
    2. Mettez l'hôte ESXi en mode de maintenance.
    3. Redémarrez l'hôte ESXi.

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

  • Les hôtes ESXi 6.5 avec des processeurs AMD Opteron Generation 3 (Greyhound) ne peuvent pas joindre les clusters EVC (Enhanced vMotion Compatibility) AMD REV E ou AMD REV F sur un système vCenter Server 7.0 Update 1

    Dans vCenter Server 7.0 Update 1, les services de cluster vSphere, tels que vSphere DRS et vSphere HA, s'exécutent sur des machines virtuelles d'agent ESX pour rendre les services fonctionnellement indépendants de vCenter Server. Toutefois, la ligne de base de CPU pour les processeurs AMD des machines virtuelles d'agent ESX a des instructions POPCNT SSE4A, ce qui empêche les hôtes ESXi 6.5 avec des processeurs AMD Opteron Generation 3 (Greyhound) d'activer le mode EVC AMD REV E et AMD REV F sur un système vCenter Server 7.0 Update 1.

    Solution : aucune.

Problèmes d'installation, de mise à niveau et de migration
  • La mise à niveau vers le correctif vCenter Server 7.0 Update 1 à partir des versions antérieures de vCenter Server 7.x est bloquée lorsque vCenter Server High Availability est activé

    La mise à niveau vers le correctif vCenter Server 7.0 Update 1 à partir des versions antérieures de vCenter Server 7.x est bloquée lorsque vCenter Server High Availability est actif.

    Solution : pour mettre à niveau votre système vers vCenter Server 7.0 Update 1 à partir de versions antérieures de vCenter Server 7.x, vous devez supprimer vCenter Server High Availability et supprimer les nœuds passif et témoin. Après la mise à niveau, vous devez recréer les clusters vCenter Server High Availability.

  • La migration d'un système vCenter Server 6.7.x vers vCenter Server 7.x échoue avec un message UnicodeEncodeError

    Si vous sélectionnez l'option permettant d'importer toutes les données pour la configuration, l'inventaire, les tâches, les événements et les mesures de performance, la migration d'un système vCenter Server 6.7.x vers vCenter Server 7.x peut échouer pour tout système vCenter Server utilisant des paramètres régionaux non anglais. À l'étape 1 de la phase 2 de la migration, dans vSphere Client, vous voyez une erreur telle que :
    Erreur lors de l'exportation des données d'événements et de tâches : …ERROR UnicodeEncodeError: Traceback (most recent call last):

    Solution : vous pouvez terminer l'opération de migration en effectuant l'une des opérations suivantes :

    • Sélectionnez l'option par défaut Configuration et inventaire à la fin de l'étape 1 de la migration.
      Cette option n'inclut pas les données de tâches et d'événements.
    • Nettoyez les données dans les tables d'événements et réexécutez la migration.
  • Si un système vCenter Server Windows dispose d'un mot de passe de base de données contenant des caractères non-ASCII, les vérifications préalables de l'assistant de migration VMware échouent

    Si vous essayez de migrer un système vCenter Server 6.x vers vCenter Server 7.x à l'aide de l'assistant de migration VMware, et si votre système dispose d'un système d'exploitation Windows et utilise une base de données externe avec un mot de passe contenant des caractères non-ASCII, l'opération échoue. Par exemple, Admin!23迁移. Dans la console de l'assistant de migration, le message d'erreur suivant s'affiche :

    Erreur : le composant com.vmware.vcdb a échoué avec une erreur interne
    Résolution : mise à niveau du fichier Bugzilla PR vers VPX/VPX/vcdb

    Solution : aucune.

  • Lors d'une mise à jour de vCenter Server 7.x vers vCenter Server 7.0 Update 1, des messages vous invitent à fournir le mot de passe vCenter Single Sign-On

    Lors d'une mise à jour de vCenter Server 7.x vers vCenter Server 7.0 Update 1, des messages vous invitent à fournir le mot de passe d'administrateur vCenter Single Sign-On.

    Solution : si vous exécutez la mise à jour à l'aide de l'interface de gestion de vCenter Server, vous devez fournir le mot de passe de l'administrateur vCenter Single Sign-On.
    Si vous exécutez la mise à jour à l'aide de modules logiciels ou d'une interface de ligne de commande de manière interactive, vous devez fournir de manière interactive le mot de passe de l'administrateur vCenter Single Sign-On.
    Si vous exécutez la mise à jour à l'aide de modules logiciels ou d'une interface de ligne de commande en mode non interactif, vous devez fournir le mot de passe de l'administrateur de vCenter Single Sign-On par un fichier de réponses au format
    { "vmdir.password": "Mot de passe SSO de l'utilisateur Administrateur@<DOMAINE SSO> " }

  • Il est possible que vous ne puissiez pas appliquer ou supprimer NSX lorsque vous ajoutez des hôtes ESXi à l'aide d'une image de vSphere Lifecycle Manager à un cluster dans lequel VMware vSphere High Availability est activé

    Si vous démarrez une opération pour appliquer ou supprimer NSX lors de l'ajout de plusieurs hôtes ESXi à l'aide d'une image de vSphere Lifecycle Manager à un cluster dans lequel vSphere HA est activé, les opérations liées à NSX peuvent échouer avec une erreur dans vSphere Client, telle que :
    L'agent vSphere HA sur certains hôtes du cluster <nom_cluster> n'est pas l'agent principal vSphere HA et n'est pas non plus connecté à l'agent principal vSphere HA. Vérifiez que la configuration de HA est bonne.
    Ce problème se produit, car vSphere Lifecycle Manager configure vSphere HA pour les hôtes ESXi ajoutés au cluster un par un. Si vous exécutez une opération pour appliquer ou supprimer NSX tandis que des opérations de configuration de vSphere HA sont toujours en cours, il est possible que les opérations NSX soient mises en attente entre les opérations de configuration de vSphere HA pour deux hôtes ESXi différents. Dans ce cas, l'opération NSX échoue avec une erreur de contrôle de santé du cluster, car l'état du cluster à ce stade ne correspond pas à l'état attendu de tous les hôtes ESXi sur lesquels vSphere HA est configuré et s'exécute. Plus vous ajoutez d'hôtes ESXi à un cluster en même temps, plus la probabilité que le problème se produise augmente.

    Solution : désactivez, puis activez vSphere HA sur le cluster. Poursuivez les opérations pour appliquer ou supprimer NSX.

  • Après une mise à niveau d'un système vCenter Server 7.0, vous ne pouvez pas voir les adresses IP des espaces dans l'onglet Résumé de l'espace vSphere de vSphere Client

    Si vous mettez à niveau votre système vCenter Server 7.0 vers une version ultérieure, vous ne pouvez plus voir les adresses IP des espaces dans l'onglet Résumé de l'espace vSphere de vSphere Client.

    Solution : utilisez les outils de l'interface de ligne de commande Kubernetes pour vSphere afin de vérifier les détails des espaces :

    1. Copiez, comme condition préalable, les noms de l'espace et de l'espace de noms. 
      • Dans vSphere Client, accédez à Gestion de la charge de travail > Clusters.
      • Copiez l'adresse IP affichée dans l'onglet Adresse IP du nœud de plan de contrôle.
      • Vous pouvez accéder à https://<control_plane_node_IP_address> et téléchargez les outils de l'interface de ligne de commande Kubernetes, kubectl et kubectl-vsphere.
        Vous pouvez également suivre les étapes décrites dans Télécharger et installer les outils de l'interface de ligne de commande Kubernetes pour vSphere.
    2. Utilisez le plug-in de l'interface de ligne de commande pour vSphere pour vérifier les détails de l'espace.
      1. Connectez-vous au cluster superviseur à l'aide de la commande
        kubectl vsphere login --server=https://<adresse_serveur> --vsphere-username <votre nom de compte d'utilisateur> --insecure-skip-tls-verify
      2. En utilisant les noms copiés à l'étape 1, exécutez les commandes pour récupérer les détails de l'espace :
        kubectl config use-context <nom_espace de noms> 
        et
        kubectl describe pod <nom_espace> -n <nom_espace de noms> 

    Par conséquent, vous pouvez voir l'adresse IP dans une sortie semblable à celle-ci :

    $ kubectl describe pod helloworld -n my-podvm-ns ...
    Statut : En cours d'exécution
    Adresse IP : 10.0.0.10
    Adresses IP :
     Adresse IP : 10.0.0.10 ...

  • Le déploiement d'un dispositif vCenter Server Appliance à l'aide du port 5480 à l'étape 2 échoue avec l'erreur Impossible d'enregistrer les paramètres IP

    Si vous utilisez https://appliance-IP-address-or-FQDN:5480 dans un navigateur Web, accédez à l'interface de gestion de vCenter Server Appliance pour l'étape 2 d'un dispositif vCenter Server Appliance récemment déployé, et que vous configurez une adresse IP statique ou que essayez de modifier la configuration IP, vous voyez une erreur de ce type
    Impossible d'enregistrer les paramètres IP.

    Solution : aucune.

Problèmes de sauvegarde et de restauration
  • Si vous utilisez les protocoles NFS et SMB pour la sauvegarde basée sur des fichiers de vCenter Server, la sauvegarde échoue après une mise à jour de vCenter Server 7.x vers vCenter Server 7.0 Update 1

    Si vous utilisez les protocoles NFS (Network File System) et SMB (Server Message Block) pour la sauvegarde basée sur des fichiers de vCenter Server, la sauvegarde échoue après une mise à jour d'une version antérieure de vCenter Server 7.x vers vCenter Server 7.0 Update 1. Dans le fichier applmgmt.log, vous voyez un message d'erreur tel que Échec du montage du stockage à distance. Ce problème se produit en raison des mises à jour du noyau Linux qui s'exécutent pendant le processus de correction. Ce problème ne se produit pas lors de nouvelles installations de vCenter Server 7.0 Update 1.

    Solution : redémarrez vCenter Server Appliance une fois la mise à jour terminée.

Problèmes liés à vSphere Lifecycle Manager
  • Si vous utilisez un client Java pour vérifier les tâches de correction, vous ne pouvez pas extraire les résultats des opérations de correction

    Si vous utilisez un client Java pour vérifier les tâches de correction, l'extraction des résultats peut échouer avec une erreur ConstraintValidationException. Ce problème se produit lorsqu'un hôte ESXi ne parvient pas à passer en mode de maintenance lors de la correction et qu'il obtient un état IGNORÉ, mais qu'il obtient en même temps un indicateur de progression pour les opérations de correction consécutives. Cela provoque l'erreur ConstraintValidationException sur les clients Java, et vous ne pouvez pas extraire le résultat de l'opération de correction.

    Solution : corrigez les problèmes sous-jacents qui empêchent les hôtes ESXi d'entrer en mode de maintenance et relancez l'opération de correction.

  • NOUVEAU : échec de l'utilisation d'Auto Deploy pour provisionner des hôtes ESXi à l'aide d'une image de vSphere Lifecycle Manager sur un cluster avec NSX-T activé

    Si vous utilisez Auto Deploy pour provisionner des hôtes ESXi sur un cluster avec NSX-T configuré à l'aide d'une image de vSphere Lifecycle Manager, vous pouvez rencontrer l'un des problèmes suivants :
    L'hôte ESXi ne parvient pas à joindre l'instance de vSphere Distributed Switch (VDS) configurée dans NSX-T dans le cadre de la configuration du profil de nœud de transport.
    L'hôte ESXi reste en mode de maintenance après avoir été ajouté au système vCenter Server ou l'hôte ESXi ne parvient pas à rejoindre le système vCenter Server.
    Dans vSphere Client, vous voyez un message d'erreur semblable au message suivant :
    Impossible d'ajouter l'hôte au cluster. Un hôte sans état ne peut pas être ajouté à des clusters à l'aide d'une image unique pour gérer les hôtes

    Le fichier syslog.log du dossier var/log/ sur les hôtes ESXi affectés contient une trace de débogage semblable à la trace suivante :

    ~~~2020-07-24T10:58:46Z Host Profiles[1000350314 opID=MainThread]: INFO: Successfully initialized privilege list.
    2020-07-24T10:58:46Z HostProfileManager:
    2020-07-24 10:58:46,481 [MainProcess INFO 'root' MainThread] Starting CGI server on stdin/stdout
    2020-07-24T10:58:46Z Host Profiles[1000350314 opID=28ea1be8-05-84-1da1]: INFO: Calling QueryState()
    2020-07-24T10:58:46Z Host Profiles[1000350314 opID=28ea1be8-05-84-1da1]: INFO: State = (vmodl.KeyAnyValue) [ (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'NSX_INSTALL_OPAQUE_SWITCH_STATUS', value = (str) [ 'OpaqueSwitchProfile' ] }, (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'REAPPLY_REQUIRED', value = (str) [ 'DvsProfile' ] }, (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'NSX_DVS_CONFIG_REQUIRED', value = (str) [ 'DvsProfile' ] } ]
    2020-07-24T10:58:46Z Host Profiles[1000350314 opID=28ea1be8-05-84-1da1]: INFO: Cleaned up Host Configuration
    2020-07-24T10:58:46Z Host Profiles[1000350314 opID=28ea1be8-05-84-1da1]: INFO: Returning Host Profile Manager state: (vmodl.KeyAnyValue) [ (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'NSX_INSTALL_OPAQUE_SWITCH_STATUS', value = (str) [ 'OpaqueSwitchProfile' ] }, (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'REAPPLY_REQUIRED', value = (str) [ 'DvsProfile' ] }, (vmodl.KeyAnyValue) { dynamicType = , dynamicProperty = (vmodl.DynamicProperty) [], key = 'NSX_DVS_CONFIG_REQUIRED', value = (str) [ 'DvsProfile' ] } ]
    Ce problème se produit en raison de certaines limitations lorsque vSphere Lifecycle Manager est activé sur un cluster. Par exemple, en cas de suppression des VIB NSX-T du nœud de transport lorsqu'un administrateur corrige un hôte ESXi.

    Solution : suivez les instructions de l'article 80697 de la base de connaissances VMware.

  • Le dépôt vSphere général Lifecycle Manager général et les dépôts locaux dans les déploiements de bureaux distants et de succursales (ROBO) peuvent ne pas être synchronisés

    Les clusters ROBO disposant d'un accès limité ou sans accès à Internet ou d'une connectivité limitée à vCenter Server peuvent télécharger une image à partir d'un dépôt local pour eux au lieu d'accéder au dépôt vSphere Lifecycle Manager dans vCenter Server. Toutefois, vSphere Lifecycle Manager génère des recommandations logicielles sous la forme d'images pré-validées uniquement à un niveau central et un contenu d'image recommandé peut ne pas être disponible lors d'un remplacement de dépôt.

    Solution : si vous décidez d'utiliser une image recommandée, assurez-vous que le contenu entre les remplacements de dépôts et le dépôt central est synchronisé.

  • La correction de cluster à l'aide de vSphere Lifecycle Manager peut échouer sur les hôtes ESXi avec le mode de verrouillage activé

    Si un cluster inclut des hôtes ESXi pour lesquels le mode de verrouillage est activé, il se peut que les opérations de correction à l'aide de vSphere Lifecycle Manager ignorent ces hôtes. Dans les fichiers journaux, des erreurs semblables aux messages suivants s'affichent : Host scan task failed et com.vmware.vcIntegrity.lifecycle.EsxImage.UnknownError An unknown error occurred while performing the operation..

    Solution : Ajoutez l'utilisateur racine à la liste d'exceptions pour le mode de verrouillage et procédez à une nouvelle tentative de correction du cluster.

Problèmes de mise en réseau
  • Si vous essayez de désactiver vSphere with Tanzu sur un cluster vSphere, l'opération s'arrête et affiche une erreur.

    Si certaines machines virtuelles situées à l'extérieur d'un cluster superviseur résident sur l'un des groupes de ports de segment NSX sur le cluster, le script de nettoyage ne peut pas supprimer ces ports ni désactiver vSphere with Tanzu sur le cluster. Dans vSphere Client, vous voyez l'erreur Les demandes de nettoyage envoyées à NSX Manager ont échoué, et l'opération s'arrête à l'état Suppression. Dans le fichier /var/log/vmware/wcp/wcpsvc.log, vous voyez un message d'erreur tel que
    Segment path=[...] has x VMs or VIFs attached. Disconnect all VMs and VIFs before deleting a segment.

    Solution : supprimez les machines virtuelles indiquées dans le fichier /var/log/vmware/wcp/wcpsvc.log du segment. Attendez que l'opération soit restaurée.

  • Après la mise à niveau vers NSX 6.4.7, lorsqu'une adresse IPv6 statique est attribuée à des machines virtuelles de charge de travail sur un réseau IPv6, les machines virtuelles ne parviennent pas à effectuer de test ping de l'interface de passerelle IPv6 du dispositif Edge.

    Ce problème se produit après la mise à niveau de vSphere Distributed Switches de la version 6.x vers la version 7.0.

    Solution 1 :

    sélectionnez le VDS sur lequel tous les hôtes sont connectés, accédez au paramètre Modifier et sous l'option Multidiffusion, sélectionnez basic.

    Solution 2 :

    ajoutez les règles suivantes sur le pare-feu Edge :

    Règle d'autorisation de test ping

    Règle d'autorisation du protocole MLD (Multidiffusion Listener Discovery) avec icmp6, tapez 130 (v1) et 143 (v2).

Problèmes de vSAN
  • Les machines virtuelles perdent la connectivité en raison d'une panne de réseau sur le site préféré

    Dans une configuration de cluster étendu vSAN, une panne de réseau sur le site préféré peut entraîner l'inaccessibilité de toutes les machines virtuelles sur le site. Les machines virtuelles ne basculent pas vers un site secondaire. Elles restent inaccessibles jusqu'à ce que l'interruption du réseau soit restaurée.

    Solution : aucune.

  • NOUVEAU : la mise à niveau compatible avec le domaine de pannes pour vSAN ne fonctionne pas au niveau du composant

    Lorsqu'un utilisateur Admin sélectionne une option pour mettre à niveau vSAN avec des domaines de pannes, il peut corriger l'image souhaitée directement à partir de l'interface utilisateur ou de l'API de vSphere Lifecycle Manager, ou choisir de mettre à niveau un composant unique, tel que les VIB NSX-T uniquement. Lors de la correction de l'image souhaitée à partir de l'interface utilisateur ou de l'API, la compatibilité avec le domaine de pannes vSAN est respectée, mais pas pour la correction d'un composant.

    Solution : aucune.

Problèmes des services de cluster vSphere (vCLS)
  • Si toutes les machines virtuelles de l'agent des services de cluster vSphere d'un cluster sont inactives, vSphere DRS ne fonctionne pas dans le cluster 

    Si des machines virtuelles de l'agent des services de cluster vSphere ne parviennent pas à déployer ou à se mettre sous tension dans un cluster, des services tels que vSphere DRS peuvent être affectés.

    Solution : pour plus d'informations sur le problème et pour obtenir des solutions, reportez-vous à l'article 79892 de la base de connaissances VMware.

  • Les machines virtuelles système qui prennent en charge les services de cluster vSphere peuvent avoir un impact sur les workflows de maintenance des clusters et des banques de données

    Dans vCenter Server 7.0 Update 1, la fonctionnalité de services de cluster vSphere ajoute un ensemble de machines virtuelles système dans chaque cluster vSphere pour garantir le bon fonctionnement de vSphere DRS. Les machines virtuelles système se déploient automatiquement avec une logique de sélection de banque de données implicite. En fonction de la configuration de votre cluster, les machines virtuelles système peuvent affecter certains des workflows de maintenance du cluster et de la banque de données.

    Solution : pour plus d'informations sur les workflows affectés et les solutions possibles, reportez-vous aux articles 79892 et 80483 de la base de connaissances VMware.

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

Pour afficher la liste des problèmes connus précédents, cliquez ici.

check-circle-line exclamation-circle-line close-line
Scroll to top icon