Fehlerbehebung bei MTV-Migrationen von „ VMware vSphere “ zu „ Red Hat OpenShift Virtualization“

Beheben Sie häufige Fehler bei „ Migration Toolkit “ für Virtualisierung (MTV), wenn Sie virtuelle Maschinen (VMs) v VMware vSphere® en auf Red Hat OpenShift Virtualisierung, einschließlich der Wiederholungsgrenzen für Warm-Migrationen, Fehler beim Abrufen von VDDK-Images (Virtual Disk Development Kit), Probleme bei der DNS-Auflösung (Domain Name System), Dateisystemfehler bei „ virt-v2v “ sowie Probleme bei der Beibehaltung statischer IP-Adressen.

Das Limit für Wiederholungsversuche beim „Warm Import“ wurde erreicht

Was passiert?

Eine „Warm“-Migration schlägt mit einer Fehlermeldung fehl, die darauf hinweist, dass der „Warm“-Import das Limit für Wiederholungsversuche überschritten hat.

Warum passiert das?

MTV hat mehr als 28 CBT-Snapshots (Changed Block Tracking) für die Quelle VM erstellt. Ein einzelnes „ VM “ unterstützt maximal 28 CBT-Snapshots. Wird dieser Grenzwert überschritten, kann die Warmwanderung nicht fortgesetzt werden.

Wie kann man das beheben?

  1. Löschen Sie ältere CBT-Snapshots auf dem Quell VM, um deren Anzahl zu verringern als 28 Momentaufnahmen.
  2. Reduzieren Sie gegebenenfalls die Snapshot-Fluktuation, indem Sie das Intervall vor dem Kopieren verlängern controller_precopy_interval.
  3. Starten Sie den Migrationsplan neu.

Das Disk-Image kann nicht auf die gewünschte Größe angepasst werden

Was passiert?

Die Migration schlägt mit der Fehlermeldung fehl, dass die Größe des Festplatten-Images nicht auf die erforderliche Größe angepasst werden kann.

Warum passiert das?

Die Ziel- VM-Persistent-Volumes, die „ ext4 “ auf Blockspeicher nutzen, überschreiten den standardmäßigen Dateisystem-Overhead von 10 %, den der Containerized Data Importer (CDI) geht davon aus. Daher ist nicht genügend Speicherplatz für die Root-Partition vorhanden.

Wie kann man das beheben?

  1. Bearbeiten Sie die benutzerdefinierte Ressource (CR) „ ForkliftController “.
  2. Erhöhen Sie den Parameter „ controller_filesystem_overhead “ auf einen höheren Wert als 0.10, wie zum Beispiel 0.15.
  3. Wenden Sie die Änderung an.
  4. Führen Sie die Migration erneut aus.

Migrationsplan scheitert nach der Erstellung

Was passiert?

Ein Migrationsplan schlägt unmittelbar nach seiner Erstellung fehl, noch bevor irgendwelche VMs übertragen werden.

Warum passiert das?

Das Abrufen von VDDK-Images (Virtual Disk Development Kit) wird verweigert, da sich der Validator-Pod nicht beim internen Red Hat OpenShift Bilddatenbank.

Wie kann man das beheben?

Erteilen Sie dem Dienstkonto „ default “ Zugriffsrechte im Ziel-Namespace. Führen Sie den folgenden Befehl im Webterminal von „ Red Hat OpenShift “ oder auf einem lokalen System aus, auf dem die CLI von „ oc “ installiert ist.

oc adm policy add-cluster-role-to-user registry-viewer system:serviceaccount:<target-namespace>:default

Ersetzen Sie „ target-namespace “ durch Ihren Ziel-Namespace.

Migrationsplan schlägt während der Initialisierungsphase fehl

Was passiert?

Ein Migrationsplan schlägt in der Initialisierungsphase mit Fehlern fehl, die auf Probleme mit der Verbindung oder der Hostnamenauflösung hindeuten.

Warum passiert das?

Der Importer-Pod kann die ESXi-Hostnamen nicht auflösen. Domain Name System (DNS) Die Abfragen für Verbindungen über Port 902 zwischen dem Red Hat OpenShift Cluster und die ESXi-Hosts „ VMware “.

Wie kann man das beheben?

Konfigurieren Sie die DNS-Weiterleitung (Domain Name System) für die „ vCenter “- oder ESXi-Domäne. Fügen Sie eine Weiterleitungszone hinzu, die auf Ihre Domänencontroller verweist.

servers:
- forwardPlugin:
        policy: Random
        upstreams:
        - <domain-controller-ip-1>
        - <domain-controller-ip-2>
    name: vcs-resolver
    zones:
    - vcs.example.com

Ersetzen Sie in der YAML-Konfiguration „ domain-controller-ip-1 “ und domain-controller-ip-2 mit den IP-Adressen Ihrer Domänencontroller. Ersetzen Sie „ vcs.example.com “ durch Ihre „ vCenter “- oder ESXi-Domäne. Wenden Sie anschließend die DNS-Änderung an, nachdem Sie die Konfiguration gespeichert haben.

