VMware Integrated OpenStack 7.1 | 13. MAI 2021 | Build-OVA 17987092, Patch 17987093 Überprüfen Sie, ob diese Versionshinweise ergänzt oder aktualisiert wurden.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Informationen zu VMware Integrated OpenStack
• Neuheiten
• Upgrade auf Version 7.1
• Kompatibilität
• Hinweise zu veralteten Funktionen
• Behobene Probleme
• Bekannte Probleme

Informationen zu VMware Integrated OpenStack

Mit VMware Integrated OpenStack wird die Bereitstellung einer OpenStack-Cloud-Infrastruktur durch die Optimierung des Integrationsprozesses erheblich vereinfacht. VMware Integrated OpenStack bietet sofort einsatzbereite OpenStack-Funktionalität und einen einfachen Konfigurations-Workflow mithilfe eines Bereitstellungsmanagers, der als virtuelle Appliance in vCenter Server ausgeführt wird.

Neuheiten

• Unterstützung für die neuesten Versionen der VMware-Produkte: 
  • VMware Integrated OpenStack 7.1 ist vollständig kompatibel mit VMware vSphere 7.0 U2, NSX-T 3.1.1 und NSX-V 6.4.10
• Neue Funktionen und Verbesserungen:
  • Verwaltungsebene
    • Unterstützung der Notfallwiederherstellung für die VIO-Verwaltungsebene. Bietet einen neuen viocli-Befehl zur Unterstützung der Wiederherstellung der Verwaltungsebene nach einem Notfall. Der vollständige Notfallwiederherstellungsvorgang wird mit der SRM-, vSphere Replication- und NSX-T-Multisite-Funktion validiert, die Nova-Instanzen, Cinder-Volumes und Neutron-Netzwerke abdeckt. Nachdem die Bereitstellung auf der DR-Ziel-Site wiederhergestellt wurde, können Benutzer VIO zum Verwalten der wiederhergestellten Nova-, Cinder- oder Neutron-Objekte verwenden.
    • Unterstützung der Migration vom Neutron NSX-T-Verwaltungs-Plug-In zum Policy-Plug-In. 
    • Es werden mehrere Lizenzschlüssel unterstützt: Dies ermöglicht, dass der Administrator mehrere VIO-Lizenzschlüssel eingibt und diese zur Nutzung zuweist.
  • OpenStack-Treiber:
    • Unterstützung für Octavia-Typen. Mit dieser Funktion können Benutzer die OpenStack Octavia-Typen für von VIO on NSX-T erstellte Lastausgleichsdienste verwenden. Diese Funktion wird vom Neutron NSX-P-Plug-In und in Verbindung mit NSX-T 3.1 oder höher unterstützt.
  • Skalierbarkeit:
    • Unterstützung einer größeren Skalierbarkeit. Eine VIO-Bereitstellung kann jetzt bis zu 128 Nova Compute-Knoten und bis zu 10.000 Mandantennetzwerke mit dem Neutron NSX-T Policy-Plug-In sowie einen Verbund von bis zu 8 VIO-Bereitstellungen mit vIDM als Identitätsanbieter unterstützen.

Upgrade auf Version 7.1

• Führen Sie ein Upgrade von Version 7.0/7.0.1 durch und verwenden Sie dazu den Befehl viocli patch. Detaillierte Anweisungen finden Sie im Produktinstallationshandbuch.
• Führen Sie ein Upgrade von Version 6.0 durch. Verwenden Sie das im Produktinstallationshandbuch beschriebene Verfahren eines Blau/Grün-Upgrade.
• VIO 7.1 unterstützt kein direktes Upgrades von Version 5.x. Führen Sie zunächst ein Upgrade auf Version 7.0.1 durch.

Kompatibilität

• Detaillierte Informationen zur Kompatibilität von VMware Integrated OpenStack mit anderen VMware-Produkten finden Sie in den VMware-Produktinteroperabilitätsmatrizen.

Hinweise zu veralteten Funktionen 

