Migration von IBM Cloud, VMware und VCF auf virtuelle VPC-Server mithilfe von RackWare RMM

Migrieren Sie VMs von IBM Cloud VMware VCF auf virtuelle VPC-Server mit RackWare RMM und behalten Sie dabei die IP-Adressen über Direct Sync und einen Bridge-Server bei.

Dieser Leitfaden befasst sich mit der Verwendung des „ RackWare-Managementmoduls“ ( RMM ) zur Migration von automatisierten virtuellen Maschinen aus „ IBM Cloud “ ( VCF ) auf virtuelle Serverinstanzen in der virtuellen privaten Cloud (VPC) von „ IBM Cloud “. Es gibt eine zugehörige Anleitung, die den Vorgang schrittweise erklärt.

IBM Cloud VCF-Für die Lizenzen für die Betriebssysteme der automatisierten virtuellen Maschinen ist der Kunde verantwortlich; diese werden nicht von bereitgestellt. IBM Cloud Beachten Sie beim Erstellen der virtuellen Zielserverinstanzen die Bereitstellungsoptionen für „ Bring Your Own License “.

Die meisten virtuellen Maschinen, die auf IBM Cloud VCF-Automated gehostet werden, sind mit NSX-Overlay-Segmenten verbunden, die keinen nativen Zugriff auf die IBM Cloud Classic-Netzwerke haben. Um sicherzustellen, dass die virtuellen Serverinstanzen am Ziel dieselben IP-Adressen wie die virtuellen Maschinen am Ursprung haben, müssen das NSX-Overlay-Segment und die VPC-Subnetze der virtuellen Serverinstanzen am Ziel voneinander isoliert werden. Dies erreichen Sie mit den folgenden Funktionen von „ RMM “:

  • Direkte Synchronisierung (Host-Synchronisierung) – Die Daten werden direkt von der virtuellen Quellmaschine auf die virtuelle Zielserverinstanz übertragen, ohne auf dem „ RMM “-Server gespeichert zu werden. Die „ RMM “ koordiniert den Einsatz.
  • Passthrough – Die virtuelle Zielserverinstanz kann die virtuelle Quellmaschine nicht direkt erreichen. Daher stellt „ RMM “ über Secure Shell (SSH) eine Verbindung zur virtuellen Zielserverinstanz her und initiiert von dort aus einen umgekehrten SSH-Tunnel zur virtuellen Quellmaschine. Datenfluss: Quelle → RMM → Ziel, wobei RMM als Netzwerk-Relay bzw. Proxy für die Datenübertragung fungiert.

Die RackWare RMM mit einem Bridge-Server ermöglicht die Migration zwischen isolierten Netzwerken durch:

  1. Bridge-Netzwerkadressübersetzung (NAT): Macht die Quelle über NAT für RMM zugänglich
  2. Reverse-SSH-Tunnel: Ermöglicht es der virtuellen Serverinstanz als Ziel, über den RMM-Server auf die virtuelle Maschine als Quelle zuzugreifen
  3. Schlüsselbasierte Authentifizierung: Die virtuelle Serverinstanz des Ziels verwendet den SSH-Schlüssel von RMM zur Authentifizierung bei der virtuellen Quellmaschine
  4. Datensynchronisierung über den Tunnel: Die virtuelle Zielserverinstanz ruft Daten von der virtuellen Quellmaschine über den sicheren SSH-Tunnel ab
  5. Installation des Bootloaders: Mit dem Befehl „ RMM “ wird das Zielsystem mit der richtigen GRUB-Konfiguration bootfähig gemacht

Das Verfahren ist elegant und ermöglicht eine beliebige Migration unter Beibehaltung von Sicherheit und Netzwerkisolierung.

Eine Alternative zur direkten Synchronisierung, die so genannte gestufte Synchronisierung (Stufe 1 + Stufe 2), wird in diesem Leitfaden nicht behandelt:

  • Stufe 1: Kopieren der Daten von der Quelle in den ZFS-Speicherpool von RMM und vorübergehende Speicherung.
  • Stufe 2: Kopieren der Daten vom Speicher RMM zum Ziel.

