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 d'ordre général connus qui affectent VMware Engine.
Mise à niveau de HCX Manager incorrectement libellée comme mise à niveau de version vSphere
Problème : La mise à niveau de HCX Manager est incorrectement libellée comme "mise à niveau de version vSphere dans la Google Cloud console.
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 automatisées "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 Google Cloud console indique explicitement que l'opération est une mise à niveau de 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 : Consultez les e-mails de notification spécifiques à HCX envoyés avant l’intervalle de maintenance pour confirmer l’étendue du travail. Si la planification correspond, l' "Mise à niveau de version vSphere" état dans la Google Cloud console 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 de la mise à jour 3 de vSphere 8.0
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 du système d'exploitation 20348.1547) configurée avec le démarrage sécurisé activé ne démarre pas (90947)
Après l'installation de la mise à jour KB5022842 de Windows Server 2022 KB5022842 (version du système d'exploitation 20348.1547) le système d'exploitation 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 procéder de l'une des manières 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.
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 à qu'il importe des routes dynamiques personnalisées dans cette relation d'appairage, les préfixes NSX appaire 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 de 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 met en œuvre 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 la page VPC Service Controls.
Interopérabilité d'Apigee avec le routage Internet sur site
Si vous utilisez Apigee avec l'appairage de VPC sur le même réseau VPC que VMware Engine et que vous configurez VMware Engine pour router le trafic Internet via une connexion sur site, la communication sortante d'Apigee peut également être routée via votre connexion sur site.
Cette configuration se produit lorsque vous activez VPC Service Controls sur l'
servicenetworking.googleapis.com appairage, comme décrit dans
Configurer l'accès à Internet pour les VM de charge de travail.
Si le trafic Apigee est routé via votre connexion sur site, Apigee n'utilise plus son adresse IP externe configurée pour la communication sortante vers les services backend d'API externes. Si vous utilisez l'adresse IP externe d'Apigee pour les configurations de pare-feu, vous devez mettre à jour vos configurations de pare-feu pour autoriser le trafic provenant de votre réseau sur site.
Les hôtes ESXi peuvent perdre temporairement la connectivité lors de la collecte d'informations de diagnostic
Les hôtes ESXi dans les environnements avec des appareils NVMe PCIe peuvent perdre temporairement la 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 appareils 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 :
Exclure le fichier manifeste NVMe de la section "Sélectionner les journaux" de la page de création du bundle de journaux empêche le répertoire ramdisk /tmp de se remplir et vérifie que l'hôte EXSi ne perd pas la connectivité réseau. Pour exclure le manifeste NVMe, procédez comme suit :
- Connectez-vous à vCenter à l'aide du nom d'utilisateur et du mot de passe
cloudowner. - Dans l'inventaire, cliquez avec le bouton droit sur l'instance vCenter Server où vous souhaitez effectuer l'exclusion.
- Cliquez sur Exporter les journaux système….
- Sélectionnez l'hôte ESXi à partir duquel vous souhaitez exclure le bundle de journaux.
- Sous Sélectionner les journaux, faites défiler la page jusqu'à Stockage, puis décochez l'option NVMe et cliquez sur Journaux exportés. Le manifeste NVMe est maintenant exclu.
Pour en savoir plus sur ce correctif, consultez VMware ESXi 7.0 Update 3q.
Erreur de traduction du nom de la 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 votre ressource de cloud privé pour répondre aux 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 bureaux 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 de traduction de nom prévue :
- Accédez au tableau de bord VMware Horizon.
- Modifiez tous les pools de bureaux Horizon pour les pools de clones complets et de clones instantanés, et définissez-les sur Désactiver le provisionnement.
Une fois la modification du nom de la ressource de cloud privé terminée, procédez comme suit :
Modifiez chaque pool de bureaux 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 à nouveau l'état de chaque pool sur Activer le provisionnement.
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.