Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Google Cloud VMware Engine auftreten können.

Allgemeine Probleme

Im Folgenden sind bekannte allgemeine Probleme aufgeführt, die sich auf VMware Engine auswirken.

Integrierte vCenter-Alarme für pNIC-Fehler werden bei vorübergehenden Netzwerkereignissen ausgelöst

Problem: Integrierte vCenter-Infrastrukturalarme wie „Hohe pNIC-Fehlerrate erkannt“ können in der vSphere Client-Konsole aufgrund vorübergehender lokaler Paketanomalien zeitweise ausgelöst werden.

Details: Das integrierte VMware-Benachrichtigungsframework wertet die zugrunde liegenden Zähler der physischen Netzwerkkarte (pNIC) über kurze, starre Stichprobenfenster aus. Aufgrund dieses Designs kann vCenter sofortige Benachrichtigungen für routinemäßige, nicht schwerwiegende Ereignisse auslösen, z. B. vorübergehendes Rauschen oder erwartetes Paketverlustverhalten auf Standby-vSAN-Uplinks, auch wenn die Netzwerkschicht fehlerfrei ist. Aufgrund der integrierten Pfadredundanz haben diese Benachrichtigungen keine Auswirkungen auf die Verfügbarkeit der Umgebung oder die Datenintegrität.

Problemumgehung: Auf Kundenseite sind keine Maßnahmen oder Problemumgehungen erforderlich. Da kurzfristig keine Aktualisierung der Empfindlichkeit der integrierten vCenter-Alarmstichproben erwartet wird, hat Google eine zugrunde liegende Plattformintelligenz bereitgestellt, um diese Falschmeldungen zu verwalten und zu filtern. Für bestimmte Produktionsumgebungen unterdrückt Google diese integrierten, kundenorientierten Konsolenbenachrichtigungen. Stattdessen werden die Infrastrukturdaten von der Google Analytics-Engine überwacht und die physische Schicht wird kontinuierlich anhand eines gleitenden 30-Minuten-Durchschnitts bewertet. Wenn die Analyse-Engine von Google eine dauerhafte physische Beeinträchtigung feststellt, z. B. ein defektes Kabel oder eine defekte Optik, wird der Google-Support automatisch benachrichtigt, damit er das Problem untersucht und behebt. Außerdem erhalten Sie automatisch eine Benachrichtigung.

Status: Dies ist eine bekannte Einschränkung der integrierten vCenter-Logik zur Alarmauswertung. Google verwaltet dieses Verhalten durch integrierte, zugrunde liegende Plattformintelligenz. VMware ist dieses Problem bekannt und hat einen Workaround empfohlen.

HCX Manager-Upgrade fälschlicherweise als vSphere-Versionsupgrade gekennzeichnet

Problem: Das HCX Manager-Upgrade wird in der Google Cloud Konsole fälschlicherweise als „vSphere-Versionsupgrade“ bezeichnet.

Details: Obwohl mindestens 14 Tage und 24 Stunden vor dem Ereignis spezifische E‑Mail-Benachrichtigungen gesendet werden, in denen das HCX-Upgrade angegeben ist, beziehen sich die automatisierten Benachrichtigungen „Ihr Private Cloud-Update wurde gestartet“ und „Ihr Private Cloud-Update wurde abgeschlossen“ auf ein allgemeines Private Cloud-Update. Außerdem wird der Vorgang auf derGoogle Cloud -Konsolenschnittstelle explizit als vSphere-Versionsupgrade gekennzeichnet. Diese Diskrepanz kann zu Verwirrung führen, insbesondere bei Kunden, die vor Kurzem ein vollständiges Stack-Upgrade durchgeführt haben (z. B. von vSphere 7.x auf 8.x), da es so aussieht, als würde die Umgebung ein weiteres großes Plattform-Update durchlaufen.

Problemumgehung: Prüfen Sie die HCX-spezifischen Benachrichtigungs-E-Mails, die vor dem Wartungsfenster gesendet wurden, um den Umfang der Arbeiten zu bestätigen. Wenn der Zeitplan übereinstimmt, bezieht sich der Status „vSphere-Versionsupgrade“ in der Google Cloud -Konsole ausschließlich auf das HCX Manager-Update. Sie müssen nichts weiter tun.

Status: Dies ist eine bekannte Einschränkung des aktuellen Benachrichtigungssystems.

Bereitstellungszeit für private Clouds mit vSphere 8.0 Update 3

