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.

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: Sehen Sie sich die HCX-spezifischen Benachrichtigungs-E-Mails an, 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 Standardgeschwindigkeit bereitgestellt und erweitert.

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

Workaround: 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.

Virtuelle Maschine mit Windows Server 2022 KB5022842 (OS Build 20348.1547), die mit aktiviertem Secure Boot konfiguriert ist, 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:

  • KB5022842 überspringen und KB5023705 verwenden
  • „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 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:

Vorgänge für die private Cloud, die ausgeführt werden, bevor die private Cloud vollständig bereitgestellt wurde, schlagen fehl

Vorgänge wie die Eskalation von Berechtigungen, 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.

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 Befehl vm-support 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, füllt sich das Verzeichnis ramdisk /tmp schnell, was dazu führen kann, 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 „Ausgewählte Logs“ 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 privaten Cloud-Ressource

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:

  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 Settings (vCenter-Einstellungen) für Pools mit vollständigen Klonen und Instant Clones 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. Wenn Sie über die Verfügbarkeit von Funktionen auf dem Laufenden bleiben möchten, wenden Sie sich an Ihr Account-Management-Team.