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.
Les alarmes d'erreur pNIC vCenter intégrées se déclenchent lors d'événements réseau temporaires
Problème : Les alarmes d'infrastructure vCenter intégrées, telles que "Taux d'erreur pNIC élevé détecté", peuvent se déclencher par intermittence dans la console du client vSphere en raison d'anomalies de paquets localisées temporaires.
Détails : Le framework d'alerte VMware intégré évalue les compteurs de cartes d'interface réseau physiques (pNIC) sous-jacents sur des fenêtres d'échantillonnage courtes et rigides. En raison de cette conception, vCenter peut déclencher des alertes immédiates pour des événements de routine sans impact, tels que du bruit temporaire ou un comportement de perte de paquets attendu sur les liaisons montantes vSAN de secours, même lorsque la couche réseau est opérationnelle. En raison de la redondance intégrée des chemins d'accès, ces alertes n'ont aucune incidence sur la disponibilité de l'environnement ni sur l'intégrité des données.
Solution : aucune action ni solution n'est requise de la part du client. Comme aucune mise à jour de la sensibilité d'échantillonnage des alarmes vCenter intégrées n'est prévue à court terme, Google a déployé une intelligence de plate-forme sous-jacente pour gérer et filtrer ces faux positifs. Pour les environnements de production ciblés, Google supprime ces alertes intégrées de la console destinées aux clients. À la place, le moteur d'analyse Google Analytics surveille les données d'infrastructure et évalue la couche physique en continu à l'aide d'une moyenne glissante sur 30 minutes. Si le moteur d'analyse de Google identifie une dégradation physique persistante, comme un câble ou un composant optique défectueux, la plate-forme alerte automatiquement l'assistance Google pour qu'elle examine et résolve le problème, et vous envoie systématiquement une notification automatisée.
État : il s'agit d'une limitation connue de la logique d'évaluation des alarmes vCenter intégrée. Google gère ce comportement via une intelligence de plate-forme intégrée et sous-jacente. VMware est au courant de ce problème et a proposé une solution de contournement.
La mise à niveau de HCX Manager est incorrectement étiquetée comme une mise à niveau de version vSphere
Problème : la mise à niveau de HCX Manager est incorrectement étiquetée comme "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 de vSphere. Cette incohérence peut prêter à 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 vers 8.x), car il semble que l'environnement subit une autre mise à jour majeure de la plate-forme.
Solution : examinez les e-mails de notification spécifiques à HCX envoyés avant l'intervalle de maintenance pour confirmer l'étendue des travaux. Si la planification est alignée, 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 des 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, mise à jour 3 et NSX-T 4.2.1.2. Pendant cette période de mise à niveau, la création et l'extension 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 du temps supplémentaire lorsque vous déployez de nouveaux clouds privés ou étendez des clusters existants.
Détection : vous pouvez observer des temps de déploiement plus longs que d'habitude pour les nouveaux clouds privés ou lorsque vous étendez 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 (OS Build 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 (OS Build 20348.1547) de Windows Server 2022, 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 de 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 ne pas dépasser cette limite, implémentez 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 pour importer des routes dynamiques personnalisées dans cette relation d'appairage, les préfixes NSX appairent les routes personnalisées dans votre réseau VPC. Le nombre de préfixes NSX que vous pouvez importer est limité par deux facteurs :
- Limite par défaut de Cloud Router pour le nombre de préfixes uniques par région, dont VMware Engine hérite
- Nombre maximal de routes dynamiques dans un groupe de peering 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'extension du cloud privé et le remplacement de nœuds sont autorisées dans le portail Google Cloud VMware Engine sur 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 que le cloud privé ne soit entièrement déployé (y compris NSX-T et HCX), elles é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 situé dans un périmètre VPC Service Controls. Pour en savoir plus, consultez 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 acheminer le trafic Internet via une connexion sur site, la communication sortante Apigee peut également être acheminée via votre connexion sur site.
Cette configuration se produit lorsque vous activez VPC Service Controls sur l'appairage servicenetworking.googleapis.com, comme décrit dans Configurer l'accès à Internet pour les VM de charge de travail.
Si le trafic Apigee est acheminé via votre connexion sur site, Apigee n'utilise plus son adresse IP externe configurée pour les communications sortantes vers les services de 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 des informations de diagnostic
Les hôtes ESXi dans des environnements dotés d'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'à ce que la collecte vm-support soit terminée.
Solution :
L'exclusion du fichier manifeste NVME de la section des journaux sélectionnés sur 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 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 où vous souhaitez appliquer l'exclusion.
- Cliquez sur Export System Logs... (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 et 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 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é la dénomination de vos ressources 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 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 des noms :
- 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, puis définissez-les sur Désactiver le provisionnement.
Une fois le changement de nom de la ressource de cloud privé terminé, 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
Rétablissez 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.