Bekannte Probleme

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

Allgemeine Probleme

Die folgenden allgemeinen Probleme sind bekannt und betreffen VMware Engine.

Fehleralarme für integrierte vCenter-pNIC 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 Paketabweichungen zeitweise ausgelöst werden.

Details: Das integrierte VMware-Benachrichtigungsframework wertet die zugrunde liegenden Zähler der physischen Netzwerkkarte (pNIC) in kurzen, starren Stichprobenfenstern aus. Aufgrund dieses Designs kann vCenter sofort Alarme für routinemäßige, nicht schwerwiegende Ereignisse auslösen, z. B. vorübergehende Störungen oder erwartetes Paketverlustverhalten bei vSAN-Standby-Uplinks, auch wenn die Netzwerkschicht fehlerfrei ist. Aufgrund der integrierten Pfadredundanz haben diese Alarme keine Auswirkungen auf die Verfügbarkeit der Umgebung oder die Datenintegrität.

Behelfslösung: Auf Kundenseite sind keine Maßnahmen oder Behelfslösungen erforderlich. Da kurzfristig keine Aktualisierung der Stichprobenempfindlichkeit für integrierte vCenter-Alarme erwartet wird, hat Google eine zugrunde liegende Plattformintelligenz bereitgestellt, um diese falsch positiven Ergebnisse zu verwalten und zu filtern. Für bestimmte Produktionsumgebungen unterdrückt Google diese integrierten, kundenorientierten Konsolenalarme. Stattdessen überwacht die Google-Analyse-Engine Infrastrukturdaten und wertet die physische Schicht kontinuierlich mit einem gleitenden 30-Minuten-Durchschnitt aus. Wenn die Analyse-Engine von Google eine anhaltende physische Verschlechterung feststellt, z. B. ein fehlerhaftes Kabel oder eine fehlerhafte Optik, benachrichtigt die Plattform automatisch den Google-Support, damit das Problem untersucht und behoben wird. Außerdem wird Ihnen automatisch eine Benachrichtigung gesendet.

Status: Dies ist eine bekannte Einschränkung der integrierten vCenter-Alarmbewertungs logik. Google verwaltet dieses Verhalten über die integrierte, zugrunde liegende Plattformintelligenz. VMware ist dieses Problem bekannt und hat eine Behelfslösung empfohlen.

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

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

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 automatischen Benachrichtigungen „Das Update Ihrer privaten Cloud wurde gestartet“ und „Das Update Ihrer privaten Cloud ist abgeschlossen“ auf ein allgemeines Update der privaten Cloud. Außerdem wird der Google Cloud Vorgang in der Konsolenschnittstelle explizit als vSphere-Version upgrade bezeichnet. 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 eine weitere größere Plattformaktualisierung durchgeführt.

Behelfslösung: 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. Es sind keine Maßnahmen erforderlich.

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

Bereitstellungszeit für private Clouds mit vSphere 8.0 Update 3

Problem: VMware Engine stellt jetzt neue private Clouds mit VMware vSphere Version 8.0 Update 3 und NSX-T 4.2.1.2 bereit. Während dieses Upgradezeitraums werden bei der Erstellung und Erweiterung privater Clouds für alle neuen Bereitstellungen mit den aktualisierten Versionen die Standardgeschwindigkeiten für die Bereitstellung verwendet.

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

Behelfslösung: Es ist keine Behelfslösung 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: Dies ist aufgrund der Versionsupdates und laufenden Upgrades das erwartete Verhalten.

VM mit Windows Server 2022 KB5022842 (Betriebssystembuild 20348.1547) mit aktiviertem sicheren Start wird nicht gestartet (90947)

Nach der Installation des Windows Server 2022-Updates KB5022842 (Betriebssystembuild 20348.1547) kann das Gastbetriebssystem nicht gestartet werden, wenn für die virtuellen Maschinen der sichere Start aktiviert ist. Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

  • KB5022842 überspringen und KB5023705 verwenden
  • „Sicherer Start“ auf den 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 das VPC-Netzwerk für den Import benutzerdefinierter dynamischer Routen in dieser Peering-Beziehung konfigurieren, werden die benutzerdefinierten Routen innerhalb des VPC-Netzwerks von NSX-Präfixen vorangestellt. Die Anzahl der NSX-Präfixe, die Sie importieren können, ist durch zwei Faktoren begrenzt:

