Migration von virtuellen Maschinen mit mehreren Festplatten unter „ VMware “ zu „ IBM Cloud “ mit direkter Volume-Kopie

Migrieren Sie virtuelle Maschinen (VMs) mit mehreren Festplatten unter „ VMware “ auf virtuelle Server unter „ IBM Cloud VPC “, indem Sie eine direkte Volume-Kopie mit „qemu-img“ oder „ virt-v2v “ verwenden, um die vollständige Kontrolle auf Festplattenebene zu gewährleisten.

Komponenten der Architektur

In der folgenden Tabelle sind die Architekturkomponenten einer direkten Volume-Copy-Migration aufgeführt.

Architekturkomponenten für die Methode der direkten Volume-Copy-Migration
Komponenten der Architektur	Beschreibung
Instanz eines virtuellen Arbeitsservers	Eine temporäre virtuelle Serverinstanz, die als Ihr Migrationsarbeitsbereich dient. Für diese virtuelle Serverinstanz gelten folgende Voraussetzungen: – Ausreichende CPU-Leistung und Arbeitsspeicher zum Ausführen der Konvertierungstools – Ausreichender Speicherplatz im Arbeitsbereich zur Speicherung der exportierten VMDK-Dateien (Virtual Machine Disk) (oder einer großen temporären Festplatte) – Netzwerkverbindung zu Ihrer VMware-Umgebung (falls Sie die Live-Übertragung nutzen) – Das Tool „ `qemu-img` “ und optional „ `libguestfs` “ ( virt-v2v ) für Transformationen
Ephemere virtuelle Serverinstanz	Eine kurzlebige virtuelle Serverinstanz, die nur dazu dient, Boot- und Datenvolumes mit der richtigen Konfiguration zu erzeugen. Sie löschen diese virtuelle Serverinstanz sofort, behalten aber ihre Volumes.
Zielvolumina	Die eigentlichen Volumes, die die migrierten VM 's Festplatten werden.

Überblick über den Prozess der direkten Volumenmigration durch Kopieren

Die folgenden Schritte beschreiben den Migrationsprozess mit Hilfe der direkten Volume-Kopie.

Bereitstellung einer virtuellen Serverinstanz für Mitarbeiter
1. Ubuntu oder RHEL-Instanz mit ausreichendem Arbeitsbereich
2. Hängen Sie ein großes sekundäres Volume an, wenn Arbeitsraum für VMDKs benötigt wird
3. Installieren Sie die erforderlichen Werkzeuge
  - qemu-img
  - libguestfs-tools (für virt-v2v )
Temporäre virtuelle Serverinstanz erstellen
1. Konfigurieren Sie es so, dass es Ihrem Ziel entspricht VM (Betriebssystem, Größe der Boot-Platte, Anzahl/Größe der sekundären Platten)
2. Kritisch: Automatisches Löschen auf allen Volumes deaktivieren
3. Kritisch: general-purpose Speicherprofil für Boot-Volume verwenden
4. Netzwerkkonfiguration kann weggeworfen werden
5. Beachten Sie die Volumengrößen und die Reihenfolge
Ephemere virtuelle Serverinstanz löschen, Volumes beibehalten
1. Löschen Sie die virtuelle Serverinstanz über die Benutzeroberfläche oder CLI
2. Bestätigen Sie, dass die Datenträger noch vorhanden und zum Anhängen verfügbar sind
Anhängen von Volumes an die Instanz des virtuellen Arbeitsservers
1. Fügen Sie sie in der gleichen Reihenfolge an, in der sie erstellt wurden
2. Notieren Sie sich die Gerätenamen (z. B. /dev/vdb, /dev/vdc, usw.)
3. Überprüfen Sie die Größen: blockdev --getsize64 /dev/vdb
Übertragen und Konvertieren von VM Disketten
1. Wenn exportiert: Kopieren Sie das VMDK auf die Instanz des virtuellen Arbeitsservers
2. Konvertieren und Schreiben in einem Schritt:
```
qemu-img convert -f vmdk -O raw source-vm-boot.vmdk /dev/vdb
qemu-img convert -f vmdk -O raw source-vm-data.vmdk /dev/vdc
```
1. Verwenden Sie optional virt-v2v für die Windows-Treiberinjektion (siehe den folgenden Abschnitt über Windows)
Überprüfen und Spülen
1. Überprüfen Sie die Partitionstabellen stichprobenartig: fdisk -l /dev/vdb
2. Puffer leeren: blockdev --flushbufs /dev/vdb
Volumes vom Arbeiter abkoppeln
1. Alle Zielvolumes abhängen
2. Sie sind nun bereit, an die endgültige virtuelle Serverinstanz angeschlossen zu werden
Endgültige virtuelle Serverinstanz aus vorhandenem Boot-Volumen erstellen
1. Anstatt ein Image auszuwählen, wählen Sie "vorhandenes Boot-Volume"
2. Wählen Sie das Boot-Volume aus, das Sie bestückt haben
3. Netzwerk, Sicherheitsgruppen, SSH-Schlüssel konfigurieren (erforderlich, auch wenn er nicht verwendet wird, wenn es sich um eine bestehende VM handelt)
4. Für sekundäre Volumes: CLI/API verwenden oder nach Erstellung und Neustart anhängen
Post-Migrations-Konfiguration
1. Booten Sie die virtuelle Serverinstanz, greifen Sie über die VNC-Konsole zu, wenn die Netzwerkkonfiguration angepasst werden muss
2. Überprüfen Sie, ob alle Festplatten vorhanden und eingehängt sind
3. Erweitern Sie die Partition des Startvolumens, wenn Sie die Größe nach oben geändert haben

