Problèmes connus
Cette page décrit les problèmes connus que vous pouvez rencontrer lors de l'utilisation de Google Cloud VMware Engine.
Problèmes d'ordre général
Voici les problèmes généraux connus qui affectent VMware Engine.
Mise à niveau du HCX Manager incorrectement étiquetée comme mise à niveau de la version vSphere
Problème : La mise à niveau du gestionnaire HCX est incorrectement libellée "Mise à niveau de la version vSphere" dans la console Google Cloud .
Détails : Bien que des notifications par e-mail spécifiques identifiant la mise à niveau HCX soient envoyées au moins 14 jours et 24 heures avant l'événement, les notifications automatiques "La mise à jour de votre cloud privé a commencé" et "La mise à jour de votre cloud privé est terminée" reflètent une mise à jour générale du cloud privé. De plus, l'interface de la consoleGoogle Cloud indique explicitement que l'opération est une mise à niveau de la version vSphere. Cette incohérence peut être source de confusion, en particulier pour les clients qui ont récemment effectué une mise à niveau complète de la pile (par exemple, de vSphere 7.x à 8.x), car il semble que l'environnement subisse une autre mise à jour majeure de la plate-forme.
Solution de contournement : Consultez les e-mails de notification spécifiques à HCX envoyés avant la période de maintenance pour confirmer l'étendue des travaux. Si le calendrier correspond, l'état "Mise à niveau de la version vSphere" dans la console Google Cloud fait strictement référence à la mise à jour de HCX Manager. Aucune action n'est requise.
État : il s'agit d'une limitation connue de la conception actuelle du système de notification.
Temps de provisionnement pour les clouds privés vSphere 8.0 Update 3
Problème : VMware Engine déploie désormais de nouveaux clouds privés avec VMware vSphere version 8.0 Update 3 et NSX-T 4.2.1.2. Pendant cette période de mise à niveau, la création et l'expansion de clouds privés utilisent des vitesses de provisionnement standards pour tous les nouveaux déploiements avec les versions mises à jour.
Détails : La création d'un cloud privé peut prendre jusqu'à 140 minutes.
Solution : Aucune solution n'est nécessaire, mais prévoyez un délai supplémentaire lorsque vous déployez de nouveaux clouds privés ou que vous développez des clusters existants.
Détection : vous pouvez observer des délais de déploiement plus longs que d'habitude pour les nouveaux clouds privés ou lorsque vous développez des clusters existants.
État : ce comportement est normal en raison des mises à jour de version et des mises à niveau en cours.
La machine virtuelle avec Windows Server 2022 KB5022842 (version OS 20348.1547) configurée avec le démarrage sécurisé activé ne démarre pas (90947)
Après l'installation de la mise à jour Windows Server 2022 KB5022842 (version OS 20348.1547), l'OS invité ne peut pas démarrer lorsque la ou les machines virtuelles sont configurées avec le démarrage sécurisé activé. Pour contourner ce problème, vous pouvez effectuer l'une des opérations suivantes :
Il existe une limite de 100 préfixes pour les annonces de routage depuis votre cloud privé vers votre réseau VPC.
Si votre annonce de routage dépasse cette limite, certains préfixes peuvent être supprimés. Pour respecter cette limite, mettez en œuvre l'agrégation sur NSX-T Edge.
VMware Engine s'appuie sur les routeurs cloud pour annoncer les plages d'adresses IP (préfixes ou CIDR) de NSX à un réseau VPC de producteur de services. Ces préfixes deviennent des routes dynamiques personnalisées dans le réseau VPC du producteur de services qui est appairé à votre réseau VPC.
Lorsque vous configurez votre réseau VPC de manière à ce qu'il importe des routes dynamiques personnalisées dans cette relation d'appairage, les préfixes NSX appairent des routes personnalisées dans votre réseau VPC. Le nombre de préfixes NSX que vous pouvez importer est limité par deux facteurs :
- La limite par défaut de Cloud Router pour le nombre de préfixes uniques par région, dont VMware Engine hérite
- Le nombre maximal de routes dynamiques dans un groupe d'appairage sur votre réseau VPC
Les opérations sur le cloud privé tentées avant le déploiement complet du cloud privé échouent
Les opérations telles que l'élévation des privilèges, l'expansion du cloud privé et le remplacement des nœuds sont autorisées sur le portail Google Cloud VMware Engine pour les clouds privés opérationnels qui ne sont pas encore entièrement provisionnés. Toutefois, si vous tentez d'effectuer ces opérations dans VMware Engine avant le déploiement du cloud privé (y compris NSX-T et HCX), ces opérations échouent. N'essayez pas d'effectuer ces opérations tant que vous n'avez pas entièrement déployé votre cloud privé.
VMware Engine n'est pas encore entièrement compatible avec VPC Service Controls.
VPC Service Controls implémente une solution provisoire (solution de contournement) pour vous permettre de continuer à utiliser VMware Engine à partir d'un projet dans un périmètre VPC Service Controls. Pour en savoir plus, consultez VPC Service Controls.
Les hôtes ESXi peuvent perdre temporairement la connectivité lors de la collecte des informations de diagnostic.
Les hôtes ESXi dans des environnements avec des appareils NVMe PCIe peuvent perdre temporairement leur connectivité lors de la collecte d'informations de diagnostic.
Origine du problème
Lorsque vous utilisez la commande vm-support ou l'interface utilisateur vCenter pour collecter des informations sur les systèmes ESXi, les journaux sont temporairement stockés dans le répertoire ramdisk /tmp. Si le système comporte de nombreux périphériques NVMe PCIe ou si le fichier journal est volumineux, le répertoire ramdisk /tmp se remplit rapidement, ce qui peut entraîner une perte temporaire de connectivité de votre hôte ESXi jusqu'à la fin de la collecte vm-support.
Solution :
Si vous excluez le fichier manifeste NVME de la section "Sélectionner les journaux" sur la page de création du bundle de journaux, vous empêchez le répertoire ramdisk /tmp de se remplir et vous vérifiez que l'hôte EXSi ne perd pas la connectivité réseau. Pour exclure le fichier manifeste NVMe, procédez comme suit :
- Connectez-vous à vCenter à l'aide du nom d'utilisateur et du mot de passe
cloudowner. - Dans l'inventaire, effectuez un clic droit sur l'instance vCenter Server pour laquelle vous souhaitez définir une exclusion.
- Cliquez sur Exporter les journaux système….
- Sélectionnez l'hôte ESXi dont vous souhaitez exclure le bundle de journaux.
- Sous Sélectionner les journaux, faites défiler la page jusqu'à Stockage, décochez l'option NVMe, puis cliquez sur Journaux exportés. Le fichier manifeste NVMe est désormais exclu.
Pour en savoir plus sur ce correctif, consultez VMware ESXi 7.0 Update 3q.
Erreur de traduction du nom de ressource de cloud privé
Si vous exécutez VMware Engine Horizon (VDI) sur Google Cloud VMware Engine, vous pouvez rencontrer des erreurs après avoir modifié le nom de vos ressources de cloud privé pour qu'il respecte les normes de Google Cloud CLI et de l'API VMware Engine.
L'exemple d'erreur suivant se produit lorsque vous modifiez les noms des ressources de cloud privé sans modifier correctement le provisionnement des pools de postes de travail Horizon :
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No resource pool available for the pool: ic-pool-1
Error during Provisioning Cloning of VM Desktop-UK-005 has failed. No datastores available for the pool: {}ic-pool-1
Pour résoudre ce problème, procédez comme suit avant la date prévue pour la traduction de votre nom :
- Accédez au tableau de bord VMware Horizon.
- Modifiez tous les pools de postes de travail Horizon pour les pools de clones complets et de clones instantanés, et définissez-les sur Désactiver le provisionnement.
Une fois le nom de ressource du cloud privé modifié, procédez comme suit :
Modifiez chaque pool de postes de travail et reconfigurez les paramètres suivants dans l'onglet Paramètres vCenter pour les pools de clones complets et de clones instantanés :
- Pool de ressources
- Datastore
Définissez l'état de chaque pool sur Activer l'approvisionnement.
Testez chaque pool en ajoutant ou en supprimant un bureau du pool pour vérifier que le provisionnement fonctionne correctement.
L'équipe VMware Engine met tout en œuvre pour fournir une solution d'interopérabilité dès que possible. Pour rester informé de la disponibilité des fonctionnalités, contactez l'équipe chargée de votre compte.