Private Cloud-Vorgänge, 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 betriebsbereite 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 implementiert eine Übergangslösung (Behelfslösung), damit Sie VMware Engine weiterhin in einem Projekt in einem VPC Service Controls-Perimeter verwenden 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 der Internettraffic über eine lokale Verbindung weitergeleitet wird, kann auch die ausgehende Kommunikation von Apigee über Ihre lokale Verbindung weitergeleitet werden. Diese Konfiguration tritt auf, wenn Sie VPC Service Controls für das servicenetworking.googleapis.com Peering aktivieren, wie unter Internetzugang für Arbeitslast-VMs konfigurieren beschrieben.

Wenn der Apigee-Traffic über Ihre lokale Verbindung weitergeleitet wird, verwendet Apigee die konfigurierte externe IP-Adresse nicht mehr 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 möglicherweise vorübergehend die Verbindung während der Erfassung von Diagnosedaten

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

Ursache

Wenn Sie mit dem Befehl vm-support oder der vCenter-UI Informationen zu ESXi-Systemen erfassen, werden die Logs vorübergehend im Verzeichnis ramdisk /tmp gespeichert. Wenn das System viele NVMe-PCIe-Geräte hat oder die Logdatei groß ist, ist das Verzeichnis ramdisk /tmp schnell voll. Dies kann dazu führen, dass die Verbindung zu Ihrem ESXi-Host vorübergehend unterbrochen wird, bis die Erfassung mit vm-support abgeschlossen ist.

Behelfslösung:

Wenn Sie das NVMe-Manifest im Abschnitt „Logs auswählen“ auf der Seite zum Erstellen von Logpaketen ausschließen, wird verhindert, dass das Verzeichnis ramdisk /tmp voll wird, und es wird sichergestellt, dass die Netzwerkverbindung zum ESXi-Host nicht unterbrochen wird. So schließen Sie das NVMe-Manifest aus:

  1. Melden Sie sich mit dem Nutzernamen und Passwort cloudowner in vCenter an.
  2. Klicken Sie im Inventar mit der rechten Maustaste auf die vCenter Server-Instanz, für die Sie den Ausschluss vornehmen möchten.
  3. Klicken Sie auf Systemprotokolle exportieren….
  4. Wählen Sie den ESXi-Host aus, für den Sie das Logpaket 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 dieser Korrektur finden Sie unter VMware ESXi 7.0 Update 3q.

Übersetzungsfehler für Ressourcennamen privater Clouds

Wenn Sie VMware Engine Horizon (VDI) in Google Cloud VMware Engine ausführen, können Fehler auftreten, nachdem Sie die Namen Ihrer privaten Cloud-Ressourcen so geändert haben, dass sie den Standards für die Google Cloud CLI und die VMware Engine API entsprechen.

Der folgende Fehler tritt auf, wenn Sie die Namen der privaten Cloud-Ressourcen ändern, ohne die Bereitstellung von Horizon-Desktoppools 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: Führen Sie die folgenden Schritte vor dem geplanten Datum für die Namensübersetzung aus:

  1. Greifen Sie auf das VMware Horizon-Dashboard zu.
  2. Bearbeiten Sie alle Horizon-Desktoppools für Full Clone- und Instant Clone-Pools und legen Sie sie auf Bereitstellung deaktivieren fest.

Nachdem die Änderung des Ressourcennamens der privaten Cloud abgeschlossen ist, führen Sie die folgenden Schritte aus:

  1. Bearbeiten Sie jeden Desktoppool 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 der einzelnen 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 Interoperabilitätslösung bereitzustellen. Wenn Sie über die Verfügbarkeit von Funktionen auf dem Laufenden bleiben möchten, wenden Sie sich an Ihr Account-Management-Team.