• Die folgenden Netzwerkfunktionen sind veraltet und werden in der nächsten VIO-Version entfernt:
  • Der NSX Data Center for vSphere-Treiber für Neutron.
  • Das NSX-T-Verwaltungs-Plug-In für Neutron wird durch das NSX-T Policy-Plug-In ersetzt.
  • Das TVD-Plug-In, mit dem eine einzelne VMware Integrated OpenStack-Bereitstellung ein NSX Data Center for vSphere-Back-End und ein NSX-T Data Center-Back-End verwenden kann.
• Die Neutron FWaaSv2 wird in einer zukünftigen Version veraltet sein.

Behobene Probleme

Die behobenen Probleme werden in folgende Kategorien unterteilt.

• Behobene Probleme bei der VIO-Verwaltung
• Behobene Probleme bei OpenStack

Behobene Probleme bei der VIO-Verwaltung

• 2750794 behoben: Die Sicherungsdaten wurden gelöscht, wenn der VIO-Administrator den VIO-Sicherungsplanauftrag löschte.

  Wenn der Administrator in VIO 7.0 den VIO-Sicherungsplanauftrag löschte, wurden die in der vCenter-Inhaltsbibliothek gespeicherten Sicherungsdaten ebenfalls gelöscht.
  In VIO 7.1 werden die Sicherungsdaten beim Löschen des Sicherungsplanungsauftrags nicht gelöscht.

• 2738659 behoben: Der Vorgang zur Wiederherstellung der VIO-Sicherung funktionierte nicht ordnungsgemäß, wenn vCenter-SSL aktiviert war.

  Der Vorgang zur Wiederherstellung der VIO-Sicherung funktionierte nicht ordnungsgemäß, wenn vCenter-SSL aktiviert war. Die Sicherungsdaten konnten nicht in die Inhaltsbibliothek von vCenter hochgeladen werden, und es wurde ein Fehler des Typs „x509: Unbekannte Zertifizierungsstelle des Zertifikats“ angezeigt.

• 2680755 behoben: Der VIO-Bereitstellungsassistent kann nicht fortgesetzt werden, und ein Fehler ähnlich dem folgenden wird angezeigt: „Zeitüberschreitung beim Laden der vCenter-Ressourcen“.

  VIO 7 verwendet govmomi zum Abrufen von vCenter Bestandslisteninformationen. Bei govmomi tritt ein Notfallalarm auf, wenn DistributedVirtualPortgroup „MAC“ oder „Systemdatenverkehr“ als Datenverkehrsbezeichner für das Filtern und Markieren des Datenverkehrs in der vSphere-Zielumgebung aufweist.

• 2677748 behoben: Die Web-Benutzeroberfläche von VIO Manager kann den Status der OpenStack-Dienste nicht auflisten.

  Die Web-Benutzeroberfläche von VIO Manager kann das Drehrad für Dienste nicht anzeigen, und es ist nur die Meldung „Keine Ressourcen gefunden“ zu sehen.

• 2591794 behoben: Der Metadatendienst ist in der NSX-V-Umgebung nicht erreichbar.

  Der Metadatendienst ist nicht erreichbar, wenn der Metadaten-Proxy-Edge vom VMware Integrated OpenStack-API-Netzwerk aus nicht geroutet werden kann. VIO 7.1 erreicht den Metadaten-Proxy in diesem Fall automatisch über die Verwaltungs-API.

• 2688209 behoben: Das VIO-Support-Paket enthält Protokollinformationen nur für ca. zwei Tage.

  In VIO 6.0 und 7.0 kann das Support-Paket nur die Protokollinformationen für etwa zwei Tage enthalten. Diese Protokollinformationen reichen für die Fehlerbehebung nicht aus. Um dieses Problem zu beheben, ermöglicht VIO 7.1 automatisch generierte Protokollsicherungen, sodass der Zeitraum für die Protokollaufbewahrung auf bis zu sieben Tage erhöht werden kann.

• 2707205 behoben: VIO 6/7 legte „rp_filter“ auf Controller-Knoten nicht auf den flexiblen Modus fest.

  VIO 6/7 wurde auf PhotonOS umgestellt und legte „rp_filter“ auf Controller-Knoten nicht explizit fest. Dies bedeutet, dass der Wert standardmäßig auf „1“ (RFC3704 – strenger Modus) festgelegt wird. Anwendungen im Verwaltungsnetzwerk können möglicherweise keine Verbindung zu den öffentlichen Endpoints herstellen, da der strenge Modus dazu führt, dass Pakete verworfen werden.