Wird verwendet, wenn Direct Sync nicht erwünscht ist oder wenn Sie Quell- und Zielvorgänge entkoppeln möchten.

IP-Adressierung beibehalten

Bei den meisten Migrationen von virtuellen Maschinen auf virtuelle VPC-Server muss die IP-Adressierung der migrierten Workloads beibehalten werden. Bei den meisten virtuellen Maschinen ist dies möglich, allerdings sind in VPC-Subnetzen IP-Adressen reserviert. Beispielsweise sind folgende Elemente auf 192.168.10.0/24:

  • ibm-network-address: 192.168.10.0
  • ibm-default-gateway: 192.168.10.1
  • ibm-dns-address: 192.168.10.2
  • ibm-reservierte-adresse: 192.168.10.3
  • ibm-broadcast-adresse: 192.168.10.255

Daher müssen Sie in vielen Fällen einige VMs pro Subnetz re-IPen.

Unterstützte Systeme

Informieren Sie sich in der in den Referenzen aufgeführten Dokumentation über die neuesten unterstützten Betriebssysteme, derzeit sind es jedoch folgende:

  • RHEL 5.2 bis 5.11, 6.x, 7.x. 8.x, 9.x
  • Centos 5.2 durch 5.11, 6.x, 7.x, 8.x
  • Oracle Linux 5.6 über 5.11, 6.x, 7.x, 8.x, 9.x
  • SLES 11 (einschließlich 32-Bit-Version)
  • SLES 12 (kein btrfs)
  • SLES 15 (kein btrfs)
  • Ubuntu 12 (einschließlich 32-Bit-Version), 14, 16, 18, 20, 22, 24
  • Debian 8, 9, 10, 11, 12
  • AlmaLinux 8, 9
  • Rocky Linux, 8, 9
  • Windows 2008 R2, 2012, 2016, 2019, 2022

Komponenten der Architektur

Dieser Leitfaden:

  • Verwendet Beispiel-IP-Adressen, um den Wissenstransfer zu unterstützen; Ihre IP-Adressen werden anders sein.
  • Der Schwerpunkt liegt auf einer Linux Migration, aber Microsoft Windows ist ähnlich.
IBM Cloud VMware-Automated    Bridge Server              IBM Cloud VPC
┌──────────────┐             ┌───────────────┐          ┌───────────────┐
│              │             │ens192:        │          │               │
│  Source VM   │             │192.168.10.254 │          │  RMM Server   │
│ 192.168.10.11├────────────►│               │◄─────────┤  10.68.70.11  │
│              │             │   ens224:     │          │               │
└──────────────┘             │   10.134.54.62│          └───────────────┘
                             │               │                  │
                             └───────────────┘                  │
                                                                │
                                                        ┌───────▼───────┐
                                                        │  Target VSI   │
                                                        │ 192.168.10.11 │
                                                        └───────────────┘

Das obige Diagramm zeigt eine logische Verbindungsansicht der Komponenten. Der Name bridge server ist irreführend, da er kein Layer-2-Bridging, sondern Layer-3-NAT verwendet.

Quelle VM:

  • Standort: IBM Cloud VCF Automatisierte Instanz VMware
  • Beispiel: VM läuft Ubuntu 22.04
  • Echte IP: 192.168.10.11 (NSX-Overlay-Segment)
  • Erreichbar über: VM hat Zugriff auf das Internet über SNAT und nativen Zugriff auf das Client-Netzwerk, aber keinen Zugriff auf das IBM Cloud Netzwerk

