Notes de mise à jour de VMware Cloud Foundation 5.0

VMware Cloud Foundation 5.0 | 1er juin 2023 | Build 21822418 VMware Cloud Foundation 5.0.0.1 | 29 septembre 2023 | Build 22485660 Recherchez des ajouts et des mises à jour pour ces notes de mise à jour.

Avis de mise à niveau

Remarque : Les clients VCF+/VCF-S peuvent désormais effectuer une mise à niveau vers VCF 5.0.

Nouveautés

La version VMware Cloud Foundation (VCF) 5.0 comprend les éléments suivants :

• Mise à niveau sur place : VCF 4.3.x, VCF 4.4.x, VCF 4.5 et VCF 4.5.1 peuvent être mis à niveau vers VCF 5.0 à partir de l'interface utilisateur de SDDC Manager (avec accès Internet) ou à l'aide de l'utilitaire de transfert de bundle (sans accès Internet).

• Domaines de charge de travail isolés : Créez et gérez des domaines de charge de travail qui peuvent chacun joindre le domaine vCenter Single Sign-On du domaine de gestion ou un nouveau domaine vCenter Single Sign-On qui n'est utilisé par aucun autre domaine de charge de travail.

• Vérifications des données d'interopérabilité des composants BOM : Vérifications automatiques de l'interopérabilité des composants BOM dans SDDC Manager.

• Réattribution de licences de produits BOM : Possibilité de redéfinir les licences des composants BOM du VCF à partir de l'interface utilisateur de SDDC Manager.

• Mise à jour des licences : SDDC Manager fait désormais l'objet d'une licence incluse dans VCF. Par conséquent, une clé de licence de SDDC Manager distincte n'est plus requise.

• Améliorations des vérifications préalables à la mise à niveau : Les vérifications préalables à la mise à niveau fournissent désormais un contrôle granulaire sur les vérifications préalables des composants individuels et spécifiques à la version.

• Améliorations du workflow de mise à jour de la configuration : Les mises à jour de la configuration peuvent être appliquées entre les applications de mise à niveau ou peuvent être enregistrées pour être appliquées ultérieurement.

• Nouvelle option de mise à niveau pour la mise à niveau ESXi : Si des machines virtuelles hors tension doivent être mises à niveau dans le cluster choisi, elles ne seront évacuées pendant le processus de mise à niveau que si cette option est activée. Autrement, elles ne seront pas migrées spécialement pour les besoins de la mise à niveau.

• Prise en charge échelonnée : Possibilité de mettre à niveau 10 clusters (hôtes) dans 5 domaines de charge de travail (5x10) simultanément dans ESXi, ce qui permet une mise à niveau parallèle.

• Commentaires intégrés au produit : SDDC Manager peut inviter les clients à des intervalles aléatoires à fournir des commentaires relatifs à VMware Cloud Foundation.

• Changement de marque de VMware NSX-T Data Center : À partir de la version 4.0, VMware NSX-T Data Center devient VMware NSX.

• Solutions validées par VMware : Toutes les solutions validées par VMware sont mises à jour pour prendre en charge VMware Cloud Foundation 5.0. Consultez la section Solutions validées par VMware pour obtenir les guides mis à jour.

• VMware Cloud Foundation avec Skyline Health Diagnostics : Nouveau contenu disponible pour les Diagnostics proactifs de VMware Cloud Foundation avec Skyline Health Diagnostics.

• Mises à jour BOM : Mise à jour de la nomenclature avec les nouvelles versions du produit.

  • Notes de mise à jour de VMware vCenter Server Appliance

  • Notes de mise à jour de VMware ESXi

  • Notes de mise à jour de VMware NSX

  • Notes de mise à jour de VMware vRealize Suite Lifecycle Manager

Remarques concernant l'obsolescence

• Le dispositif de création d'images VMware (VIA), intégré au dispositif VMware Cloud Builder et destiné à créer des images de serveurs ESXi, est obsolète dans VMware Cloud Foundation 5.0 et sera supprimé dans une prochaine version.

• Dans une version ultérieure, l'option « Connecter les domaines de charge de travail » de la carte vRealize Operations située dans la section SDDC Manager > Administration > vRealize Suite sera supprimée. De plus, il ne sera plus possible d'utiliser les options de l'API publique VCF correspondantes.

  À partir de vRealize Operations 8.10, une fonctionnalité améliorée pour la connexion des domaines de charge de travail VCF à vRealize Operations est disponible directement à partir de l'interface utilisateur de vRealize Operations. Les utilisateurs sont encouragés à utiliser cette méthode dans l'interface utilisateur vRealize Operations pour connecter des domaines de charge de travail VCF.

• VMware Update Manager comme option par défaut pour le cluster de domaine de gestion sera obsolète dans une version ultérieure et vSphere Lifecycle Manager deviendra la valeur par défaut. Cette modification répond à l'obsolescence de VMware Update Manager dans les prochaines versions de vSphere, comme indiqué ici : https://docs.vmware.com/fr/VMware-vSphere/7.0/rn/vsphere-vcenter-server-703-release-notes.html

Nomenclature (BOM) de VMware Cloud Foundation

Le produit logiciel VMware Cloud Foundation se compose des nomenclatures (BOM) logicielles suivantes. Les composants de la nomenclature sont interopérables et compatibles.

Composant logiciel	Version	Date	Numéro de build
VM Cloud Builder	5.0	1er juin 2023	21822418
SDDC Manager	5.0	1er juin 2023	21822418
VMware vCenter Server Appliance	8.0 Update 1a	1er juin 2023	21815093
VMware ESXi	8.0 Update 1a	1er juin 2023	21813344
Dispositif témoin VMware vSAN	8.0 Update 1	14 avril 2023	21495797
VMware NSX	4.1.0.2	1er juin 2023	21761691
VMware vRealize Suite Lifecycle Manager	8.10 Patch 1	21 février 2023	21331275

• VMware vSAN est inclus dans le bundle VMware ESXi.

• Vous pouvez utiliser vRealize Suite Lifecycle Manager pour déployer vRealize Automation, vRealize Operations Manager, vRealize Log Insight et Workspace ONE Access. vRealize Suite Lifecycle Manager détermine quelles versions de ces produits sont compatibles et vous permet uniquement d'installer/mettre à niveau vers les versions prises en charge.

• Les packs de contenu vRealize Log Insight sont installés lorsque vous déployez vRealize Log Insight.

• Le module de gestion vRealize Operations Manager est installé lorsque vous déployez vRealize Operations Manager.

• Vous pouvez accéder aux dernières versions des packs de contenu pour vRealize Log Insight depuis VMware Solution Exchange et le magasin intégré au produit du marketplace de vRealize Log Insight.

Informations relatives à la licence VMware Software Edition

Le logiciel SDDC Manager est soumis à la licence VMware Cloud Foundation. Le logiciel SDDC Manager déploie des produits logiciels VMware spécifiques en tant qu'élément de ce produit.