virt-v2v: Dateisystem schreibgeschützt eingebunden

Was passiert?

Das Konvertierungstool „ virt-v2v “ meldet, dass das Dateisystem schreibgeschützt eingebunden ist, und die Migration schlägt fehl.

Warum passiert das?

Der Quell-Windows®- VM-Server wurde vor dem Export des Open Virtualization Archive (OVA) nicht ordnungsgemäß heruntergefahren. Durch den Schnellstart oder den Ruhezustand wurde das Dateisystem in einem „dirty“-Zustand hinterlassen, wodurch „ virt-v2v “ daran gehindert wird, es für den Lese-/Schreibzugriff einzuhängen.

Wie kann man das beheben?

  1. Deaktivieren Sie den Schnellstart auf dem Quell-Windows- VM. Gehen Sie zu „Systemsteuerung“ > Energieoptionen > Legen Sie fest, welche Funktionen die Ein-/Aus-Tasten haben sollen, und deaktivieren Sie das Kontrollkästchen „ Schnellstart aktivieren “.
  2. Den Ruhezustand deaktivieren. Führen Sie in einer Eingabeaufforderung mit Administratorrechten folgenden Befehl aus:powercfg /h off
  3. Führen Sie ein ordnungsgemäßes Herunterfahren durch, indem Sie den Befehl „ shutdown /s /t 0 “ ausführen.
  4. Exportieren Sie die OVA-Datei erneut, nachdem der ordnungsgemäße Herunterfahrvorgang abgeschlossen ist.
  5. Laden Sie die neue OVA auf den Server „ NFS “ hoch.
  6. Versuchen Sie die Migration erneut.

Statische IP beibehalten: Subnetz des Ziels stimmt nicht überein

Was passiert?

Nachdem Sie die Option „Statische IP-Adressen beibehalten“ aktiviert haben, erhält der migrierte „ VM “ nicht die erwartete IP-Adresse, und im Zielnetzwerk liegt eine Subnetz-Diskrepanz vor.

Warum passiert das?

Das primäre Layer-2-Zielnetzwerk hat ein anderes Subnetz als das Quellnetzwerk.

Wie kann man das beheben?

Löschen Sie das primäre Layer-2-Netzwerk und erstellen Sie es neu, sodass es dem richtigen Subnetz entspricht. Führen Sie anschließend die Migration erneut durch.

Statische IP beibehalten: VM erhält eine zufällige IP-Adresse anstelle der angeforderten IP-Adresse

Was passiert?

Nachdem Sie die Option „Statische IP-Adressen beibehalten“ aktiviert haben, wird der migrierte „ VM “ eine freie IP-Adresse zugewiesen anstelle der statischen IP-Adresse aus der Quelle.

Warum passiert das?

Die Quelle VM war zum Zeitpunkt der Migration nicht eingeschaltet, oder der Gast-Agent „ VMware “ war nicht installiert. Beide Bedingungen müssen erfüllt sein, damit die Beibehaltung der statischen IP-Adresse ordnungsgemäß funktioniert.

Wie kann man das beheben?

  1. Löschen Sie die falsch migrierte Datei „ VM “.
  2. Stellen Sie sicher, dass der „ VMware “-Gastagent ( VMware-Tools oder open-vm-tools) installiert auf der Quell- VM.
  3. Stellen Sie sicher, dass die Quell VM, eingeschaltet ist.
  4. Versuchen Sie die Migration erneut.

Statische IP beibehalten: Die Netzwerkzuordnung verweist auf ein sekundäres Layer-2-Netzwerk

Was passiert?

Nachdem Sie die Option „Statische IP-Adressen beibehalten“ aktiviert haben, wird die statische IP-Adresse nicht beibehalten, und die Netzwerkzuordnung verweist auf ein sekundäres Layer-2-Netzwerk.

Warum passiert das?

Sekundäre Layer-2-Netzwerke unterstützen die Funktion „ Preserve static IP “ nicht.

Wie kann man das beheben?

Richten Sie ein sekundäres Layer-2-Netzwerk ohne IP-Adressverwaltung (IPAM) ein und verwenden Sie stattdessen die manuelle IP-Konfiguration.

Statische IP-Adresse beibehalten: Die Netzwerkzuordnung verweist auf ein Localnet- oder VMNetwork-Netzwerk

Was passiert?

Nachdem Sie die Option „Statische IP-Adressen beibehalten“ aktiviert haben, wird die statische IP-Adresse nicht beibehalten, und die Netzwerkzuordnung verweist auf ein Localnet- oder VMNetwork-Netzwerk.

Warum passiert das?

Localnet-Netzwerke unterstützen die Funktion „ Preserve static IP “ nicht.

Wie kann man das beheben?

Verwenden Sie die manuelle IP-Konfiguration auf dem migrierten „ VM “.

Weitere Ressourcen zur Fehlerbehebung

Weitere Anleitungen zur Fehlerbehebung und Informationen zu den erfassten Protokollen finden Sie in den folgenden Ressourcen: