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 de carte d'interface réseau physique (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 vSphere Client en raison d'anomalies de paquets localisées et temporaires.
Détails : le framework d'alerte VMware intégré évalue les compteurs de carte d'interface réseau physique (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 le bruit transitoire ou le comportement de perte de paquets attendu sur les liaisons montantes vSAN en veille, même lorsque la couche réseau est saine. Grâce à la redondance de chemin intégrée, ces alertes n'ont pas d'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. Étant donné qu'une mise à jour de la sensibilité d'échantillonnage des alarmes vCenter intégrées n'est pas 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 de console intégrées destinées aux clients. Au lieu de cela, le moteur Google Analytics surveille les données d'infrastructure et évalue la couche physique en continu à l'aide d'une moyenne glissante de 30 minutes. Si le moteur d'analyse de Google identifie une dégradation physique persistante, comme un câble ou un élément 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 limite connue de la logique d'évaluation des alarmes vCenter intégrée. Google gère ce comportement grâce à l'intelligence intégrée de la plate-forme sous-jacente. VMware a été informé de ce problème et a recommandé une solution de contournement.
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 l'intervalle 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 constaterez peut-être 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 KB5022842 (version OS 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 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 à 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.
Interopérabilité d'Apigee avec le routage Internet sur site
Si vous utilisez Apigee avec l'appairage de réseaux 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, les communications sortantes d'Apigee peuvent également être acheminées 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 la communication sortante avec les services de backend d'API externes. Si vous vous appuyez sur 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 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 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 Disable Provisioning (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.