Les composants logiciels VMware suivants déployés par SDDC Manager sont concédés sous licence VMware Cloud Foundation :

• VMware ESXi

• VMware vSAN

• VMware NSX

Les composants logiciels VMware suivants déployés par SDDC Manager sont concédés sous licence séparément :

• VMware vCenter Server

REMARQUE : une seule licence vCenter Server est requise pour tous les serveurs vCenter déployés dans un système VMware Cloud Foundation.

Pour plus d'informations sur les éditions spécifiques des logiciels VMware faisant l'objet des licences que vous avez achetées, reportez-vous à la Nomenclature (BOM) de VMware Cloud Foundation.

Pour obtenir des informations générales sur le produit, reportez-vous à la section VMware Cloud Foundation.

Matériel pris en charge

Pour plus d'informations sur les configurations prises en charge, reportez-vous au Guide de compatibilité VMware (VCG) et à la section Configuration matérielle requise dans l'onglet Liste de vérification des conditions préalables du Manuel de planification et de préparation.

Documentation

Pour accéder à la documentation Cloud Foundation, accédez à la Documentation du produit VMware Cloud Foundation.

Pour accéder à la documentation des produits logiciels VMware que SDDC Manager peut déployer, reportez-vous à la documentation du produit et utilisez les menus déroulants de la page pour choisir la version appropriée :

• Documentation du produit VMware vSphere incluant aussi de la documentation sur ESXi et vCenter Server

• Documentation du produit VMware vSAN

• Documentation du produit VMware NSX

Compatibilité des navigateurs et résolutions d'écran

L'interface Web VMware Cloud Foundation prend en charge les deux dernières versions des navigateurs Web suivants :

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

Pour les interfaces utilisateur Web, la résolution standard prise en charge est de 1 920 x 1 080 pixels.

Informations sur l'installation et la mise à niveau

Vous pouvez installer VMware Cloud Foundation 5.0 en tant que nouvelle version ou effectuer une mise à niveau séquentielle ou de niveau ignoré vers VMware Cloud Foundation 5.0.

Attention:

Si vous effectuez une mise à niveau vers VMware Cloud Foundation 5.0 ou une version ultérieure, lisez les informations critiques dans l'article 91751 de la base de connaissances.

Installation en tant que nouvelle version

Le nouveau processus d'installation comprend trois phases :

• Phase 1 : Préparer l'environnement : Le Manuel de planification et de préparation fournit des informations détaillées sur les logiciels, les outils et les services externes requis pour implémenter un SDDC (Software-Defined Data Center) avec VMware Cloud Foundation, à l'aide d'un modèle d'architecture standard.

• Phase 2 : Image de tous les serveurs avec ESXi : Créez une image de tous les serveurs avec la version d'ESXi mentionnée dans la section Nomenclature (BOM) de Cloud Foundation. Pour plus d'informations sur l'installation d'ESXi, reportez-vous au Guide de déploiement de VMware Cloud Foundation.

• Phase 3 : Installer Cloud Foundation 5.0 : Pour plus d'informations sur le déploiement de Cloud Foundation, reportez-vous au Guide de déploiement de VMware Cloud Foundation.

Mise à niveau vers Cloud Foundation 5.0

Important:

VMware Cloud Foundation 4.5.2 ne peut pas être mis à niveau vers VMware Cloud Foundation 5.0 ou 5.0.0.1. Pour plus d'informations, reportez-vous à l'article 94195 de la base de connaissances..

Vous pouvez effectuer une mise à niveau séquentielle ou de niveau ignoré vers VMware Cloud Foundation 5.0 à partir de VMware Cloud Foundation 4.3.x ou d'une version ultérieure. Si votre environnement est à une version antérieure à la version 4.3.x, vous devez mettre à niveau le domaine de gestion et tous les domaines de charge de travail VI vers VMware Cloud Foundation 4.3.x ou une version ultérieure, puis effectuer la mise à niveau vers VMware Cloud Foundation 5.0. Pour plus d'informations, reportez-vous à la section Gestion du cycle de vie de VMware Cloud Foundation.

Important:

Avant de mettre à niveau une instance de vCenter Server, effectuez une sauvegarde sur fichier. Reportez-vous à la section Sauvegarde manuelle de vCenter Server.

Note:

Étant donné que VMware Cloud Foundation 5.0.x désactive le service SSH par défaut, les scripts qui reposent sur l'activation de SSH sur les hôtes ESXi ne fonctionneront pas après la mise à niveau vers VMware Cloud Foundation 5.0.x. Mettez à jour vos scripts en fonction de ce nouveau comportement. Pour plus d'informations sur l'activation et la désactivation du service SSH sur les hôtes ESXi, reportez-vous à l'article  86230 de la base de connaissances.

Informations sur la version VMware Cloud Foundation 5.0.0.1

VMware Cloud Foundation 5.0.0.1 inclut des mises à jour de sécurité, des correctifs pour les problèmes de gestion du cycle de vie et de l'interface utilisateur, et des améliorations apportées aux vérifications préalables au niveau du bundle pour vCenter.

Vous pouvez effectuer une mise à niveau séquentielle ou de niveau ignoré vers VMware Cloud Foundation 5.0.0.1 à partir de VMware Cloud Foundation VCF 4.3.x, VCF 4.4.x, VCF 4.5, VCF 4.5.1 et 5.0. Si votre environnement est à une version antérieure à la version 4.3.x, vous devez mettre à niveau le domaine de gestion et tous les domaines de charge de travail VI vers VMware Cloud Foundation VCF 4.3.x, VCF 4.4.x, VCF 4.5 et VCF 4.5.1, puis effectuer la mise à niveau vers VMware Cloud Foundation 5.0.0.1. Pour plus d'informations, reportez-vous à la section Gestion du cycle de vie de VMware Cloud Foundation.

VMware Cloud Foundation 5.0.0.1 contient les mises à jour de nomenclature suivantes :

Composant logiciel	Version	Date	Numéro de build
SDDC Manager	5.0.0.1	29 septembre 2023	22485660

Cette version résout les problèmes suivants dans SDDC Manager :

