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 finden Sie bekannte allgemeine Probleme, die sich auf VMware Engine auswirken.

Integrierte vCenter-pNIC-Fehleralarme werden bei vorübergehenden Netzwerkereignissen ausgelöst

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

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

Problemlösung: Es sind keine Maßnahmen oder Problemumgehungen erforderlich. Da eine Aktualisierung der integrierten vCenter-Alarm-Abtastempfindlichkeit kurzfristig nicht zu erwarten ist, hat Google eine zugrunde liegende Plattformintelligenz bereitgestellt, um diese falsch positiven Ergebnisse zu verwalten und zu filtern. Für gezielte Produktionsumgebungen unterdrückt Google diese integrierten kundenorientierten Console-Benachrichtigungen. Stattdessen überwacht die Google-Analyse-Engine die Infrastrukturdaten und wertet die Bitübertragungsschicht kontinuierlich anhand eines gleitenden Durchschnitts von 30 Minuten aus. Wenn die Analyse-Engine von Google eine dauerhafte physische Beeinträchtigung feststellt, z. B. ein fehlerhaftes Kabel oder eine fehlerhafte Optik, wird der Google-Support automatisch benachrichtigt, um das Problem zu untersuchen und zu beheben. Außerdem erhalten Sie automatisch eine Benachrichtigung.

Status: Dies ist eine bekannte Einschränkung der integrierten vCenter-Alarmauswertungslogik. Google verwaltet dieses Verhalten über eine integrierte, zugrunde liegende Plattformintelligenz. VMware ist dieses Problem bekannt und hat eine Problemumgehung 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 zum HCX-Upgrade gesendet werden, spiegeln die automatischen Benachrichtigungen „Das Update Ihrer privaten Cloud hat begonnen“ und „Das Update Ihrer privaten Cloud wurde abgeschlossen“ ein allgemeines Update der privaten Cloud wider. Außerdem wird der Vorgang in derGoogle Cloud -Konsole explizit als vSphere-Versionsupgrade gekennzeichnet. Diese Abweichung kann zu Verwirrung führen, insbesondere bei Kunden, die vor Kurzem ein vollständiges Stack-Upgrade durchgeführt haben (z. B. vSphere 7.x auf 8.x), da es den Anschein hat, dass die Umgebung ein weiteres großes Plattformupdate durchläuft.

Problemumgehung: Prüfen Sie die HCX-spezifischen E-Mail-Benachrichtigungen, 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 Console 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: 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 für die Erstellung und Erweiterung privater Clouds die Standardbereitstellungsgeschwindigkeiten für alle neuen Bereitstellungen mit den aktualisierten Versionen verwendet.

Details: Das Erstellen einer 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: Möglicherweise stellen Sie längere Bereitstellungszeiten als üblich für neue private Clouds oder beim Erweitern vorhandener Cluster fest.

Status: Dies ist aufgrund der Versionsupdates und laufenden Upgrades das erwartete Verhalten.

Virtuelle Maschine mit Windows Server 2022 KB5022842 (Betriebssystem-Build 20348.1547), die mit aktiviertem Secure Boot konfiguriert ist, startet nicht (90947)

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

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

Für Route Advertisements 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 gelöscht. Um dieses Limit nicht zu überschreiten, implementieren Sie die Aggregation auf NSX-T Edge.

VMware Engine verwendet Cloud Router, um IP-Adressbereiche (Präfixe oder CIDRs) von NSX an ein VPC-Netzwerk des Diensterstellers zu bewerben. 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 gepeert. Die Anzahl der NSX-Präfixe, die Sie importieren können, ist durch zwei Faktoren begrenzt:

Vorgänge in der privaten Cloud, die vor der vollständigen Bereitstellung der privaten Cloud versucht werden, schlagen fehl.

Vorgänge wie Rechteausweitung, Erweiterung der privaten Cloud und Knotenaustausch 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 vollständig bereitgestellt wurde (einschließlich NSX-T und HCX), 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 Zwischenlösung (Workaround), mit der Sie VMware Engine weiterhin innerhalb eines Projekts 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 Internettraffic über eine lokale Verbindung weitergeleitet wird, wird die ausgehende Apigee-Kommunikation möglicherweise auch über Ihre lokale Verbindung weitergeleitet. Diese Konfiguration erfolgt, wenn Sie VPC Service Controls für das Peering servicenetworking.googleapis.com aktivieren, wie unter Internetzugriff 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 für Firewallkonfigurationen die externe IP-Adresse von Apigee verwenden, müssen Sie Ihre Firewallkonfigurationen aktualisieren, um Traffic von Ihrem lokalen Netzwerk zuzulassen.

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

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

Ursache

Wenn Sie den Befehl vm-support oder die vCenter-Benutzeroberfläche verwenden, um Informationen zu ESXi-Systemen zu erfassen, werden die Protokolle vorübergehend im Verzeichnis ramdisk /tmp gespeichert. Wenn das System viele NVMe-PCIe-Geräte hat oder die Logdatei groß ist, füllt sich das Verzeichnis ramdisk /tmp schnell. 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 im 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 von 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 Log-Bundle 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 Fehlerbehebung finden Sie unter VMware ESXi 7.0 Update 3q.

Fehler bei der Übersetzung des Ressourcennamens der privaten Cloud

Wenn Sie VMware Engine Horizon (VDI) in Google Cloud VMware Engine ausführen, können Fehler auftreten, nachdem Sie die Benennung Ihrer privaten Cloud-Ressourcen geändert haben, um die Standards für die Google Cloud CLI und die VMware Engine API zu erfüllen.

Der folgende Beispielfehler tritt auf, wenn Sie die Namen von Ressourcen in der privaten Cloud ändern, ohne die Horizon-Desktop-Pools ordnungsgemäß 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

Führen Sie die folgenden Schritte vor dem geplanten Datum der Namensübersetzung aus, um dieses Problem zu beheben:

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

Führen Sie nach der Änderung des Ressourcennamens der privaten Cloud die folgenden Schritte aus:

  1. Bearbeiten Sie jeden Desktop-Pool und konfigurieren Sie die folgenden Einstellungen auf dem Tab vCenter-Einstellungen für vollständige Klone und Instant-Klone 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 Interoperabilitätslösung bereitzustellen. Wenn Sie über die Verfügbarkeit von Funktionen auf dem neuesten Stand bleiben möchten, wenden Sie sich an Ihr Account-Management-Team.