Bridge-Server:

  • Zweck: Bereitstellung von Layer-3-Netzkonnektivität zwischen isolierten Netzen
  • Funktion: Verwendet SNAT, um isolierte NSX-Overlay-Segmente für IBM Cloud VPC-Netzwerke zugänglich zu machen
  • Interfaces
    • ens192: 192.168.10.254- Inneres Netz ( 192.168.10.0/24 )
    • ens224: 10.134.54.62- Außerhalb des Netzes ( 10.134.54.0/26 )

RMM Server:

  • Standort: IBM Cloud VPC
  • Zweck: Orchestrierung von Migrations-/Synchronisationsvorgängen
  • IP: 10.68.70.11
  • Läuft: RackWare Software, hostet die Benutzeroberfläche, koordiniert den Datentransfer, fungiert als Proxy für Netzwerk-Kommunikationen im Passthrough-Modus

Ziel-VSI

  • Standort: IBM Cloud VPC
  • Beispiel: Virtuelle Server-Instanz (VSI)
  • IP: 192.168.10.11
  • Zweck: Ziel für migrierte Daten

IBM Cloud Private Statisches Teilnetz:

  • Standort: IBM Cloud Klassisch
  • Beispiel: Bereitstellen eines portablen /30-Subnetzes (4 IPs)
  • IP: 10.194.177.82/30. Verwendbare IPs: 10.194.177.82- 10.194.177.85
  • Zweck: Stellt die IP-Adresse für NAT bereit, an die das klassische Netzwerk IBM Cloud weiterleitet: 10.134.54.62 (IP-Adresse des Bridge-Servers ens224 ). IBM die Netzwerkinfrastruktur der Firma weiß, dass jeglicher Verkehr, der für 10.194.177.82/30 bestimmt ist, an 10.134.54.62

Bridge-Server

Der Bridge-Server verwendet iptables, um NAT bereitzustellen:

  1. Wenn RMM eine Verbindung zu 10.194.177.82 herstellt, übersetzt die Bridge das Ziel in 192.168.10.11 (die echte IP-Adresse der Quelle VM ).

  2. Wenn die Quelle VM antwortet, scheint sie von der NAT-IP zu kommen 10.194.177.82

    Wenn RMM versucht, 10.194.177.82 zu erreichen:

    1. RMM sendet Paket
      • SRC: 10.68.70.11
      • Sommerzeit: 10.194.177.82
    2. VPC-Routen zu Transit Gateway, die zu einem klassischen Netzwerk führen, das das weiß:
      • " 10.194.177.82 ist im Teilnetz 10.194.177.82/30 "
      • "Dieses Subnetz an 10.134.54.62 weiterleiten"
    3. Schritt 3: Paket wird an den Bridge-Server übermittelt
      • Zu finden unter ens224 ( 10.134.54.62 )
      • Sommerzeit: 10.194.177.82 (unverändert)
    4. DNAT mit iptables unter Bridge
      • iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.82 -j DNAT --to-destination 192.168.10.11
    5. Paket wird zur Quelle weitergeleitet VM
      • SRC: 10.68.70.11
      • DST: 192.168.10.11 (DNAT-umgeleitet)

SSH-Schlüssel-Anforderungen

Damit der Tunnel für die Datenübertragung funktioniert, muss sich das Ziel bei der Quelle authentifizieren. Der Ziel-VSI benötigt den privaten SSH-Schlüssel, der zu einem öffentlichen Schlüssel in der authorized_keys-Datei der Quelle VM passt.

Wichtige Standorte:

  • RMM: /root/.ssh/id_rsa Erstellt als Teil des manuellen Prozesses nach der Bereitstellung von RMM
  • Ziel Linux VSI: /root/.ssh/id_rsa Muss derselbe Schlüssel sein wie der von RMM und über einen automatisierten Prozess RMM übertragen werden
  • Quelle Linux VM: /home/rackware/.ssh/authorized_keys Erstellt im Rahmen des manuellen Prozesses zur Einrichtung der Quelle