Problem: In VMware Engine werden neue private Clouds jetzt mit VMware vSphere Version 8.0 Update 3 und NSX-T 4.2.1.2 bereitgestellt. Während dieses Upgradezeitraums werden private Clouds mit den aktualisierten Versionen mit Standardbereitstellungsgeschwindigkeiten erstellt und erweitert.

Details: Die Erstellung der privaten Cloud kann bis zu 140 Minuten dauern.

Problemumgehung: Es ist keine Problemumgehung erforderlich. Planen Sie jedoch zusätzliche Zeit ein, wenn Sie neue private Clouds bereitstellen oder vorhandene Cluster erweitern.

Erkennung: Die Bereitstellungszeiten für neue private Clouds oder beim Erweitern vorhandener Cluster können länger als gewöhnlich sein.

Status: Das ist aufgrund der Versionsupdates und laufenden Upgrades normal.

VM mit Windows Server 2022 KB5022842 (OS Build 20348.1547), die mit aktiviertem Secure Boot konfiguriert wurde, wird nicht gestartet (90947)

Nach der Installation des Windows Server 2022-Updates KB5022842 (OS Build 20348.1547) kann das Gastbetriebssystem nicht gestartet werden, wenn die VM(s) mit aktiviertem Secure Boot konfiguriert ist. Sie haben folgende Möglichkeiten, dieses Problem zu umgehen:

  • Überspringen Sie KB5022842 und verwenden Sie KB5023705.
  • „Secure Boot“ auf betroffenen VMs deaktivieren

Für das Route Advertisement von Ihrer privaten Cloud zu Ihrem VPC-Netzwerk gilt ein Limit von 100 Präfixen.

Wenn Ihr Route Advertisement dieses Limit überschreitet, werden einige Präfixe möglicherweise weggelassen. Implementieren Sie die Aggregation auf NSX-T Edge, um innerhalb dieses Limits zu bleiben.

VMware Engine benötigt Cloud Router, um IP-Adressbereiche (Präfixe oder CIDRs) von NSX einem VPC-Netzwerk eines Diensterstellers anzubieten. Diese Präfixe werden zu benutzerdefinierten dynamischen Routen im Dienstersteller-VPC-Netzwerk, das per Peering mit Ihrem VPC-Netzwerk verbunden ist.

Wenn Sie Ihr VPC-Netzwerk so konfigurieren, dass benutzerdefinierte dynamische Routen in dieser Peering-Beziehung importiert werden, werden die NSX-Präfixe als benutzerdefinierte Routen in Ihrem VPC-Netzwerk per Peering verbunden. Die Anzahl der NSX-Präfixe, die Sie importieren können, ist durch zwei Faktoren begrenzt:

Vorgänge für die private Cloud, die vor der vollständigen Bereitstellung der privaten Cloud ausgeführt werden, schlagen fehl

Vorgänge wie die Rechteausweitung, die Erweiterung der Private Cloud und das Ersetzen von Knoten sind im Google Cloud VMware Engine-Portal für Private Clouds zulässig, die noch nicht vollständig bereitgestellt wurden. Wenn Sie diese Vorgänge jedoch in VMware Engine ausführen, bevor die Private Cloud (einschließlich NSX-T und HCX) vollständig bereitgestellt wurde, schlagen diese Vorgänge fehl. Führen Sie diese Vorgänge erst aus, wenn Sie Ihre Private Cloud vollständig bereitgestellt haben.

VMware Engine wird noch nicht vollständig von VPC Service Controls unterstützt.

VPC Service Controls bietet eine Übergangslösung (Workaround), mit der Sie VMware Engine weiterhin über ein Projekt in einem VPC Service Controls-Perimeter nutzen können. Weitere Informationen finden Sie unter VPC Service Controls.

Apigee-Interoperabilität mit lokalem Internetrouting

Wenn Sie Apigee mit VPC-Peering im selben VPC-Netzwerk wie VMware Engine verwenden und VMware Engine so konfigurieren, dass Internet-Traffic über eine lokale Verbindung weitergeleitet wird, kann es sein, dass auch die ausgehende Kommunikation von Apigee über Ihre lokale Verbindung weitergeleitet wird. Diese Konfiguration erfolgt, wenn Sie VPC Service Controls für das servicenetworking.googleapis.com-Peering aktivieren, wie unter Internetzugang für Arbeitslast-VMs konfigurieren beschrieben.