• 2631412 behoben: Die grafische Benutzeroberfläche von VIO verwendet ein Zertifikat mit dem Namen „Kubernetes Ingress Controller Fake Certificate“.

  Der Zertifikatsname ist der vom Nginx-Ingress-Controller erstellte Standardname. Wenn Sie ein Upgrade auf VIO 7.1 durchführen, wird es durch ein Zertifikat mit einem ordnungsgemäßen Namen ersetzt. 

Behobene Probleme bei OpenStack

• 2594923 behoben: Die Eigenschaft „vmware_cpu_affinity“ des Glance-Images funktioniert nicht.

  Die Eigenschaft „vmware_cpu_affinity“ des Glance-Images funktioniert nicht. Bei der Verwendung eines solchen Glance-Images zum Erstellen von Nova-Instanzen tritt sinngemäß folgender Fehler auf: „Fehler: Im Feld „vmware_cpu_affinity“ ist eine Liste erforderlich, und keine Zeichenfolge (HTTP 400)“

  In VIO 7.1 könnte die Eigenschaft wie folgt festgelegt werden:

  openstack image set --property vmware_cpu_affinity="[0,1]" image_name

• 2753879 behoben: Heat-Stack konnte aufgrund einer fwaas v1-Erweiterung nicht aktualisiert werden.

  Upstream-Heat verwendet weiterhin fwaas v1 und unterstützt fwaas v2 nicht. VIO 7 unterstützt jedoch nur fwaas v2.

• 2713308 behoben: Die nicht verwendeten Glance Basisimages sammeln sich im Nova-Cache-Ordner an.

  Die nicht verwendeten Glance Basisimages sammeln sich im Nova-Cache-Ordner an. Der Backend-Vorgang zum Bereinigen nicht verwendeter Images funktioniert nicht ordnungsgemäß.

• 2710808 behoben: VIO 7 unterstützt nur einen ns_record im Designate-Pool.

  VIO 7 unterstützt nur einen ns_record im Designate-Pool. Dies wurde in VIO 7.1 verbessert, sodass mehrere ns_records in Designate unterstützt werden.

• 2707581 behoben: Wenn eine QoS-Richtlinie als Standard konfiguriert ist, verwendet das externe Netzwerk diese QoS-Richtlinie ebenfalls.

  Wenn eine bestimmte QoS-Richtlinie als Standard konfiguriert ist, verwendet das externe Netzwerk diese QoS-Richtlinie ebenfalls. Dies ist für das externe Netzwerk nicht korrekt.

• 2705010 behoben: Die Größe des Lastausgleichsdiensts bei Octavia konnte in VIO 7 nicht geändert werden.

  Octavia LBaaS bietet dem Benutzer keine Möglichkeit, die Größe des Lastausgleichsdiensts zu ändern.
  VIO 7.1 bietet Optionen für die Größenkonfiguration.

  default_edge_size = <purpose>:<edge size>[,...]
  

  Die unterstützten Werte für „purpose“ sind „router“, „dhcp“ und „lb“.
  Die unterstützten Werte für „edge size“ sind „large“, „xlarge“ und „quadlarge“.
  Beispiel: default_edge_size = lb:xlarge

  Verwenden Sie „viocli update neutron“, um die unten aufgeführten Parameter unter dem zu konfigurierenden Abschnitt [nsxv] hinzuzufügen:

  conf:
    neutron:
    plugins:
      nsx:
        nsxv:
          default_edge_size: lb:xlarge

• 2701437 behoben: Die Glance-Image-Option „vmware_create_template=false“ funktionierte nicht ordnungsgemäß.

  Das Glance-Image konnte Nova-Instanzen unter den nachstehenden Konfigurationen nicht erstellen und starten:

  • Wenn die Option „vmware_create_template“ in der Glance-Konfiguration den Wert „false“ aufweist
  • Wenn der Benutzer das Glance-Image mithilfe der OpenStack-CLI mit der Eigenschaft „vmware_create_template=false“ erstellt
    Beispiel:

  openstack image create --disk-format vmdk --file vmdk --property vmware_create_template=false imageName

• 2699470 behoben: Der Befehl „nova-manage“ kann im Nova Compute-Pod nicht ausgeführt werden.

  Wenn der Befehl „nova-manage“ im Nova Compute-Pod ausgeführt wird, tritt eine DBNonExistentTable-Ausnahme auf, da in „nova-compute.conf“ kein [database]-Abschnitt vorhanden ist.

• 2688655 behoben: Die OpenStack-CLI-Authentifizierung über OpenID funktioniert nicht unter VIO 7.0.1.

  Die OpenStack-CLI-Authentifizierung über OpenID funktioniert nicht unter VIO 7.0.1, und es wird ein Fehler des Typs „Nicht autorisiert (HTTP 401)“ ausgegeben.

• 2674517 behoben: Die im Typ definierte Auslagerungsfestplatte ist in der Nova-Instanz nicht ordnungsgemäß gemountet.

  Die im Typ definierte Auslagerungsfestplatte ist in der Nova-Instanz nicht ordnungsgemäß gemountet. Dieses Problem wurde in VIO 7.1 mit der Einschränkung behoben, dass die Änderung der VM-Größe in Verbindung mit einer Auslagerungsfestplatte nicht unterstützt wird.

• 2672946 behoben: Beim Pod zum Einrichten der Nova Compute-Verfügbarkeitszone tritt ein CrashLoopBackOff-Zustand auf, wenn der Name für die Hostaggregation bestimmte Bedingungen aufweist.

  Wenn ein Hostaggregat mit dem Namen „nova“ in der Verfügbarkeitszone „nova“ und ein anderes Hostaggregat mit dem Namen „xxxxx-nova“ der mit „^.*nova$“ in derselben Zone übereinstimmt (z. B. „5-nova“) vorhanden ist, tritt beim Nova Compute-Pod „az-setup“ ein CrashLoopBackOff-Zustand auf.

• 2656225 behoben: Der Benutzer kann die VM-Konsole nicht öffnen, und ein Fehler des Typs „Fehler: Konsole ist derzeit nicht verfügbar“ wird über die Horizon-Benutzeroberfläche ausgegeben.

  In bestimmten Situationen konnte Horizon VM-Konsolen nicht anzeigen, und ein Fehler des Typs „Fehler: Konsole ist derzeit nicht verfügbar“ wurde angezeigt. Dies wird durch Folgendes verursacht: Wenn der VMX-Konfigurationspfad länger wird, kann „nova-compute“ keine Zeile einfügen, die die Informationen eines MKS-Tickets und den VMX-Konfigurationspfad zur Datenbank enthält. Beispiel: SvMotion für eine VIO-Instanz führt dazu, dass der geänderte VMX-Konfigurationspfad eine längere Zeichenfolge ist.

• 2652286 behoben: Die Löschung der LB-Integritätsüberwachung schlägt mit einer Fehlermeldung des Typs „Serverseitiger Fehler: ‚NoneType‘-Objekt weist kein Snapshot-Attribut auf“ fehl.

  Dies ist ein Fehler im Octavia-Dienst, der das VMware NSX-Plug-In betrifft. In manchen Fällen kann der Octavia-Dienst den Pool, der einer Integritätsüberwachung entspricht, nicht abrufen, und löst damit diesen Fehler aus. Der Fehler ist derzeit offen und wird unter https://storyboard.openstack.org/#!/story/2008231 verfolgt.

• 2678067 behoben: Der Cursor funktioniert nicht konsistent für eine Windows-Nova-VM über die Horizon Console.

  Wenn Sie in einem beliebigen Browser auf die Horizon Console zugreifen, reagiert der Cursor für eine Windows-VM nicht, es sei denn, Sie klicken bei gedrückter Tabulator- oder Steuerungstaste. Letztendlich reagiert der Cursor erneut nicht auf Klicken mit der linken Maustaste.

• 2755304 behoben: Die Octavia LB-Statusänderungstransaktion schlägt fehl und bleibt im Status PENDING_DELETE hängen.

  Octavia verwendet einen UNIX-Socket für die interne Kommunikation innerhalb des Treiberagenten. Gelegentlich kommt es beim Schreiben in diesen Socket zu einer Zeitüberschreitung und damit zum Fehlschlagen der Statusänderungstransaktion. Der Wiederholungsmechanismus wird für die Statusänderungstransaktion hinzugefügt.

• 2643797​behoben: Beim Konfigurieren von „trusted_dashboard“ wird der Horizon-FQDN in „kystone.conf“ als IP-Adresse gespeichert, und nicht als FQDN (vollqualifizierter Domänenname).

  Wenn Sie Verbundeinstellungen für Keystone konfigurieren, wird der angegebene HorizonFQDN in der Keystone-Konfigurationsdatei als IP-Adresse und nicht als der angegebene FQDN (vollqualifizierter Domänenname) gespeichert.

  viocli update keystone
  conf:
    keystone:
      federation:
        trusted_dashboard: https://HorizonFQDN/auth/websso/

Bekannte Probleme

• Die Begrenzung der öffentlichen API-Rate ist nicht verfügbar.

  In VMware Integrated OpenStack 7.1 ist es nicht möglich, die Ratenbegrenzung für öffentliche APIs zu erzwingen.

  Problemumgehung: Keine. Diese Funktion wird in einer späteren Version angeboten.

• Das Erstellen eines Lastausgleichsdiensts mit einem privaten Subnetz, das nicht an einen Router angehängt ist, führt zu einem Fehlerzustand

  Wenn Sie über die Neutron-NSX-T-Plug-Ins wie MP- und Policy-Plug-In verfügen und einen Lastausgleichsdienst mit einem privaten Subnetz erstellen, das nicht an einen Router angehängt ist, führt dies dazu, dass der Lastausgleichsdienst sich in einem Fehlerzustand befindet, und der Fehler wird dem Benutzer nicht gemeldet.

  Problemumgehung: Erstellen Sie den Lastausgleichsdienst mit einem Subnetz, das an einen Router angehängt ist.

• Wenn bei der Bereitstellung von OpenStack falsche Anmeldedaten eingegeben werden, erkennt der Assistent möglicherweise die korrekten Anmeldedaten nicht.

  Wenn bei der OpenStack-Bereitstellung vCenter Server- oder NSX Manager-Anmeldedaten nicht korrekt eingegeben werden, erkennt der Assistent möglicherweise die korrekten Anmeldedaten nicht. Selbst wenn Sie die falschen Daten entfernen und die korrekten Anmeldedaten eingeben, kann der Assistent diese nicht validieren.

  Problemumgehung: Schließen Sie den Bereitstellungsassistenten und öffnen Sie ihn erneut.

• OpenStack-Portsicherheit kann auf direkten Ports im NSX-V Neutron-Plug-In nicht erzwungen werden.

  Die Aktivierung von „port-security“ für Ports mit dem Wert „direct“ für „vnic-type“ kann wirkungslos sein. Sicherheitsfunktionen sind für direkte Ports nicht verfügbar.

  Problemumgehung: Keine.

• Anmelden bei VIO nicht möglich, wenn das Kennwort für vCenter und NSX „$$“ enthält

  Wenn das für das zugrunde liegende vCenter und NSX konfigurierte VIO-Konto ein Kennwort verwendet, das „$$“ enthält, kann VIO die Authentifizierung für vCenter und NSX aufgrund der im Kennwort verwendeten Zeichenfolge „$$“ nicht abschließen. Bei den OpenStack-Pods kann ein CrashLoopBackOff-Zustand auftreten.

  Problemumgehung: Verwenden Sie andere Kennwörter, die nicht die Zeichenfolge „$$“ enthalten.

• Lastausgleichsdienste bleiben im Status PENDING_XXX hängen und sind für die Ausführung von Vorgängen nicht verfügbar.

  Dieses Problem mit dem Hängenbleiben tritt bei jedem Lastausgleichsdienst auf, der erstellt, geändert oder gelöscht wurde, als „octavia-da“ im octavia-api-Pod abstürzte.

  Problemumgehung: Diese Lastausgleiche können in Octavia nicht mehr verwendet werden. Sie sollten manuell aus der Octavia-Datenbank entfernt werden.

• Der Benutzer konnte das Glance-Image nicht über den OpenStack-CLI-Client herunterladen

  Beim Herunterladen des Images über die OpenStack-CLI tritt ein Fehler auf: „[Errno 32] Herunterladen eines beschädigten Images.“ Dies liegt daran, dass VIO das Image standardmäßig als VM-Vorlage im vSphere-Datenspeicher speichert. Der md5sum-Wert wird zwischen VMDK- und VM-Vorlage nicht gespeichert.

  Problemumgehung: Das Glance-Image konnte mit den nachstehenden Konfigurationen nicht heruntergeladen werden:

  • Die Option „vmware_create_template“ in der Glance-Konfiguration weist den Wert „false“ auf
  • Der Benutzer erstellt das Glance-Image mithilfe der OpenStack-CLI mit der Eigenschaft „vmware_create_template=false“
• Nach dem administrativen Festlegen einer Firewallgruppe als „DOWN (state=DOWN)“ ist der Betriebsstatus der Firewallgruppe immer DOWN, auch wenn der Administratorstatus der Firewallgruppe wieder UP ist

  Der Dienst „neutron-fwaas“ ignoriert die Änderung des Betriebsstatus bei Übergängen, bei denen kein Port zur Firewallgruppe hinzugefügt oder daraus entfernt wird.

  Problemumgehung: Fügen Sie einen Port hinzu oder entfernen Sie einen Port. Alternativ dazu können Sie einen bereits an die Firewallgruppe gebundenen Port hinzufügen oder entfernen.

• Es besteht nicht die Wahl, die Zertifikatvalidierung nicht zu ignorieren, wenn das Zertifikat für vCenter und NSX von einer Zwischenzertifizierungsstelle signiert ist

  Wenn das Zertifikat für vCenter und NSX von einer Zwischenzertifizierungsstelle signiert ist, können einige VIO-Dienste nicht ordnungsgemäß für die Durchführung einer Zertifikatvalidierung konfiguriert werden. Der Fehler kann in verschiedenen Formen vorliegen. Beispielsweise kann die Auswahl von „Zertifikatvalidierung ignorieren“ beim Hinzufügen oder Bearbeiten von vCenter oder NSX nicht aufgehoben werden.

  Problemumgehung: Wählen Sie „Zertifikatvalidierung ignorieren“ in der Benutzeroberfläche aus, bearbeiten Sie vCenter- und NSX-CR und legen Sie spec.insecure auf „true“ fest.

• Wenn Sie für ein Neutron-Segment auf „Bearbeiten“ und „Speichern“ klicken, wird versehentlich Multicast aktiviert

  Wenn in der NSX-T Policy-Benutzeroberfläche im Multicast-Routing damit nicht in Zusammenhang stehende Änderungen vorgenommen werden, wird Multicast-Routing für das Segment aktiviert.

  Problemumgehung: Deaktivieren Sie Multicast explizit in der Benutzeroberfläche, wenn Sie das Segment bearbeiten.

• Vorgänge zum Hinzufügen von Mitgliedern schlagen mit einer Fehlermeldung des Typs „Anbieter ‚vmwareedge‘ meldet Fehler: Zertifikat konnte nicht abgerufen werden::“ (HTTP-Status 500) fehl

  Es können keine Mitglieder zu Octavia-Lastausgleichsdiensten mit dem Status HTTPS_TERMINATED hinzugefügt oder daraus entfernt werden.

  Problemumgehung: Verwenden Sie die OpenStack-CLI zum Hinzufügen oder Entfernen von Mitgliedern.

  1. Rufen Sie für alle betroffenen Benutzer die tls_container_ref ab.

  2. Suchen Sie die URIs für den Container, den geheimen Schlüssel und das Zertifikat.

  3. Rufen Sie die Benutzer-ID des Octavia-Diensts ab.

  4. Fügen Sie die in Schritt 2 abgerufenen URIs den ACLs für die in Schritt 3 abgerufene Benutzer-ID hinzu.

• Für Tier1-Gateways konnte während einer großen MP2P-Migration kein vollständiges Rollback durchgeführt werden

  Während einer großen MP2P-Migration konnte für einige Tier1-Gateways kein vollständiges Rollback durchgeführt werden, und der Löschstatus blieb „In Bearbeitung“. Ein nicht erfolgreiches Rollback wurde möglicherweise durch einen Fehlers während der Migration verursacht.

  Problemumgehung: Stellen Sie UA wieder her und führen Sie die Migration erneut durch.

