Auf der Suche nach dem besten Weg für dieses Unterfangen fühlten wir uns von den großen Suchmaschinen etwas vernachlässigt. Es fand sich kein für uns gut gangbarer Weg, der es uns erlaubt hätte, die virtuellen Maschinen "einfach umzuziehen".
Die allgemein im Internet vorzufindende Aussage zu unserer Recherche lautete: "Neu Installieren und dann die Nutzdaten umziehen". Unter Linux wäre es eventuell noch halbwegs gut möglich gewesen, /etc per RSync zu kopieren, aber wirklich glücklich waren wir mit dieser Aussage nicht, denn unserer Erfahrung nach gibt es nur wenige gute Wege zwischen alles kopieren und komplett neu aufsetzen eines Systems. Wir begaben uns also selbst noch einmal auf die Suche nach Möglichkeiten, um alles kopieren zu können. Doch zuvor noch ein paar Worte zum Setup vor Ort, das glücklicherweise nicht besonders kompliziert war:
Das Setup vor der Migration
Die bestehenden LXC-Container liefen bis dato auf dem lokalen Storage des Proxmox VE Servers. Unter ESX sollten sie nun gleich auf einem ebenfalls frisch eingeführten SAN abgelegt werden. Die beiden Hypervisor standen im selben Netz und waren direkt durch einen Gigabit fähigen Ethernet Switch verbunden.
| Gerät | IP-Adresse |
|---|---|
| Proxmox VE Host | 192.168.0.2 |
| ESX Host | 192.168.0.3 |
Proxmox legt für LXC Container einzelne Logical Volumes in LVM an, welche direkt das Dateisystem des Containers beinhalten. In unserem Fall ging es ausschließlich um Linux Container, die mit ext4 Dateisystem betrieben wurden. Wir hatten also die folgende Schachtelung:
Unser Plan bestand nun darin, das Dateisystem des einzelnen Containers in eine neue leere VM auf ESX zu übertragen und, dort angekommen, zu einer vollvirtualisierten-VM auszubauen.
Bei LXC Containern handelt es sich ja bekanntlich um eine Form der Paravirtualisierung, was bedeutet, dass direkt im Container weder ein Kernel noch ein Bootloader installiert sind. Beides würde aber im geplanten neuen Zuhause unter ESX benötigt werden, so dass wir nicht umhin kamen, nach dem Kopieren der Daten nochmals tätig zu werden. Da der Hauptzeitverbrauch bei einer solchen Migration mit Wechsel des Storage der Datentransfer selbst sein würde, suchten wir uns zum Testen einen möglichst kleinen LXC-Container aus.
Tip für Nachahmer: Wer keinen kleinen LXC-Container hat, der kann sich auf der alten Umgebung zum Testen einfach einen solchen anlegen und diesen wie die restlichen einrichten.
Erfolgreich mit einem Test-LXC-Container ausgestattet, konnten wir die Migration erproben und folgenden Pfad ausarbeiten:
Migrationspfad Proxmox-VMware
- Erstellen einer neuen VM auf dem ESX Host sowie Zuweisen einer Festplatte, die gleich groß oder etwas größer als die alte Platte des LXC-Containers auf der Proxmox-Instanz ist:
Die Erweiterung eines Dateisystems ist im allgemeinen recht einfach möglich, wohingegen dessen Verkleinerung oder das punktgenaue Umkopieren nur unnötige Komplexität schafft, die mit einigen GB mehr für die neue VM schlichtweg vermieden werden kann. - Starten von GParted auf der neuen VM im ESX Cluster und Vorbereiten für den Zugriff mit SSH:
Ziel ist es vom Proxmox VE Host per SSH auf die neue VM zugreifen zu können. Dies kann sowohl per SSH-Key als auch per Passwort geschehen. Wir entschieden uns für die Kennwort-Variante, da das Setup ohnehin nicht dauerhaft bestehen sollte. Zu diesem Zweck muss ein root-Kennwort gesetzt sowie der Login per SSH erlaubt werden. Außerdem wird natürlich eine IP-Adresse und ein aktives Netzwerk-Interface benötigt. Zu guter Letzt muss auch der SSH-Dienst noch laufen, damit SSH verwendet werden kann. passwd
rm /etc/hosts.deny###linebreak###sed -i "s/#PermitRootLogin.*/PermitRootLogin yes/g" /etc/ssh/sshd_config###linebreak###ip addr add 192.168.0.4/24 dev eth0###linebreak###ip link set up dev eth0###linebreak###systemctl restart ssh###linebreak###ip route add default via 192.168.0.4
- Eintragen der Nameserver für die DNS-Auflösung:
Unsere neue VM auf ESX-Basis würde Pakete herunterladen müssen, daher sollte auch für die Namensauflösung gesorgt sein.
echo "nameserver 192.168.0.253" >> /etc/resolv.conf
- Konnektivität testen:
Wenn die Paketquellen erfolgreich abgerufen werden können, ist die VM in puncto Konnektivität fertig vorbereitet.
apt-get update
- Nun fehlen noch ein paar Schritte, damit das Dateisystem des LXC-Containers erfolgreich aufgenommen werden kann.
- Erstellen einer Partitionstabelle und Erzeugen einer Partition OHNE Dateisystem, sowie Setzen des boot Flags auf der Partition mit GParted:
Bisher hängt in der neuen VM nur die leere Festplatte, die wir in Schritt 1 erstellt haben. Wir möchten hier eine vergleichbare Kapsel für das Dateisystem schaffen, wie sie auch unter Proxmox vorhanden war, also eine Art "Ersatz-Ei" für unser "Küken".
- Prüfen, ob der alte Container privilegiert war:
Im Laufe unserer Arbeit mussten wir lernen, dass es für die Migration einen Unterschied macht, ob der LXC-Container auf Proxmox privilegiert war oder nicht. Wenn der Container auf Proxmox unprivilegiert lief, so werden bei einigen Usern und Gruppen nach dem Transfer den Dateien falsche ID-Nummern zugeteilt. Bei diesen Containern mussten wir folglich anschließend noch mittels find die Dateien wieder ihren richtigen Usern zuführen. Vor allem der root User sollte vor einem Start der fertigen VM unbedingt geprüft werden. Wenn ein Container unprivilegiert betrieben wurde, steht die ID nach dem Übertragen nicht als 0 im Dateisystem. - Prüfen, ob auf dem ext2-3-4 Dateisystems des alten Containers mmp aktiviert war:
Ein weiterer Stolperstein beim Migrieren ist das mmp Flag unter ext4 Dateisystemen, die Proxmox für seine LXC-Container erstellt hat. Dieses Feature verhindert, dass das Dateisystem von verschiedenen Punkten gleichzeitig schreibend gemounted wird. Vermutlich handelt es sich dabei um einen Schutzmechanismus, falls Proxmox im Cluster betrieben wird und verhindert werden soll, dass zwei Hosts den Container gleichzeitig starten. Dazu kann auf dem Proxmox Host mit folgendem Befehl geprüft werden, ob mmp in dem Dateisystem aktiviert ist:
dumpe2fs /dev/mapper/pve-vm--114--disk--0 | grep -i mmp
- Erhält man eine Ausgabe, ist mmp aktiv, kommt nichts zurück, ist mmp deaktiviert. Sollte sich dabei nun herausstellen, dass mmp aktiv ist, muss es nach dem Transfer des Dateisystems deaktiviert werden, da es ansonsten zu Problemen beim Booten führen würde.
- Ausstellen des alten Containers auf Proxmox:
Alles ist nun vorbereitet. Damit das Dateisystem des Containers still ist, während es transferiert wird, muss der Container ausgeschaltet werden. - Kopieren der Daten des LXC-Containers vom Proxmox-Host aus:
Mit folgendem Befehl kann vom Proxmox-Host aus das Dateisystem mittels dd über SSH direkt in die leere Partition der neuen ESX-VM geschrieben werden:
dd if=/dev/mapper/pve-vm--114--disk--0 | pv | ssh root@191.168.0.4 "dd of=/dev/sda1"
Sobald der Datentransfer durchgelaufen ist, sollte das Zwischenergebnis gesichert werden. Sollte es anschließend noch zu Problemen kommen, müssen die Daten nicht wieder neu transferiert werden.
- Anlegen eines Snapshots der ESX-VM (mit RAM):
Es empfiehlt sich, den Snapshot mit Arbeitsspeicher zu erstellen, damit nicht die komplette Setup-Arbeit um GParted herum wiederholt werden muss. - Deaktivieren von mmp und Reparaturversuch des frisch beschriebenen Dateisystems sowie Erweiterung auf die neue Partitionsgröße:
Mittels tune2fs kann mmp für das frisch umkopierte Dateisystem deaktiviert werden. Darauf sollte direkt fsck folgen, um sicherzugehen, dass es beim Transfer zu keinen Schäden gekommen ist. Anschließend darf das Dateisystem in seine neue Partition hineinwachsen. Dies kann mittels resize2fs erledigt werden.
tune2fs -O ^mmp /dev/sda1###linebreak###fsck -f /dev/sda1###linebreak###resize2fs /dev/sda1
- An dieser Stelle ist das System von Proxmox auf die Partition in der ESX-VM umgezogen. Da es aber aufgrund der Paravirtualisierung von Proxmox Containern darauf weder einen Kernel noch einen Bootloader gibt, müssen diese nun noch manuell nachinstalliert werden.
- Wechsel auf das neu umkopierte System mittels Changeroot:
mount /dev/sda1 /mnt###linebreak###mount --rbind /dev /mnt/dev###linebreak###mount --rbind /sys /mnt/sys###linebreak###mount -t proc /proc /mnt/proc###linebreak###chroot /mnt /bin/bash###linebreak###
- Das neue Dateisystem wird in der GParted Live Umgebung eingehängt und mit den Ressourcen des gebooteten GParted über seine Umgebung in Kenntnis gesetzt. Anschließend kann mittels chroot in das umgezogene System gewechselt werden.
- Ändern der Standard-Route und Anpassen des Interface-Namens in /etc/network/interfaces:
Da wir einfach das Dateisystem kopiert haben, sich aber der Hardwareunterbau komplett geändert hat, stimmt der Name des Netzwerk-Interfaces nun nicht mehr. Wir haben den Namen unter /etc/network/interfaces angepasst, aber dieser Punkt muss auf das verwendete Linux angepasst ausgeführt werden - Installieren von Paketen, um die Paravirtualisierte-VM zu einem vollwertigen Linux zu machen:
apt install linux-image-amd64 grub2 kbd open-vm-tools
- Der Bootloader sollte auf /dev/sda installiert werden.
- Erstellen einer kompletten fstab Datei:
Bislang war aufgrund der Paravirtualisierung keine komplette fstab Datei nötig. Eine solche wird nun jedoch benötigt. Zu diesem Zweck kann einfach die Ausgabe von blkid an die bestehende /etc/fstab Datei angefügt werden. Es muss dann nur noch alles Unnötige heraus editiert werden, so dass korrekte Einträge entstehen. Die Ausgabe von blkid liefert dabei die UUID Werte der neuen Partition.
blkid >> /etc/fstab###linebreak###vim /etc/fstab
- Syntaxbeispiel:
/etc/fstab###linebreak###UUID=MYUUID / ext4 errors=remount-ro 0 1
- Damit sind nun alle Schritte abgeschlossen, um aus dem umgezogenen Dateisystem eine bootbare Linux-VM zu machen.
Prüfen auf falsche User und Gruppen IDs:
An dieser Stelle bietet sich eine gute Gelegenheit zur Überprüfung der Dateirechte. Falls sich in Schritt 6 herausgestellt hat, dass der ursprüngliche Container auf Proxmox unprivilegiert lief, sollten jetzt die Auswirkungen dieses Problems vorliegen und behoben werden.
In unserem Fall hatten wir bei ehemals unprivilegierten Containern das Zwischenergebnis, dass alle Dateien, die root gehören sollten, der ID 10000 gehörten. Zur Behebung ist es ideal, dass wir gerade in einer chroot Umgebung sind. Mittels find können die falsch zugeordneten Dateien gefunden und angepasst werden.
Es lohnt sich auf jeden Fall, an dieser Stelle ein wenig Zeit zu investieren und zu prüfen, welche Rechte an welchen Dateien geändert werden müssen. Unsere Beispiel-Lösung ist sicherlich eine verallgemeinerte und wird nicht hundertprozentig auf die individuellen Bedürfnisse jedes Systems passen.
find / -uid 100000 -gid 100000###linebreak###find / -uid 100000 -gid 100000 ! -type l -exec chown 0:0 {} +- Sollten weiterhin falsche Rechte gesetzt sein, kann das System selbst auch durch eine manuelle Neuinstallation aller Pakete korrigiert werden.
dpkg --get-selections | grep -v deinstall | awk '{print $1}' > list.log###linebreak###apt-get install --reinstall $(cat list.log)
Neustarten der ESX-VM:
Die VM kann nun neu gestartet werden. Dazu muss man erst das chroot System verlassen und die Dateisysteme mit dem umount Befehl aushängen. Die VM sollte NICHT mittels reboot neugestartet, sonden erst heruntergefahren werden. In ausgeschaltetem Zustand wird die GParted Live CD entfernt und anschließend die VM über ESX wieder neu angeworfen.
Testen:
An dieser Stelle lohnt es sich, nochmals alle Funktionen der VM durchzugehen und sich dazu etwas Zeit zu nehmen. Wer an dieser Stelle Zeit spart, bereut es an anderer Stelle. Insbesondere ist es zu prüfen, ob alle Dienste laufen, die Netzwerkinterfaces funktionieren und alle benötigten Netze und Routen zu Verfügung stehen. Nicht vergessen sollte man, die iptables-Regeln an die Namen der neuen Netzwerk-Interfaces anzupassen.
Nun können theoretisch noch weitere Änderungen folgen:
- Falls gewünscht, könnte die Partitionierung der VM noch aufgesplittet werden. Aktuell handelt es sich ja nur um eine große Root Partition.
- Möglicherweise müssen Überwachungssysteme oder Funktionen geprüft werden, die von außen auf die VM zugreifen und z.B. mit anderer MAC-Adresse rechnen.
Resümee
Mittels der beschriebenen Vorgehensweise konnten wir es umgehen, für jeden LXC-Container eine komplett neue Installation vornehmen zu müssen. Zwar ist der Migrationspfad auch nicht in 5 Minuten abgearbeitet, aber je nach Menge und Komplexität der Container kann der Aufwand, die Container manuell zu echten VMs auszubauen, lohnen. In unserem konkreten Fall hat es sich bei einer Menge von 6 Containern und etwa 450 GB Nutzdaten auf jeden Fall gelohnt.