Vorteile der direkten Volumenkopie

In der folgenden Tabelle sind die Designvorteile der direkten Volume-Copy-Migration aufgeführt.

Designvorteile für die Methode der direkten Volume Copy Migration
Vorteil Design	Beschreibung
Unterstützung mehrerer Festplatten	Die Unterstützung für mehrere Festplatten verarbeitet virtuelle Maschinen mit einer beliebigen Anzahl von Festplatten, bis hin zur VPC-Grenze von 12 Festplatten.
Keine Bildvermehrung	Sie erstellen nicht für jede virtuelle Maschine ein eigenes Image. Ihre benutzerdefinierte Bilderliste bleibt sauber.
Flexible Umgestaltung	Ermöglicht eine einfache Integration mit virt-v2v für Treiberinjektionen, Betriebssystemoptimierungen usw.
Option zur Speichereffizienz	Wenn Sie eine Basisvorlage als benutzerdefiniertes Image importieren und als Boot-Volume-Quelle für Ihre ephemere virtuelle Serverinstanz verwenden (Schritt 2), erbt das endgültige Boot-Volume die Effizienz des verknüpften Klonraums.

Einschränkungen und Beschränkungen der direkten Volumenkopie

In der folgenden Tabelle sind die Einschränkungen und Beschränkungen einer direkten Volume-Kopie-Migration aufgeführt.

Einschränkungen und Beschränkungen für die Methode der direkten Volume-Kopie-Migration
Beschränkung oder Einschränkung	Beschreibung
Komplexität der Orchestrierung	Es gibt mehr Schritte und bewegliche Teile. Sie benötigen solide Runbooks und vorzugsweise Automatisierung (Terraform, Ansible, Skripte).
Einschränkungen bei der Anbindung von Datenträgern	Die Benutzeroberfläche (UI) von „ IBM Cloud “ unterstützt das Hinzufügen von sekundären Volumes während der Erstellung einer virtuellen Serverinstanz nicht. Sie müssen eine der folgenden Vorgehensweisen wählen: – Verwenden Sie die Befehlszeilenschnittstelle (CLI): `ibmcloud is instance-create ... --volume-attach ...` – Verwenden Sie die API/Terraform für eine vollständige Automatisierung: – Erstellen Sie die virtuelle Serverinstanz, stoppen Sie sie, hängen Sie Volumes an und starten Sie sie anschließend
Gemeinkosten exportieren	Wenn Sie VMDKs von VMware exportieren, fällt dieser Aufwand trotzdem an (wenn auch weniger als beim OVA-Export).

Überspringen des Exports mit Hilfe der Netzwerkübertragung

Sie können Methode 2 mit Netzwerkübertragungsmethoden (siehe Methode 3) kombinieren, um den Export von VMDKs vollständig zu vermeiden. Booten Sie Ihre Quelle VM von einer ISO-Datei, stellen Sie eine Netzwerkverbindung zu Ihrer virtuellen Worker-Server-Instanz her und streamen Sie den Festplatteninhalt direkt:

Geben Sie auf der virtuellen Worker-Server-Instanz (Ziel) den folgenden Befehl ein:
```
nc -l 192.168.100.5 8080 | gunzip | dd of=/dev/vdb bs=16M status=progress
```
Geben Sie auf der virtuellen Quellmaschine (von ISO gebootet) den folgenden Befehl ein:
```
dd if=/dev/sda bs=16M | gzip | nc -N -v 192.168.100.5 8080
```

Durch dieses Verfahren entfallen der Zeitaufwand für die Ausfuhr und der Lagerbedarf für die Ausfuhr.

Verwenden Sie diesen Prozess für VMs mit mehreren Festplatten, für Szenarien, in denen Sie eine genaue Kontrolle wünschen oder in denen es wichtig ist, die Verbreitung von benutzerdefinierten Images zu vermeiden. Auch bei der Netzwerkübertragung können Sie die Effizienz steigern.