• Fehler mit doppeltem Eintrag im Keystone-Verbund

  Wenn nach dem Löschen von OIDC im Keystone-Verbund derselbe Benutzer versucht, sich bei OIDC anzumelden, schlägt die Authentifizierung mit einer 409-Fehlermeldung fehl.

  Problemumgehung: Löschen Sie den Benutzer entweder über die Horizon- oder die OpenStack-CLI.

  Beispiel:

  1. Melden Sie sich in Horizon mit einem Administratorkonto an.

  2. Legen Sie als Domänenkontext die Verbunddomäne fest.

  3. Löschen Sie auf der Seite „Benutzer“ den Benutzer, bei dem in der Spalte „Benutzername“ der Wert None angegeben ist.

  In der OpenStack-CLI:

  openstack user list --domain <federated domain name>

  openstack user delete <user id> --domain <federated domain name>

• Nach erfolgreicher Migration sind die Migrator-Pod-Protokolle im VIO-Support-Paket nicht verfügbar
   

  Nach einer erfolgreichen Migration wird die VIO-Steuerungsebene neu konfiguriert und der Migrator-Pod wird gelöscht. Daher wird das Protokoll des Migrator-Pods nicht im Support-Paket erfasst.

  Problemumgehung: Die Protokolle für den Migrator-Pod sind auf dem Controller-Knoten verfügbar und werden unter „/var/log/vmware/mp2p_migration.log“ ausgeführt und gespeichert. Sie können die Protokolldateien abrufen, indem Sie über viossh auf die Controller-Knoten zugreifen. Die Protokolldateien sind nur auf dem Controller verfügbar, auf dem die Aufgabenausführung stattfindet. Daher kann es erforderlich sein, mehrere Controller zu durchlaufen, bis Sie sie finden.

• Ceilometer kann nicht aktiviert werden, wenn 10.000 Neutron-Mandantennetzwerke vorhanden sind.

  Wenn in vSphere eine große Anzahl an Ressourcen wie Netzwerke vorhanden sind, generiert VIO viele Kundenressourcen für diese Objekte. Wenn die Anzahl an Kundenressourcen zu groß ist, wird ein Fehlschlagen der Web-Benutzeroberfläche von VIO Manager auf der Backend-API herbeigeführt, da die Antwortdaten für HTTP-Anforderungen zu groß sind.

  Problemumgehung: Löschen Sie in VIO Manager die ermittelten Kundenressourcen manuell.

  Die Kundenressourcen können mithilfe des folgenden Befehls aufgelistet werden:

  kubectl -n openstack get discoveries.vio.vmware.com

  Die Kundenressourcen können mithilfe des folgenden Befehls gelöscht werden. Beispiel:

  kubectl -n openstack delete discoveries.vio.vmware.com vcenter-vcenter2-networks-2

• Zertifikat muss von der Zertifizierungsstelle signiert und nach der Wiederherstellung erneut angewendet werden

  Der geheime Zertifikatschlüssel, der den privaten VIO-Schlüssel und das VIO-Zertifikat enthält, befindet sich derzeit nicht im Sicherungsumfang. Nach einer nicht direkten Wiederherstellung ist das zuvor importierte Zertifikat in der neuen Bereitstellung nicht vorhanden.

  Problemumgehung:

  1. Speichern Sie den geheimen Zertifikatschlüssel aus der ursprünglichen Bereitstellung.
  osctl get secret certs -oyaml > certs.yaml
  2. Ersetzen Sie nach der Wiederherstellung den Wert für „private_key“ und „vio_certificate“ im geheimen Zertifikatschlüssel durch die Daten aus Schritt 1.
  3. Beenden Sie die Dienste und starten Sie sie erneut.

• Auf einem bestimmten Nova Compute-Knoten können keine Instanzen erstellt werden, und das Nova Compute-Protokoll bleibt hängen.

  Beim Erstellen einer Instanz verbleibt sie im BUILD-Status und wird nie erfolgreich erstellt. Beim Prüfen des Nova Compute-Protokolls sind nur wenige Protokolleinträge vorhanden und keine weiteren Informationen verfügbar.

  Problemumgehung: Starten Sie den Nova Compute-Pod manuell neu.