Für Windows-Server wird das Dienstprogramm RackWare SSHD verwendet. RackWare SSHD für Windows ist eine leichtgewichtige SSH-Server-Implementierung, die als MSI-Installationsprogramm speziell für Windows-Systeme verpackt ist, um RackWare RMM Konnektivität zu ermöglichen. Das MSI, RWSSHDService_x64.msi, kann direkt vom Server RMM heruntergeladen werden: https://<RMM_IP>/windows/RWSSHDService_x64.msi

Authentifizierungsablauf

  1. RMM → Quelle VM (über Brückenserver)
    • Verwendet: RMM 's SSH-Schlüssel
    • Authentifiziert sich als: rackware user
    • Zweck: Erkennung, Einhängen von Dateisystemen, Aufräumen
  2. RMM → Ziel VSI
    • Verwendet: RMM 's SSH-Schlüssel
    • Authentifiziert sich als: root user
    • Zweck: Tunnel erstellen, Dateisysteme einhängen, Datenübertragung
  3. Ziel-VSI → Quelle VM (durch Tunnel)
    • Verwendet: Kopierter SSH-Schlüssel (gleich wie RMM 's)
    • Authentifiziert sich als: rackware user
    • Zweck: Datenübermittlung

Kern RackWare RMM Operationen

Im Folgenden sind die wichtigsten RackWare RMM Vorgänge für die Migration aufgeführt.

Entdecken/Untersuchen

Zweck: Sammeln von Informationen über die Quelle VM Prozess:

  • Der Benutzer gibt die IP-Adresse oder den DNS-Hostnamen der Quelle VM an. In unserem Anwendungsfall verwenden wir die NAT-IP-Adresse.
  • RMM verbindet sich über SSH mit dem Quellserver VM
  • Führt Standard-Betriebssystemabfragen durch, um Metadaten zu sammeln:
    • CPU-Kerne, RAM, Festplattenkonfiguration
    • Partitionen und Volumenstruktur
    • Betriebssystemversion und installierte Pakete
    • Netzkonfiguration
    • Anwendungsinformationen
  • Metadaten, die in der CMDB (Configuration Management Database) von RMM gespeichert sind
  • Wird später für AutoProvisioning Ziel-VSI verwendet, falls erforderlich

Schlüsselanforderung: SSH-Schlüssel müssen zwischen RMM und dem Quellserver ordnungsgemäß konfiguriert sein

Erfassen (Store-and-Forward-Ansatz)

Der Store-and-Forward-Ansatz wird in diesem Anwendungsfall nicht verwendet, da wir den Ansatz der direkten Zuweisung (Flex Sync/Host Sync) nutzen.

Zweck: Erstellen eines Snapshots/Klons des Quell-Images VM auf dem RMM Prozess:

  • Erstellt einen LVM-Snapshot ( Linux ) oder einen VSS-Snapshot (Windows) auf der Quelle VM
  • Das Betriebssystem überträgt die IOs der Anwendung auf die Festplatte, um die Konsistenz zu gewährleisten
  • Betriebssystem legt Lesezeichen im Dateisystem ab (nicht störend)
  • RMM kopiert Bildbits vom statischen Schnappschuss in den Speicher RMM
  • Nur verwendete Daten werden kopiert (auf Dateiebene, nicht auf Blockebene)
  • Bild gespeichert auf RMM Server
  • Zusätzliche Metadaten über das in der CMDB gespeicherte Bild

Hauptmerkmale:

  • Keine Unterbrechung des Ursprungs-Servers (die Produktion läuft weiter)
  • Dateibasierte Replikation (nicht Sektor/Block)
  • Unterstützt Komprimierung und Verschlüsselung
  • Einschluss-/Ausschlusslisten für selektive Daten können angegeben werden

Zuweisen

Zweck: Bereitstellen des erfassten Abbilds auf einem Ziel-VSI Prozess:

  1. AutoProvision ziel-VSI (oder Verwendung eines vorbereiteten Servers)
    • RMM verwendet Metadaten aus Discover, um die Zielgröße entsprechend anzupassen
    • Rückstellungen VSI in VPC
  2. Verbindung zum Ziel über SSH
  3. Ziel untersuchen
    • Überprüfen Sie, ob der Ziel-VSI das Quell-Image VM ausführen kann
    • Verstehen der zugrunde liegenden Hardware
  4. Booten in RackWare Microkernel
    • Bereitstellung des Mikrokernels auf dem Ziel-VSI
    • In Bootloader-Optionen einfügen
    • Ziel-VSI vom Mikrokernel booten
  5. VSI-Zieldatenträger vorbereiten
    • Diskette neu formatieren
    • Struktur des logischen Volumes neu erstellen (exakte Übereinstimmung mit dem Ursprung)
    • Erstellen von Partitionen mithilfe des Best-Fit-Algorithmus
  6. Bild übertragen
    • Übertragen von Bildbits vom Speicher RMM zum Ziel-VSI
    • Injizieren der notwendigen Gerätetreiber für neue Hardware
    • Optionale Änderung der Netzwerkkonfiguration für den Ziel-VSI
  7. Konfigurieren und neu starten
    • Konfigurieren Sie den Bootloader für das aktuelle Betriebssystem
    • Neustart des replizierten Betriebssystems
  8. Verifizierung
    • Überprüfen Sie, ob der Ziel-VSI ordnungsgemäß bootet
    • Überprüfung der korrekten Vernetzung
    • Überprüfung der korrekten Datenreplikation
    • SSH auf dem replizierten Server mit denselben Anmeldedaten wie beim Ursprung

Direkte Zuweisung (auch Flex Sync oder Host Sync genannt)

Dies ist der Ansatz, den wir in diesem Anwendungsfall verwenden.

Zweck: Direkte Replikation von der Quelle VM zum Ziel-VSI ohne Zwischenspeicherung Prozess:

  1. Kombiniert Erfassen + Zuweisen in einem einzigen Vorgang
  2. Führt alle Discover-Funktionen aus
  3. Bereitstellung eines Zielservers (oder Verwendung eines vorhandenen)
  4. Bereitet den Zielserver vor
  5. Repliziert direkt von der Quelle VM zum Ziel-VSI
  6. Die Netzwerkverbindung kann weiterhin über RMM geleitet werden (keine direkte Quelle-Ziel-Verbindung erforderlich)

Sync (Delta-Synchronisierung)

Zweck: Ziel mit nur geänderten Daten aus der Quelle aktualisieren VM Prozess:

  1. Erstellt einen Snapshot auf der Quelle VM (LVM oder VSS)
  2. Berechnet Delta (nur geänderte Dateien)
  3. Überträgt nur geänderte Daten zum Ziel
  4. Aktualisierungen entweder:
    • Captured Image auf RMM storage, OR
    • Laufender Zielserver, OR
    • Beide (Bild + Zielserver)

Synchronisationsoptionen

  • Stufe I Sync
    • Herkunft → RMM Speicherung (aufgenommenes Bild)
    • Aktualisiert nur das gespeicherte Bild
  • Stufe II Sync
    • RMM Speicherung → Zielserver
    • Aktualisiert das laufende Ziel aus dem gespeicherten Bild
  • RMM Durchleitung
    • Herkunft → RMM → Ziel
    • Daten fließen durch RMM, bleiben aber nicht erhalten
    • Keine Speicherung auf RMM erforderlich
  • Direkte Synchronisierung
    • Ursprung → Ziel (direkte Verbindung)
  • Selektive Synchronisation*
    • Nur bestimmte Dateien/Verzeichnisse synchronisieren
    • Verwendet Include/Exclude-Listen
  • Laufwerk/Verzeichnis-Zuordnung
    • Zuordnung bestimmter Ursprungspfade zu verschiedenen Zielpfaden

Sync-Motoren:

  • RWSync (Standard):
    • Agentless
    • Ausfallsicherheit des Netzes
    • Verarbeitet massive gleichzeitige Aktualisierungen
    • Enthält die endgültige Prüfsumme
    • Langsamer als TNG
  • TNG (Fortgeschrittene):
    • Erfordert die Installation von Delta File Tracker
    • Viel schneller und effizienter
    • Für große Server, hohe Aktualisierungsraten, aggressive RPO
    • Muss in Antivirus auf die Whitelist gesetzt werden
    • Anfälliger für Netzausfälle
    • Unterstützt keine entfernten NFS /CIFS-Mounts

Der RackWare Mikrokernel-Boot-Prozess

Während des Zuweisungsvorgangs bootet RMM den Ziel-VSI in einen RackWare Mikrokernel, und die Boot-Diskette wird neu formatiert, wobei sichergestellt wird, dass die Dateisysteme, ihre Typen und Größen mit denen der Quelle VM übereinstimmen. RMM versucht auf der Grundlage des Layouts der Zielfestplatte und der Partitionen, die in die Quelle passen sollen, eine optimale Anpassung.

Microkernel-Bereitstellung

Wenn RackWare einen Ziel-VSI für den Empfang des replizierten Images vorbereitet:

  • RMM stellt einen RackWare Mikrokernel auf dem Ziel-VSI bereit
  • Dieser Mikrokernel "fügt sich in die Bootloader-Optionen" des Betriebssystems der Plattform ein
  • Der Mikrokernel bootet vom Bootloader (GRUB auf Linux )

Der Mikrokernel kann als LiveCD, betrachtet werden und ist eine minimale bootfähige Umgebung, die:

  • Beherbergt die erforderlichen Treiber für die Zielhardware
  • Ermöglicht der RMM die Kommunikation mit dem Zielserver
  • Ermöglicht die Neuformatierung der Festplatte und die Erstellung von Partitionen
  • Erleichtert die eigentliche Datenübertragung vom Ursprung zum Ziel
  • Konfiguriert das System für die neue Hardwareumgebung

Während der Zuordnungsphase, RackWare:

  1. Startet den Ziel-VSI in den Mikrokernel (über GRUB-Eintrag)
  2. Formatiert die Festplatte im Mikrokernel neu
  3. Erzeugt die Partitionsstruktur entsprechend der Quelle neu VM
  4. Erzeugt logische Volumes, um die LVM-Struktur zu erstellen
  5. Überträgt die Daten der Quelle VM auf den Ziel-VSI
  6. Injiziert die notwendigen Treiber für die Zielhardware
  7. Konfiguriert GRUB zum Booten des aktuellen Betriebssystems
  8. Neustart des replizierten Betriebssystems

RackWare ändert die GRUB-Konfiguration zu:

  • Hinzufügen eines temporären Mikrokernel-Boot-Eintrags während des Zuweisungsprozesses
  • Konfigurieren Sie die richtigen Boot-Parameter für das replizierte Betriebssystem
  • Festlegen der Standard-Boot-Option für das replizierte Betriebssystem nach Abschluss der Übertragung
  • Alle Kernel-Parameter, die für die neue Hardware benötigt werden, werden verarbeitet

Für Windows-Systeme:

  • Windows Boot Manager wird anstelle von GRUB verwendet
  • Es gilt das gleiche Mikrokernel-Konzept
  • Microkernel fügt sich in die Windows-Boot-Konfiguration ein
  • Nach der Replikation zeigt die Startkonfiguration auf das replizierte Windows-Betriebssystem

Die Mikrokernel-Umgebung ermöglicht RackWare:

  • Geeignete Speichertreiber einfügen
  • Netzwerktreiber einschleusen
  • Konfigurieren Sie Gerätetreiber für neue Hardware
  • Sicherstellen, dass das replizierte Betriebssystem auf unterschiedlicher Hardware booten kann

Der Replikationsprozess für Deltasynchronisationen, d. h. für nachfolgende Synchronisationen, funktioniert auf dieselbe Weise wie die erste Synchronisation. Die Deltasynchronisation wird nach dem Neustart des Zielservers mit dem Mikrokernel RackWare durchgeführt. Sobald die Deltasynchronisation abgeschlossen ist, wird der Ziel-VSI wieder in das Host-Betriebssystem gebootet,

Dieser Mikrokernel-Ansatz ist ein wesentliches Unterscheidungsmerkmal für RackWare, da er es ihnen ermöglicht, die Komplexität plattform- und hypervisorübergreifender sowie physischer und virtueller Migrationen zu bewältigen, indem sie die vollständige Kontrolle über die Zielumgebung während der kritischen Übertragungs- und Konfigurationsphase haben.

RackWare Passthrough mit direktem Sync-Prozess

Das Verfahren ist wie folgt:

  1. RMM Entdeckt die Quelle VM
RMM → Bridge (10.194.177.82) → Source VM (192.168.10.11)
  • RMM verbindet sich über SSH mit 10.194.177.82 (NAT IP)
  • Bridge bedeutet übersetzt 192.168.10.11
  • RMM sammelt Metadaten: Betriebssystem, Dateisysteme, Festplattenlayout usw.
  1. RMM Entdeckt das Ziel VSI
RMM → Target VSI (192.168.10.11)
  • RMM verbindet sich über SSH mit 192.168.10.11
  • Untersucht die Zielhardware und -fähigkeiten
  1. RMM Erstellt einen umgekehrten SSH-Tunnel zum Ziel-VSI

Die RMM Automatisierung erstellt einen umgekehrten SSH-Tunnel zwischen dem Ziel-VSI und der Quelle VM über den RMM Server:

Target VSI (192.168.10.11)
  │
  └─ localhost:23 ──[SSH Tunnel]──► RMM ──► Bridge ──► Source VM:22

  1. RMM initiiert SSH-Verbindung zum Ziel-VSI

  2. Erzeugt einen abhörenden Port (23) auf dem Ziel

  3. Jede Verbindung zu localhost:23 auf dem Ziel wird weitergeleitet:

    • Durch den SSH-Tunnel zurück zu RMM
    • RMM weiterleitung an 10.194.177.82:22 (Quelle über Brücke)
    • Überbrückung von DNATs zur eigentlichen Quelle

    Visueller Fluss:

    Target:       [App tries localhost:23]
                       ↓
               [SSH tunnel to RMM]
                       ↓
RMM: [Receives and forwards to 10.194.177.82:22]
                       ↓
 Bridge: [DNAT: 10.194.177.82 → 192.168.10.11]
                       ↓
Source:   [Receives connection on port 22]

  4. Dateisysteme einhängen

RMM mountet Dateisysteme sowohl auf der Quelle als auch auf dem Ziel mit Befehlen, die den folgenden Beispielen ähneln:

Auf Quelle VM (über Brücke):

# RMM executes on source
mount --bind / /mnt/rackware/tmp.xxxxx

On Target VSI (direkt):

# RMM executes on target
mount /dev/vda2 /mnt/rackware/tmp.yyyyy
  1. Datenübertragung

RMM führt die Datenübertragung auf dem Ziel-VSI aus, um Daten von der Quelle VM zu ziehen:

  1. GRUB-Installation

RMM installiert und konfiguriert GRUB auf dem Zielrechner für UEFI-Boot:

  • Kopiert GRUB-Bootloader-Dateien
  • Erzeugt grub.cfg mit korrekten Kernelparametern
  • Erzeugt UEFI-Boot-Einträge
  • Konfiguriert für neue Hardware-Treiber
  1. Aushängen von Dateisystemen
# On both source and target
umount /mnt/rackware/tmp.xxxxx

  1. Tunnel schließen

  2. RMM schließt den SSH-Tunnel zum Ziel

  3. Port 23 hört auf, das Ziel zu überwachen

  4. Dienstprogramme entfernen

# RMM removes temporary files from source and target
rm -rf /var/tmp/rackware/

Referenzen