• Correctifs de l'interface utilisateur :

  • Missing license information le message d'erreur ne se produit plus dans les cas suivants :

    1. Une opération de création de domaine est déclenchée à partir d'un écran de domaine de charge de travail via l'API publique (en dehors de l'interface utilisateur SDDC),

    2. Un workflow Ajouter un cluster est déclenché via l'interface utilisateur.

  • Les bannières disposent désormais d'une nouvelle option Ignorer.

  • Dans une configuration avec le domaine de gestion et le domaine de charge de travail VI, dans l'état ABONNEMENT/ACTIF (OU ABONNEMENT ANNULÉ), ce message s'affichait par erreur à l'utilisateur : You have reached the limit of 4 cloud-connected workload domains. To learn how to add more workload domains, go to the VMware knowledge base.

• Correctifs de la gestion du cycle de vie :

  • Échec de la mise à niveau d'ESXi avec une erreur ESX UPGRADE VUM STAGE REGISTER UPLOADED FILES

  • Lors de la mise à niveau de VCF 4 vers la version 5, un problème se produisait avec la spécification d'entrée de clé de licence, ce qui entraînait un problème avec une mise à niveau de vCenter.

  • Le journal de débogage LCM (lcm-debug.log) recevait le message d'erreur does not have a valid product api version string indésirable. Ce problème de journalisation excessive a été résolu.

• Déploiement :

  • Échec systématique de la mise en service de l'hôte par le client, même si celui-ci remplit toutes les conditions requises

• Améliorations et correctifs des vérifications préalables :

  • Échec des vérifications préalables de NSX-T BACKUP en raison d'un espace disque insuffisant et le message de correction ne fournit pas les informations appropriées.

Problèmes connus

• Problèmes connus de VMware Cloud Foundation
• Problèmes connus de mise à niveau
• Problèmes connus liés à la configuration initiale
• Problèmes connus de SDDC Manager
• Problèmes connus du domaine de charge de travail
• Problèmes connus de l'API

Problèmes connus de VMware Cloud Foundation

• Aucune erreur générée lorsque l'inventaire NSX Manager n'est pas synchronisé lors de la vérification préalable de la gestion du cycle de vie

  La vérification préalable de la gestion du cycle de vie affiche un état vert et ne génère aucune erreur pour l'inventaire NSX Manager.

  Solution : Aucun

• Erreur d'informations de licence manquantes dans l'interface utilisateur

  Une erreur Missing domain licensing information s'affiche lorsque :

  1. Une opération de création de domaine est déclenchée à partir d'un écran de domaine de charge de travail via l'API publique (en dehors de l'interface utilisateur SDDC),

  2. puis un workflow Ajouter un cluster est déclenché via l'interface utilisateur.

  Solution : actualisez la page, puis déclenchez le workflow « Ajouter un cluster ».

• L'écran de mise à niveau affiche la version incorrecte lors de la mise à niveau de VCF 4.3 vers la version 5.0.

  L'interface utilisateur de VCF affiche la version source incorrecte lors de la mise à niveau de la version 4.3 vers la version 5.0. Cependant, la mise à niveau réelle s'effectue toujours correctement en passant directement de la version source à la version cible.

  Solution : Aucun

• La création de domaines de charge de travail en parallèle n'applique pas la limite maximale de gestionnaires de calcul par NSX Manager.

  La création de domaines de charge de travail en parallèle peut entraîner l'échec d'une ou plusieurs créations de domaines de charge de travail, car la limite des gestionnaires de calcul par NSX Manager sera dépassée.

  Solution : supprimez le domaine de charge de travail qui a échoué.

• Dans la nomenclature mixte VCF 5.0 avec vCenter Enhanced Linked Mode, vous pouvez voir les systèmes vCenter Server de la version 8.0 à partir d'une instance de vCenter Server 7.x.

  Si vous disposez d'un groupe vCenter Enhanced Linked Mode qui contient des instances de vCenter Server des versions 8.x et 7.x, lorsque vous vous connectez à une instance de version 7.x de vCenter Server, dans vSphere Client, vous pouvez voir des systèmes vCenter Server de version 8.0. Étant donné que vCenter Server 8.0 introduit de nouvelles fonctionnalités, vous pouvez exécuter des workflows spécifiques à vSphere 8.0 sur vCenter Server 8.0, mais cela peut entraîner des résultats inattendus lors d'une exécution à partir de vSphere Client 7.x.

  Solution : ce problème est résolu dans vSphere 7.0 P07.

• Entrées supplémentaires dans la liste déroulante Portée de la vérification préalable de la mise à niveau

  Lorsque vous effectuez des contrôles préalables de mise à niveau via l'interface utilisateur de SDDC Manager et que vous sélectionnez une version cible de VCF, la liste déroulante « Portée de la vérification préalable » peut contenir plus d'entrées sélectionnables que nécessaire. SDDC Manager peut s'afficher plusieurs fois en tant qu'entrée. Il peut également être inclus en tant que composant sélectionnable pour les domaines VI, bien qu'il s'agisse d'un composant du domaine de gestion.

  Solution : aucune. Il s'agit d'un problème visuel sans incidence fonctionnelle.

• La conversion de clusters de lignes de base vSphere Lifecycle Manager en images vSphere Lifecycle Manager n'est pas prise en charge.

  Les lignes de base de vSphere Lifecycle Manager (anciennement connu sous le nom de vSphere Update Manager ou VUM) sont obsolètes dans vSphere 8.0, mais continuent d'être prises en charge. Pour plus d'informations, reportez-vous à l'article 89519 de la base de connaissances..

  VMware Cloud Foundation 5.0 ne prend pas en charge la conversion de clusters à partir de lignes de base vSphere Lifecycle Manager en images vSphere Lifecycle Manager. Cette fonctionnalité sera prise en charge dans une version ultérieure.

  Solution : Aucun

• La gestion de la charge de travail ne prend pas en charge la fédération NSX Data Center

  Vous ne pouvez pas déployer la gestion de la charge de travail (vSphere with Tanzu) sur un domaine de charge de travail lorsque l'instance NSX Data Center de ce domaine de charge de travail est membre d'une fédération NSX Data Center.

  Solution : Aucun.

• NSX Guest Introspection (GI) et NSX Network Introspection (NI) ne sont pas pris en charge sur les clusters étendus

  Il n'existe aucune prise en charge de l'extension des clusters sur lesquels NSX Guest Introspection (GI) ou NSX Network Introspection (NI) sont activés. VMware Cloud Foundation détache les profils de nœud de transport des hôtes AZ2 pour autoriser les configurations réseau spécifiques à la zone de disponibilité. NSX GI et NSX NI exigent que le même profil de nœud de transport soit attaché à tous les hôtes du cluster.

  aucune.

• Clusters étendus et gestion de la charge de travail

  Vous ne pouvez pas étendre un cluster sur lequel la gestion de la charge de travail est déployée.

  aucune.

Problèmes connus de mise à niveau

• Nouveau - Le bouton Planifier la mise à jour/Réessayer la mise à niveau n'est pas désactivé lorsqu'une mise à niveau existante est en cours.

  Lorsqu'une mise à niveau est en cours pour une partie du cluster d'un domaine, l'interface utilisateur permet toujours à l'utilisateur de sélectionner et de démarrer la mise à niveau pour un autre cluster. Toutefois, cette action est bloquée sur le bouton TERMINER.

  Solution : Ne déclenchez pas une autre mise à niveau lorsqu'une mise à niveau est en cours sur un domaine.

• Nouveau - La fenêtre contextuelle de verrouillage de déploiement sur la page des mises à jour est vierge lors des opérations de domaine

  Si ces dernières sont effectuées pendant une mise à niveau, telles que l'ajout d'un hôte ou d'un cluster, les opérations liées à la mise à niveau sont bloquées et l'info-bulle n'affiche pas le texte avec la raison.

  Solution : aucune.

• Nouveau - Le bouton TERMINER de l'interface utilisateur de mise à niveau permet de lancer plusieurs mises à niveau.

  Lorsque vous cliquez plusieurs fois sur le bouton TERMINER, plusieurs mises à niveau sont lancées pour le même bundle.

  Aucune solution. Vous pouvez voir toutes les mises à niveau déclenchées dans le panneau de tâches. Toutes les mises à niveau lancées après le premier clic du bouton Terminer échoueront.

• VCF 4.5.1 avec le correctif asynchrone pour NSX 3.2.3 ne peut pas être mis à niveau vers la version VCF 5.0

  La mise à niveau de NSX 3.2.3 vers la version 4.1.0.2 n'est pas prise en charge. Elle prend uniquement en charge la version NSX 4.1.1 et les versions ultérieures.

  Solution : aucune.

  Ce problème sera résolu dans une version ultérieure.

• Échec de la mise à jour de VC pendant l'installation

  Lors de l'exécution de la charge de travail VC mise à niveau à partir de VCF, l'installation de VC échoue avec le message target vc upgrade precheck stage failing.

  Solution : ne réutilisez pas la même adresse IP temporaire pour les mises à niveau séquentielles de VC. Utilisez une adresse IP temporaire distincte pour chaque VC en cours de mise à niveau.

• La mise à niveau de NSX peut échouer s'il y a des alarmes actives dans NSX Manager.

  S'il y a des alarmes actives dans NSX Manager, la mise à niveau NSX peut échouer.

  Solution : vérifiez les alarmes actives dans l'interface utilisateur NSX Manager avant la mise à niveau et corrigez-les, le cas échéant. Si les alarmes ne sont pas corrigées, la mise à niveau NSX échouera. Vous pouvez recommencer la mise à niveau après avoir corrigé les alarmes.

• La vérification préalable de NSX a échoué avec un message d'erreur

  Si les conditions préalables Backup SDDC Manager, all vCenter Servers, and NSX Managers à la mise à niveau sont ignorées et que l'emplacement STFP défini pour la sauvegarde de la configuration NSX n'a pas assez d'espace disque, le message d'erreur Precheck for NSX has failed s'affiche. Bien que la cause principale de l'erreur sftp server disk is full s'affiche dans le journal d'Operations Manager, elle ne s'affiche pas actuellement dans SDDC Manager.

  Solution : augmentez l'espace disque disponible sur le serveur SFTP, puis remplissez les conditions préalables de mise à niveau avant de continuer.

• Aucune erreur générée lorsque l'inventaire NSX Manager n'est pas synchronisé lors de la vérification préalable de la gestion du cycle de vie

  Solution : aucune.

• Les détails du bundle SDDC Manager doivent indiquer 4.4.1.1 comme « Version requise » pour la mise à niveau échelonnée

  Lors d'une mise à niveau échelonnée de VMware Cloud Foundation 4.4.1.1 vers 5.0, il existe une erreur dans les détails du pack SDDC Manager, qui indique de manière incorrecte VMware Cloud Foundation 4.5.0 comme étant la « Version requise ».

  Solution : Aucun

• Échec de la mise à niveau de VCF ESXi lors de la validation postérieure en raison d'un problème de configuration de cluster lié à HA

  La mise à niveau du cluster ESXi échoue avec une erreur semblable au message d'erreur ci-dessous :

  Cluster Configuration Issue: vSphere HA failover operation in progress in cluster <cluster-name> in datacenter <datacenter-name>: 0 VMs being restarted, 1 VMs waiting for a retry, 0 VMs waiting for resources, 0 inaccessible vSAN VMs

  Solution : reportez-vous à l'article  90985 de la base de connaissances.

• Échec de la mise à niveau de SDDC Manager à l'étape « Configurer Common Appliance Platform »

  Si une tâche de reconfiguration de machine virtuelle (par exemple, la suppression d'un snapshot ou l'exécution d'une sauvegarde) se déroule dans le domaine de gestion au moment où vous mettez à niveau SDDC Manager, la mise à niveau peut échouer.

  Solution : planifiez les mises à niveau de SDDC Manager à un moment où aucune tâche de reconfiguration de machine virtuelle n'est exécutée dans le domaine de gestion. Si vous rencontrez ce problème, attendez que les autres tâches soient terminées, puis réessayez la mise à niveau.

• Les mises à niveau parallèles de vCenter Server ne sont pas prises en charge

  Si vous essayez de mettre à niveau vCenter Server pour plusieurs domaines de charge de travail VI en même temps, la mise à niveau peut échouer lors de la modification des autorisations du répertoire de configuration vpostgres dans le dispositif. Le message chown -R vpostgres:vpgmongrp /storage/archive/vpostgres s'affiche dans le fichier PatchRunner.log sur le vCenter Server Appliance.

  Solution : chaque instance de vCenter Server doit être mise à niveau individuellement.

• Une des machines virtuelles de l'agent vSphere Cluster Services (vCLS) est placée sur le stockage local lors de la mise à niveau de VMware Cloud Foundation

  vSphere Cluster Services (vCLS) garantit que les services de cluster restent disponibles, même lorsque vCenter Server est indisponible. vCLS déploie trois machines virtuelles d'agent vCLS pour maintenir la santé des services du cluster. Lorsque vous mettez à niveau VMware Cloud Foundation, l'une des machines virtuelles vCLS peut être placée sur le stockage local au lieu du stockage partagé. Cela peut provoquer des problèmes si vous supprimez l'hôte ESXi sur lequel la VM est stockée.

  Solution : désactivez et réactivez vCLS sur le cluster pour déployer toutes les VM de l'agent vCLS sur le stockage partagé.

  1. Vérifiez le placement des machines virtuelles de l'agent vCLS pour chaque cluster de votre environnement.

     1. Dans vSphere Client, sélectionnez Menu > VM et modèles.

     2. Développez le dossier vCLS.

     3. Sélectionnez la première VM d'agent vCLS et cliquez sur l'onglet Résumé.

     4. Dans la section Objets associés, vérifiez la banque de données répertoriée pour le stockage. Il doit s'agir de la banque de données vSAN. Si une VM d'agent vCLS se trouve sur le stockage local, vous devez désactiver vCLS pour le cluster, puis le réactiver.

     5. Répétez ces étapes pour toutes les machines virtuelles d'agent vCLS.

  2. Désactivez vCLS pour les clusters disposant de machines virtuelles d'agent vCLS sur un stockage local.

     1. Dans vSphere Client, cliquez sur Menu > Hôtes et clusters.

     2. Sélectionnez un cluster qui possède une machine virtuelle d'agent vCLS sur un stockage local.

     3. Dans la barre d'adresse du navigateur Web, notez l'ID moref du cluster.

        Par exemple, si l'URL s'affiche comme suit : https://vcenter-1.vrack.vsphere.local/ui/app/cluster;nav=h/urn:vmomi:ClusterComputeResource:domain-c8:503a0d38-442a-446f-b283-d3611bf035fb/summary, l'ID moref est domain-c8.

     4. Sélectionnez le vCenter Server contenant le cluster.

     5. Cliquez sur Configurer > Paramètres avancés.

     6. Cliquez sur Modifier les paramètres.

     7. Modifiez la valeur de config.vcls.clusters.<moref id>.enabled en false et cliquez sur Enregistrer.

        Si le paramètre config.vcls.clusters.<moref id>.enabled ne s'affiche pas pour votre ID moref, entrez son nom et la valeur false, puis cliquez sur Ajouter.

     8. Attendez quelques minutes que les machines virtuelles de l'agent vCLS soient mises hors tension et supprimées. Vous pouvez suivre la progression dans le volet Tâches récentes.

  3. Activez vCLS pour le cluster afin de placer les VM de l'agent vCLS sur un stockage partagé.

     1. Sélectionnez le vCenter Server contenant le cluster et cliquez sur Configurer > Paramètres avancés.

     2. Cliquez sur Modifier les paramètres.

     3. Modifiez la valeur de config.vcls.clusters.<moref id>.enabled en true et cliquez sur Enregistrer.

     4. Attendez quelques minutes que les machines virtuelles de l'agent vCLS soient déployées et mises sous tension. Vous pouvez suivre la progression dans le volet Tâches récentes.

  4. Vérifiez l'emplacement des machines virtuelles de l'agent vCLS pour vous assurer qu'elles se trouvent toutes sur un stockage partagé

• Problèmes liés à l'interface utilisateur de SDDC Manager lors de l'exécution de plusieurs vérifications préalables de mise à niveau parallèle

  Si vous lancez une vérification préalable sur plusieurs domaines de charge de travail simultanément, l'interface utilisateur de SDDC Manager peut clignoter et afficher des informations incorrectes.

  Solution : n'exécutez pas plusieurs vérifications préalables parallèles. Si vous le faites, attendez que les vérifications préalables soient terminées pour évaluer les résultats.

• Les résultats des vérifications préalables à la mise à niveau pour ESXi affichent l'erreur « Le périphérique TPM 2.0 détecté, mais impossible d'établir une connexion ».

  Ce problème peut se produire pour des hôtes ESXi dont les puces TPM (Trusted Platform Modules) sont partiellement configurées.

  Solution : assurez-vous que le périphérique TPM est configuré dans le BIOS de l'hôte ESXi pour utiliser l'algorithme de hachage SHA-256 et l'interface TIS/FIFO (First-In, First-Out, premier entré, premier sorti), mais pas le CRB (Command Response Buffer, tampon de réponse de la commande). Pour plus d'informations sur la définition de ces options BIOS requises, consultez la documentation du fournisseur.

• L'exécution de vérifications préalables parallèles sur plusieurs domaines de charge de travail qui utilisent des images vSphere Lifecycle Manager peut échouer.

  Si vous effectuez des vérifications préalables parallèles sur plusieurs domaines de charge de travail qui utilisent des images vSphere Lifecycle Manager en même temps que vous effectuez des mises à niveau parallèles, les vérifications préalables risquent d'échouer.

  Solution : utilisez les instructions suivantes pour planifier vos mises à niveau et vos vérifications préalables pour les domaines de charge de travail qui utilisent des images vSphere Lifecycle Manager.

  • Pour les mises à niveau simultanées, VMware Cloud Foundation prend en charge jusqu'à cinq domaines de charge de travail pouvant chacun comporter cinq clusters.

  • Pour les vérifications préalables simultanées, VMware Cloud Foundation prend en charge jusqu'à trois domaines de charge de travail pouvant chacun comporter quatre clusters.

  • N'exécutez pas de mises à niveau parallèles et de vérifications préalables en même temps.

• L'utilisation de l'API /v1/upgrades pour déclencher des mises à niveau simultanées de clusters sur plusieurs domaines de charge de travail dans un seul appel API ne permet pas d'effectuer la mise à niveau parallèle des clusters.

  Lors de l'utilisation de l'API VMware Cloud Foundation pour mettre à niveau plusieurs domaines de charge de travail simultanément, l'inclusion de plusieurs spécifications de mise à niveau des ressources (resourceUpgradeSpec) dans un seul appel API (/v1/upgrades) de mise à niveau de domaine ne fonctionne pas comme prévu.

  Solution : pour obtenir des performances optimales lors de la mise à niveau de plusieurs domaines de charge de travail simultanément à l'aide de l'API VMware Cloud Foundation, n'incluez pas plusieurs spécifications de mise à niveau de ressources (resourceUpgradeSpec) dans un seul appel de mise à niveau de domaine. Au lieu de cela, appelez la mise à niveau du domaine plusieurs fois avec un seul resourceUpgradeSpec pour chaque domaine de charge de travail.

  Vous pouvez également utiliser l'interface utilisateur de SDDC Manager pour déclencher plusieurs mises à niveau simultanées dans les domaines de charge de travail.

• Échec de la mise à niveau de NSX Data Center à l'étape « NSX T EFFECTUER UNE SAUVEGARDE »

  Si vous n'avez pas changé la destination des sauvegardes de NSX Manager vers un serveur SFTP externe, les mises à niveau peuvent échouer à cause d'une empreinte digitale SSH obsolète pour SDDC Manager.

  Solution :

  1. connectez-vous à l'interface utilisateur de NSX Manager.

  2. Cliquez sur Système > Sauvegarder et restaurer.

  3. Cliquez sur Modifier pour le serveur SFTP.

  4. Supprimez l'empreinte digitale SSH existante et cliquez sur Enregistrer.

  5. Cliquez sur Ajouter pour ajouter l'empreinte digitale fournie par le serveur.

  6. Cliquez sur Enregistrer.

  7. Réessayez la mise à niveau de NSX Data Center à partir de l'interface utilisateur de SDDC Manager.

• Échec de la mise à niveau d'ESXi au niveau du cluster

  La sélection au niveau du cluster pendant la mise à niveau ne tient pas compte de l'état de santé des clusters et peut afficher l'état d'un cluster comme Disponible, même pour un cluster défectueux. Si vous sélectionnez un cluster défectueux, la mise à niveau échoue.

  Effectuez toujours une vérification préalable de la mise à jour pour valider l'état de santé des clusters. Résolvez tous les problèmes avant de procéder à la mise à niveau.

• Impossible de mettre à jour NSX Data Center dans le domaine de gestion ou dans un domaine de charge de travail avec le stockage principal vSAN, en raison d'une erreur au cours de l'étape de vérification préalable du nœud de transport NSX

  Dans SDDC Manager, lorsque vous exécutez la vérification préalable à la mise à niveau avant de mettre à jour NSX Data Center, la validation du nœud de transport NSX génère l'erreur suivante.

  Aucun vidage mémoire cible n'a été configuré. Les vidages de mémoire de l'hôte ne peuvent pas être sauvegardés : les journaux système sur l'hôte sfo01-m01-esx04.sfo.rainpole.io sont stockés sur un stockage non persistant. Consultez la documentation du produit pour configurer un serveur Syslog ou une partition Scratch.

  Comme la vérification préalable à la mise à niveau génère une erreur, vous ne pouvez pas procéder à la mise à jour de l'instance de NSX Data Center dans le domaine. VMware Validated Design prend en charge vSAN comme stockage principal dans le domaine de gestion. Cependant, les banques de données vSAN ne prennent pas en charge les partitions Scratch. Reportez-vous à l'article 2074026 de la base de connaissances VMware.

  Désactivez la validation de la vérification préalable pour la mise à jour ultérieure de NSX Data Center.

  1. Connectez-vous à SDDC Manager en tant que VCF à l'aide d'un client Secure Shell (SSH).

  2. Ouvrez le fichier application-prod.properties pour le modifier : vi /opt/vmware/vcf/lcm/lcm-app/conf/application-prod.properties

  3. Ajoutez la propriété suivante et enregistrez le fichier : lcm.nsxt.suppress.prechecks=true

  4. Redémarrez le service de gestion du cycle de vie : systemctl restart lcm

  5. Connectez-vous à l'interface utilisateur de SDDC Manager et procédez à la mise à jour de NSX Data Center.

• La mise à niveau de NSX-T peut échouer à l'étape NSX T TRANSPORT NODE POSTCHECK STAGE

  La mise à niveau de NSX-T ne peut pas se poursuivre au-delà de l'étape NSX T TRANSPORT NODE POSTCHECK STAGE.

  Contactez le support VMware.

• La mise à niveau d'ESXi échoue avec l'erreur « Fichiers de correctif ou de mise à niveau incompatibles. Vérifiez que le fichier de correctif est compatible avec l'hôte. Reportez-vous aux fichiers journaux LCM et VUM ».

  Cette erreur se produit si l'un des hôtes ESXi que vous mettez à niveau possède des périphériques de stockage détachés.

  Solution : attachez tous les périphériques de stockage aux hôtes ESXi en cours de mise à niveau. Redémarrez les hôtes et recommencez la mise à niveau.

• La vérification préalable à la mise à jour échoue avec l'erreur « Le mot de passe a expiré »

  Si la stratégie de mot de passe vCenter Single Sign-On spécifie une durée de vie maximale de zéro (n'expire jamais), la vérification préalable échoue.

  Solution : définissez la stratégie de durée de vie maximale du mot de passe sur une valeur différente de zéro, puis réessayez la vérification préalable.

Problèmes connus liés à la configuration initiale

• Impossible de se connecter au dispositif VMware Cloud Builder

  Si vous déployez le dispositif VMware Cloud Builder avec un mot de passe d'administrateur ou racine à 8 caractères, vous ne pouvez pas vous connecter au dispositif et l'erreur Invalid username or password s'affiche.

  Solution : Redéployez le dispositif VMware Cloud Builder avec des mots de passe contenant au moins 12 caractères.

• La validation de la mise en place de la configuration réseau échoue avec le message « L'adresse IP de la passerelle pour la gestion n'est pas joignable »

  L'échec suivant « L'adresse IP de la passerelle pour la gestion n'est pas joignable » est signalé comme une erreur fatale dans l'interface utilisateur de Cloud Buider et la mise en place ne peut pas continuer. Dans certains cas, la validation ne parvient pas à valider la connectivité parce qu'elle utilise un ensemble de ports prédéfinis, mais le ping fonctionne.

  Solution : Pour plus d'informations, consultez l'article KB 89990.

Problèmes connus de SDDC Manager

• SDDC Manager affiche de manière incorrecte le mode sombre en raison de l'héritage des paramètres du SE dans VCF 5.0

  L'interface utilisateur de SDDC Manager ne prend pas en charge le mode sombre par défaut. Il tente de rendre le mode sombre en fonction des paramètres du SE, ce qui peut entraîner des problèmes de rendu de certains écrans.

  Solution : Il existe deux façons de résoudre ce problème :

  • Désactivez le mode sombre au niveau du système d'exploitation et videz le cache du navigateur, ou

  • Exécutez le script suivant dans la console du développeur du navigateur que vous utilisez (en remplaçant le champ Domain par le FQDN de votre système) :

  document.cookie = 'clarity-theme=Light; Max-Age=2147483647; path=/; Domain=sddc-manager.vrack.vsphere.local; SameSite=Lax'

• La clé de licence SDDC Manager n'est pas nécessaire

  Aucune clé de licence SDDC Manager n'est nécessaire, et vous pouvez ignorer toute erreur liée à une clé de licence SDDC manager existante.

  Solution : aucune.

• Le compte administrateur de vRealize Operations Manager s'affiche comme déconnecté

  SDDC Manager indique de manière incorrecte que le compte administrateur de vRealize Operations Manager est déconnecté à cause d'un mot de passe qui a expiré. En fait, le mot de passe du compte administrateur utilisé pour se connecter à l'interface utilisateur de vRealize Operations Manager n'expire jamais, mais SDDC Manager vérifie en réalité le mot de passe du compte administrateur du dispositif virtuel (Photon OS).

  Solution : pour supprimer l'alerte de mot de passe expiré/déconnecté dans SDDC Manager :

  1. Connectez-vous au nœud vRealize Operations Manager concerné et mettez à jour le mot de passe administrateur du dispositif virtuel.

  2. Dans SDDC Manager, corrigez (ou effectuez une rotation ou une mise à jour) du mot de passe du compte expiré. Vous pouvez également utiliser l'API VMware Cloud Foundation pour exécuter POST /v1/credentials/expirations.

• L'interface utilisateur de SDDC Manager affiche toujours le système d'exploitation local comme source d'identité par défaut

  Si vous ajoutez Active Directory sur LDAP ou OpenLDAP en tant que source d'identité dans SDDC Manager et utilisez vSphere Client pour définir cette source d'identité comme source par défaut, l'interface utilisateur de SDDC Manager (Administration > Single Sign On > Fournisseur d'identité) continue d'afficher le SE local comme source d'identité par défaut.

  
  

  Solution : utilisez vSphere Client pour confirmer la source d'identité par défaut.

• Échec de la résolution de nom lors de la configuration du serveur NTP

  Sous certaines conditions, la résolution de nom peut échouer lorsque vous configurez un serveur NTP.

  Solution : exécutez la commande suivante à l'aide du nom de domaine complet des ressources ayant échoué pour vous assurer que la résolution de nom a réussi, puis réessayez la configuration du serveur NTP.

  nslookup <FQDN>

• La tâche Générer une CSR pour un composant est suspendue

  Lorsque vous générez une CSR, la tâche peut échouer à cause des problèmes liés aux ressources du composant. Par exemple, lorsque vous générez une CSR pour NSX Manager, la tâche peut échouer à cause des problèmes avec un nœud NSX Manager. Vous ne pouvez pas réessayer la tâche une fois que la ressource est à nouveau opérationnelle.

  1. Connectez-vous à l'interface utilisateur du composant pour dépanner et résoudre les problèmes.

  2. À l'aide de SSH, connectez-vous à la machine virtuelle SDDC Manager avec le nom d'utilisateur vcf.

  3. Tapez su pour passer au compte root.

  4. Exécutez la commande suivante : systemctl restart operationsmanager

  5. Réessayez de générer la CSR.

• Les options de l'utilitaire SoS pour le contrôle de santé sont manquantes

  En raison des limitations du compte de service ESXi, certaines informations ne sont pas disponibles dans les options de contrôle de santé suivantes :

  • --hardware-compatibility-report: Aucune information Devices and Driver pour les hôtes ESXi.

  • --storage-health: Aucune information vSAN Health Status ou Total no. of disks pour les hôtes ESXi.

  aucune.

Problèmes connus du domaine de charge de travail

• L'interface utilisateur de SDDC Manager affiche de manière incorrecte « Propriétaire » dans le domaine de charge de travail isolé en tant qu'utilisateur Admin SSO du domaine de gestion.

  Lors de la création d'un domaine de charge de travail isolé, la vue « Domaines de charge de travail » de l'interface utilisateur affiche de manière incorrecte « Propriétaire » en tant qu'utilisateur Admin SSO du domaine de gestion.

  Solution : les informations sur le domaine s'affichent dans la colonne « Domaine SSO ». Pour intégrer le domaine SSO comme colonne, sélectionnez-le dans la configuration du tableau pour l'afficher en tant que telle. La colonne Propriétaire de l'interface utilisateur ne s'applique pas aux domaines de charge de travail isolés.

• Un accord de réplication inattendu subsiste après la désaffectation réussie de la tâche de nœud SSO

  La désaffectation du nœud SSO a réussi, mais le partenaire de réplication est resté.

  Solution : supprimez manuellement l'association de réplication du nœud SSO non valide et redémarrez la suppression du domaine de charge de travail.

  La commande vCenter /usr/lib/vmware-vmdir/bin/vdcrepadmin peut être utilisée pour ajouter/supprimer des accords de réplication.

• Les opérations hétérogènes « Création de cluster » et « Création de VI » ne sont pas prises en charge pour être exécutées en parallèle lorsqu'elles fonctionnent avec la même instance de NSX partagée.

  Si un workflow de création de VI est en cours d'exécution sur une ressource NSX, la création d'un cluster sur des domaines qui partagent ce NSX n'est pas possible.

  Solution : aucune. Le workflow de création de VI doit être terminé avant que le workflow de création de cluster puisse être lancé.

• L'interface utilisateur de SDDC Manager vous permet de sélectionner une instance de NSX Manager non prise en charge

  Lorsque vous créez un domaine de charge de travail VI, il ne peut pas partager une instance NSX Manager avec un domaine de charge de travail VI qui se trouve dans un domaine SSO différent. Bien que l'interface utilisateur de SDDC Manager vous permette de sélectionner une instance de NSX Manager non prise en charge, la tâche de création du domaine de charge de travail VI échouera.

  Solution : Aucun

• Échec de l'ajout d'un hôte lorsque l'hôte se trouve sur un VLAN différent

  L'ajout d'un hôte peut parfois échouer si l'hôte se trouve sur un autre VLAN.

  1. Avant d'ajouter l'hôte, ajoutez un nouveau groupe de ports au VDS pour ce cluster.

  2. Marquez le nouveau groupe de ports avec l'ID du VLAN de l'hôte à ajouter.

  3. Ajoutez l'hôte. Ce workflow échoue à l'opération « Migrer les cartes vmknic de l'hôte vers DVS ».

  4. Localisez l'hôte défaillant dans vCenter et migrez le vmk0 de l'hôte vers le nouveau groupe de ports que vous avez créé à l'étape 1. Pour plus d'informations, reportez-vous à la section Migrer les adaptateurs VMkernel vers un vSphere Distributed Switch dans la documentation du produit vSphere.

  5. Réessayez l'opération Ajouter un hôte.

  REMARQUE : Si vous supprimez cet hôte par la suite, vous devez également supprimer manuellement le groupe de ports s'il n'est pas utilisé par un autre hôte.

• Le déploiement de services de partenaires sur un domaine de charge de travail NSX affiche une erreur

  Le déploiement de services de partenaires, tels que McAfee ou Trend, sur un domaine de charge de travail activé pour vSphere Update Manager (VUM) affiche l'erreur « Configurer NSX au niveau du cluster pour déployer la VM de service ».

  Attachez le profil de nœud de transport au cluster et essayez de déployer le service de partenaires. Une fois le service déployé, détachez le profil de nœud de transport du cluster.

• Si la version d'ESXi du témoin ne correspond pas à la version d'ESXi de l'hôte dans le cluster, une partition du cluster vSAN peut se produire

  Le workflow du cluster vSAN étendu ne vérifie pas la version d'ESXi de l'hôte témoin. Si la version d'ESXi du témoin ne correspond pas à la version de l'hôte dans le cluster, une partition du cluster vSAN peut se produire.

  1. Mettez à niveau manuellement l'hôte témoin avec la version d'ESXi correspondante à l'aide de la fonctionnalité vCenter VUM.

  2. Remplacez ou déployez le dispositif témoin correspondant à la version d'ESXi.

• La partition vSAN et des alertes critiques sont générées lorsque le MTU témoin n'est pas défini sur 9 000

  Si le MTU du commutateur témoin dans le dispositif témoin n'est pas défini sur 9 000, la partition étendue du cluster vSAN peut se produire.

  Définissez le MTU du commutateur témoin dans le dispositif témoin sur 9 000 MTU.

• Échec de l'ajout d'un hôte à un domaine de charge de travail vLCM configuré avec le gestionnaire de support matériel Dell (OMIVV)

  Lorsque vous essayez d'ajouter un hôte à un cluster vSphere pour un domaine de charge de travail activé avec vSphere Lifecycle Manager (vLCM), la tâche échoue et le journal du gestionnaire de domaine indique « L'hôte (nom de l'hôte) n'est actuellement pas géré par OMIVV ». Les journaux du gestionnaire de domaine sont situés dans /var/log/vmware/vcf/domainmanager sur la VM SDDC Manager.

  Mettez à jour l'inventaire des hôtes dans OMIVV et réessayez la tâche d'ajout d'hôte dans l'interface utilisateur de SDDC Manager. Pour plus d'informations sur la mise à jour de l'inventaire des hôtes dans OMIVV, reportez-vous à la documentation de Dell.

• Échec de l'ajout d'un cluster vSphere ou d'un hôte à un domaine de charge de travail

  Dans certaines circonstances, l'ajout d'un hôte ou d'un cluster vSphere à un domaine de charge de travail échoue à la sous-tâche Configurer le nœud de transport NSX ou Créer une collection de nœuds de transport.

  1. Activez le protocole SSH pour les machines virtuelles NSX Manager.

  2. Ouvrez une session SSH sur les machines virtuelles NSX Manager en tant qu'admin, puis connectez-vous en tant que root.

  3. Exécutez la commande suivante sur chaque machine virtuelle NSX Manager : sysctl -w net.ipv4.tcp_en=0

  4. Connectez-vous à l'interface utilisateur de NSX Manager pour le domaine de charge de travail.

  5. Accédez à Système > Infrastructure > Nœuds > Nœuds de transport d'hôte.

  6. Sélectionnez le serveur vCenter pour le domaine de charge de travail dans le menu déroulant Géré par.

  7. Développez le cluster vSphere et accédez aux nœuds de transport dont l'état est réussite partielle.

  8. Cochez la case en regard d'un nœud dont l'état est réussite partielle, cliquez sur Configurer NSX.

  9. Cliquez sur Suivant puis Appliquer.

  10. Répétez les étapes 7 à 9 pour chaque nœud dont l'état est réussite partielle.

  Lorsque tous les problèmes d'hôte sont résolus, la création du nœud de transport démarre pour les nœuds défaillants. Lorsque tous les hôtes sont créés en tant que nœuds de transport, réessayez la tâche d'ajout de cluster vSphere ou d'ajout d'hôte qui a échoué à partir de l'interface utilisateur de SDDC Manager.

• Le service de performance vSAN n'est pas activé pour les clusters vSAN lorsque le CEIP n'est pas activé

  Si vous n'activez pas le programme d'amélioration du produit (CEIP) VMware dans SDDC Manager, le service de performances vSAN ne sera pas activé pour les clusters vSAN lorsque vous créez un domaine de charge de travail ou que vous ajoutez un cluster vSphere à un domaine de charge de travail. Lorsque le CEIP est activé, les données du service de performance vSAN sont fournies à VMware et elles sont utilisées pour aider le support VMware lors du dépannage et pour des produits tels que VMware Skyline, un Cloud Monitoring Service proactif. Pour plus d'informations sur la collection des données par le CEIP, reportez-vous à la section Programme d'amélioration du produit.

  Activez le CEIP dans SDDC Manager. Reportez-vous à la section Documentation de VMware Cloud Foundation. Une fois le CEIP activé, une tâche planifiée qui active le service de performance vSAN sur des clusters existants dans les domaines de charge de travail s'exécute toutes les trois heures. Le service est également activé pour les nouveaux domaines de charge de travail et les clusters. Pour activer immédiatement le service de performances de vSAN, reportez-vous à la section Documentation de VMware vSphere.

• Échec de la création ou de l'extension d'un cluster vSAN comportant plus de 32 hôtes

  Par défaut, un cluster vSAN peut contenir jusqu'à 32 hôtes. Lorsque la prise en charge de clusters volumineux est activée, un cluster vSAN peut s'étendre jusqu'à un maximum de 64 hôtes. Cependant, même si la prise en charge de clusters volumineux est activée, une tâche de création ou d'extension peut échouer dans la sous-tâche Activer vSAN sur le cluster vSphere.

  1. Activez la prise en charge de clusters volumineux pour le cluster vSAN dans vSphere Client. Si elle est déjà activée, passez à l'étape 2.

     1. Sélectionnez le cluster vSAN dans vSphere Client.

     2. Sélectionnez Configurer > vSAN > Options avancées.

     3. Activez la prise en charge de clusters volumineux.

     4. Cliquez sur Appliquer.

     5. Cliquez sur Oui.

  2. Exécutez un contrôle de santé vSAN pour voir quels hôtes doivent être redémarrés.

  3. Mettez les hôtes en mode maintenance et redémarrez-les.

  Pour plus d'informations sur la prise en charge de clusters volumineux, reportez-vous à la section https://kb.vmware.com/kb/2110081.

• La suppression d'un hôte d'un cluster, la suppression d'un cluster d'un domaine de charge de travail ou la suppression d'un domaine de charge de travail échoue si des VM de service (SVM) sont présentes

  Si vous avez déployé un service de protection de point de terminaison (tel que Guest Introspection) sur un cluster via NSX Data Center, la suppression d'un hôte du cluster, la suppression du cluster ou la suppression du domaine de charge de travail contenant le cluster échouera sur la sous-tâche Passer en mode maintenance sur les hôtes ESXi.

  • Pour supprimer un hôte : Supprimez la VM de service de l'hôte et réessayez l'opération.

  • Pour supprimer un cluster : Supprimez le déploiement de service pour le cluster et réessayez l'opération.

  • Pour supprimer un domaine de charge de travail : Supprimez le déploiement de service pour tous les clusters du domaine de charge de travail et réessayez l'opération.

• vCenter Server remplace le nom de la banque de données NFS lors de l'ajout d'un cluster à un domaine de charge de travail VI

  Si vous ajoutez une banque de données NFS avec un nom différent, mais la même adresse IP de serveur NFS qu'une banque de données NFS qui existe déjà dans le domaine de charge de travail, vCenter Server applique le nom de la banque de données existante à la nouvelle banque de données.

  Si vous souhaitez ajouter une banque de données NFS avec un nom différent, elle doit utiliser une adresse IP de serveur NFS différente.

Problèmes connus de l'API

• Le journal de débogage LCM (lcm-debug.log) reçoit le message d'erreur « does not have a valid product api version string » indésirable

  Ce problème est dû à un problème de format de version des données d'interopérabilité de vRealize. Par conséquent, les journaux se réinitialisent fréquemment.

  Solution : aucune.

  Ce problème sera résolu dans une version ultérieure.

• Une API pour les clusters NSX est répertoriée par erreur dans VMware Cloud Foundation Developer Center

  L'API publique « 2.36.6. Obtenir les zones de transport du cluster NSX » est répertoriée par erreur dans VMware Cloud Foundation Developer Center.

  Solution : Aucun

• Échec de la procédure d'extension du cluster

  Si le cluster que vous étendez ne comporte pas de VM sous tension avec un système d'exploitation installé, l'opération échoue au niveau de la tâche « Valider le cluster pour zéro VM ».

  Avant d'étendre le cluster, assurez-vous qu'il possède une VM sous tension avec un système d'exploitation installé.