• Beim Speichern der Änderungen an Firewallregeln über die Horizon-Benutzeroberfläche reagiert die Benutzeroberfläche nicht.

  Wenn eine der mit Sternchen (*) markierten erforderlichen Optionen beim Bearbeiten von Firewallregeln nicht aktualisiert wird, reagiert die Benutzeroberfläche beim Speichern von Änderungen nicht.

  Problemumgehung: Aktualisieren Sie beim Bearbeiten von Firewallregeln alle erforderlichen Optionen.

• Manche Tag-2-Vorgänge funktionieren nach dem Ändern des vCenter-Benutzernamens und des vCenter-Kennworts in der Web-Benutzeroberfläche von VIO Manager nicht mehr.

  Wenn ein Benutzer die vCenter-Anmeldedaten in der Web-Benutzeroberfläche von VIO Manager aktualisiert, besteht die Möglichkeit, dass die OpenStack-Dienste funktionieren. Die Steuerungsebene von VIO kann jedoch nicht mit vCenter kommunizieren, da der geheime vCenter-Schlüssel im K8s-Cloud-Anbieter und in der Cluster-API nicht aktualisiert wurde.

  Problemumgehung: Verwenden Sie den Befehl „kubectl patch secret“ zum Aktualisieren der vCenter-Anmeldedaten in VIO Manager.

  Überprüfen Sie die aktuellen Informationen des geheimen vc-credential-Schlüssels:

  kubectl -n kube-system get secret viocluster1-vc-credentials -o yaml 
  kubectl -n openstack get secret viocluster1-vc-credentials -o yaml
  

  Aktualisieren Sie den geheimen vc-credentials-Schlüssel mit einem neuen Benutzernamen/Kennwort (im base64-Format):

  kubectl -n kube-system patch secret viocluster1-vc-credentials --patch \
  '{"data": {"your_vcenter.password": "password_in_base64", "your_vcenter.username": "username_in_base64"}}'
  kubectl -n openstack patch secret viocluster1-vc-credentials --patch \
  '{"data": {"password": "password_in_base64", "username": "username_in_base64"}}'
  

• Die Horizon-Benutzeroberfläche zeigt „xmltooling::IOException“ an, wenn eine Anmeldung mit dem Identitätsanbieter für den SAML-Verbund erfolgt.

  Wenn VIO mit einem externen SAML-Identitätsanbieter konfiguriert ist, tritt der Fehler „xmltooling::IOException“ auf, wenn der Benutzer versucht, sich beim SAML-Verbund anzumelden.

  Problemumgehung: Klicken Sie im Browser auf die Schaltfläche „Aktualisieren“. Der Benutzer wird zur Anmeldeseite für Identitätsanbieter weitergeleitet.

• Wenn Sie den Befehl „viocli update“ zum Aktualisieren von CR verwenden, kann ein Fehler auftreten, wenn Sie eine große Ganzzahl als Wert eingeben. Beispiel: profile_fb_size_kb: 2097152.

  Große Ganzzahlen werden in einigen Fällen durch VIO-Helm-Diagramme in die wissenschaftliche Notation konvertiert.

  Problemumgehung: Fügen Sie Anführungszeichen um die große Ganzzahl hinzu. Beispiel: profile_fb_size_kb: "2097152".

• Snapshots auf einem Controller-Knoten verhindern einige VIO-Vorgänge.

  Das persistente Volume auf einem Controller-Knoten kann nicht verschoben werden, wenn ein Snapshot des Controller-Knotens vorhanden ist. Daher wird die Erstellung eines Controller-Snapshots von VIO nicht unterstützt.

  Problemumgehung: Löschen Sie alle Snapshots auf den Controller-Knoten.

• Volumes, die aus Images erstellt werden, sind standardmäßig immer startfähig.

  Wenn Sie beim Erstellen eines Volumes aus einem Image den Parameter „--non-bootable“ hinzufügen, wird der Parameter nicht wirksam.

  Problemumgehung: Nachdem das Volume erstellt wurde, aktualisieren Sie es so, dass es nicht bootfähig ist.