Wenn Apigee-Traffic über Ihre lokale Verbindung weitergeleitet wird, verwendet Apigee nicht mehr die konfigurierte externe IP-Adresse für die ausgehende Kommunikation mit externen API-Backend-Diensten. Wenn Sie sich bei Firewallkonfigurationen auf die externe IP-Adresse von Apigee verlassen, müssen Sie Ihre Firewallkonfigurationen aktualisieren, um Traffic von Ihrem lokalen Netzwerk zuzulassen.

ESXi-Hosts verlieren während der Erfassung von Diagnoseinformationen möglicherweise vorübergehend die Verbindung

ESXi-Hosts in Umgebungen mit NVMe-PCIe-Geräten verlieren möglicherweise vorübergehend die Verbindung während der Erfassung von Diagnoseinformationen.

Ursache

Wenn Sie den vm-support-Befehl oder die vCenter-UI verwenden, um Informationen zu ESXi-Systemen zu erfassen, werden Logs vorübergehend im Verzeichnis ramdisk /tmp gespeichert. Wenn das System viele NVMe-PCIe-Geräte hat oder die Protokolldatei groß ist, wird das Verzeichnis ramdisk /tmp schnell voll. Dies kann dazu führen, dass Ihr ESXi-Host vorübergehend die Verbindung verliert, bis die vm-support-Sammlung abgeschlossen ist.

Behelfslösung:

Wenn Sie das NVME-Manifest auf der Seite zum Erstellen des Log-Bundles aus dem Abschnitt „Logs auswählen“ ausschließen, wird verhindert, dass das Verzeichnis ramdisk /tmp voll wird, und es wird geprüft, ob der EXSi-Host die Netzwerkverbindung verliert. So schließen Sie das NVMe-Manifest aus:

  1. Melden Sie sich mit dem Nutzernamen und Passwort für cloudowner in vCenter an.
  2. Klicken Sie im Inventar mit der rechten Maustaste auf die vCenter Server-Instanz, für die Sie den Ausschluss festlegen möchten.
  3. Klicken Sie auf Systemprotokolle exportieren….
  4. Wählen Sie den ESXi-Host aus, von dem Sie das Protokollpaket ausschließen möchten.
  5. Scrollen Sie unter Logs auswählen zu Speicher und deaktivieren Sie die Option NVMe. Klicken Sie dann auf Exportierte Logs. Das NVMe-Manifest ist jetzt ausgeschlossen.

Weitere Informationen zu diesem Fix finden Sie unter VMware ESXi 7.0 Update 3q.

Übersetzungsfehler beim Namen der Ressource für die private Cloud

Wenn Sie VMware Engine Horizon (VDI) in Google Cloud VMware Engine ausführen, können nach dem Ändern der Benennung Ihrer privaten Cloud-Ressourcen, um den Standards für die Google Cloud CLI und die VMware Engine API zu entsprechen, Fehler auftreten.

Der folgende Beispielfehler tritt auf, wenn Sie Namen von Ressourcen in der privaten Cloud ändern, ohne die Bereitstellung von Horizon-Desktop-Pools richtig zu bearbeiten:

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

So beheben Sie das Problem vor dem geplanten Datum der Namensübersetzung:

  1. Greifen Sie auf das VMware Horizon-Dashboard zu.
  2. Bearbeiten Sie alle Horizon-Desktoppools für Pools mit vollständigen Klonen und Instant Clones und legen Sie sie auf Disable Provisioning (Bereitstellung deaktivieren) fest.

Nachdem die Namensänderung der privaten Cloud-Ressource abgeschlossen ist, führen Sie die folgenden Schritte aus:

  1. Bearbeiten Sie jeden Desktop-Pool und konfigurieren Sie die folgenden Einstellungen auf dem Tab vCenter-Einstellungen für Full Clone- und Instant Clone-Pools neu:

    • Ressourcenpool
    • Datastore

  2. Setzen Sie den Status jedes Pools wieder auf Bereitstellung aktivieren.

  3. Testen Sie jeden Pool, indem Sie einen Desktop hinzufügen oder entfernen, um zu prüfen, ob die Bereitstellung ordnungsgemäß funktioniert.

Das VMware Engine-Team arbeitet aktiv daran, so schnell wie möglich eine Lösung für die Interoperabilität zu finden. Wenden Sie sich an Ihr Account-Management-Team, um über die Verfügbarkeit von Funktionen auf dem Laufenden zu bleiben.