Laufendes Linux: Image ziehen und in VirtualBox booten
Verlockend: Vom Windows-Desktop aus ein 1:1-Abbild eines laufenden Systems über das Netzwerk ziehen und dann lokal als virtuelle Maschine booten
Eine virtuelle Version eines Systems kann echt praktisch sein. Etwa zum Herumspielen, um Hardware durch VMs zu ersetzen oder als nutzbares Backup, wenn das echte System dauerhaft ersetzt wird. Und für die meisten von uns sieht die Situation doch so aus: Ein Windows- als Arbeitsplatzrechner, ein Linux im Netzwerk auf zum Beispiel einem Raspberry Pi, daran kein eigener Monitor und keine Lust, den Rechner auszuschalten oder gar irgendetwas anzustöpseln. Und da geht es los.
Tools und Workflow
Zunächst vorweg: Es geht hier wirklich um ein laufendes System! Es ist immer zuverlässiger, das System herunterzufahren, von einem Live-System zu booten und dann ein Image zu ziehen. Auch ist es eigentlich eine gute Idee, ein System zunächst für so einen Umzug anzupassen, beispielsweise fix konfigurierte Netzwerkverbindungen zu deaktieren oder Mounts zu entfernen, die in der VM später nicht zur Verfügung stehen werden. Aber hier geht es nicht um maximale Zuverlässigkeit, sondern um Bequemlichkeit, Standard-Tools und Performance.
Die Ausgangssituation ist hier ganz konkret: Arbeitsplatz ist ein Rechner mit Windows 11, das Image wird von einem Ubuntu auf einem Cubi-Server gezogen und später auf dem Windows-Desktop in VirtualBox gebootet. Die Tools: dd für Imaging und gegebenenfalls Transfer, VBoxManage für die Konvertierung von Image nach VM und natürlich VirtualBox zum Betreiben der VM.
Und hier noch eine TLDR-Version, falls Ihr keine Erläuterungen braucht:
1. Auf dem Linux (192.168.178.100): root über SSH erlauben (/etc/ssh/sshd_config --> PermitRootLogin yes)
2. ssh root@192.168.178.100 "dd if=/dev/sda " | dd of=/d/meine-daten/mein-image.img
3. vboxmanage.exe convertfromraw mein-image.img meine-virtuelle-festplatte.vdi
4. VDI in VirtualBox-VM mit EFI-Support booten
Für allen anderen ein wenig mehr Kontext ;)
1. Image erstellen und transferieren
Ihr habt hier zwei Möglichkeiten: Entweder Ihr erstellt das Image komplett auf dem Linux-System und speichert es auf einem Netzlaufwerk, das auch dem Windows-Desktop zur Verfügung steht. Oder Ihr streamt das Image auf den Windows-Rechner. Ersteres ist tendenziell zuverlässiger und performanter. Für beide Varianten haben wir einen ausführlicheren Artikel, folgend die Kurzversionen.
Die Netzlaufwerk-Version:
1. SSH-Verbindung zum Linux aufbauen:
ssh peter@192.168.178.100
2. Image per dd auf Laufwerk „meine-netzlaufwerk“ speichern:
dd if=/dev/sda of=/media/meine-netzlaufwerk/mein-image.img --status=progress
Dabei muss if (input file) auf die Boot-Platte zeigen – in aller Regel /dev/sda. of (output file) sagt entsprechend, wo das Image gespeichert werden soll. Die letzte Option sorgt für eine minimale Fortschrittsanzeige.
Die Streaming-Version:
Hier benötigt Ihr dd auch auf dem Windows-Rechner! Das Programm ist im Bash-Terminal verfügbar, das Ihr zum Beispiel über Git for Windows bekommt und auch hier im Einsatz ist. Alternativ könnt Ihr auch das Windows-eigene WSL nutzen.
Voraussetzung: Auf dem Linux-System muss entweder root über SSH erlaubt sein oder dd ohne root-Rechte. Hier mit root über SSH:
1. root über SSH auf Linux-Rechner:
ssh peter@192.168.178.100
sudo nano /etc/ssh/sshd_config
Hinzufügen: PermitRootLogin yes
sudo service sshd restart
2. Imaging auf Windows-Rechner:
ssh root@192.168.178.100 "dd if=/dev/sda " | dd of=/d/meine-daten/mein-image.img
Das ist das Schöne an dd, man kann den Input einfach via Pipe (|) an eine andere dd-Instanz weiterreichen und diese die Output-Datei erzeugen lassen. Der Vorgang wird tendenziell ziemlich lange dauern! Denn dd erstellt 1:1-Kopien der Laufwerke – auch vom nicht belegten Speicher. Eine 50-Gigabyte-Platte ergibt ein 50-Gigabyte-Image, selbst wenn nur 5 Gigabyte belegt sind.
Tipp: Falls Ihr erstmal mit dd herumspielen wollt, ohne stundenlang zu warten:
ssh root@192.168.178.100 "echo Hello World " | dd of=/d/meine-daten/test-image.img
dd frisst im Grunde alles als Input, auch ein wenig guten alten Text.
2. Image konvertieren
So ein rohes Image ist zwar eine genaue Kopie des Originals, samt aller Partitionen und Boot-Informationen, aber noch keine virtuelle Festplatte. Die lässt sich ganz einfach mit einem VirtualBox-Tool erzeugen:
vboxmanage.exe convertfromraw mein-image.img meine-virtuelle-festplatte.vdi
Anschließend habt Ihr eine neue virtuelle Festplatte im VDI-Format. Wobei dieses „anschließend“ schon bei einer 50-Gigabyte-Platte mehr als nur zwei, drei Kaffeepäuschen auf sich warten lässt.
3. Image booten
Genau an diesem Punkt haben viele Nutzer ein großes Problem: Die virtuelle Festplatte bootet eben nicht. Das kann an etlichen Ausgangskonfigurationen liegen, die meist nur kompliziert zu beheben sind. Gerade bei Einsteigern würde ich Folgendes eher für plausibel halten: Es wird eine vorhandene virtuelle Maschine genutzt, um das Image zu booten – und das wird oft fehlschlagen. Denn vermutlich hat Euer dd’tes Image ein EFI-System abgebildet. Legt man eine neue VM in VirtualBox an, ist die EFI-Funktion aber standardmäßig nicht aktiv.
Soll heißen: Erstellt eine neue virtuelle Maschine in VirtualBox und aktiviert im Assistenten oder später unter Einstellungen/System/Erweitert den EFI-Support. Nicht-EFI-Systeme können dann freilich nicht mehr in dieser VM booten. Ihr seid nicht sicher? Schaut einfach nach, ob /sys/firmware/efi existiert – wenn nicht, braucht Ihr auch keinen EFI-Support.
- Erstellt eine neue VM
- Nutzt als Massenspeicher die konvertierte VDI-Datei
- Aktiviert den EFI-Support
- Setzt Ressourcen, die zum Image/Originalsystem passen
- VM starten
Nun sollte die VM booten. Allerdings kann es gut sein, dass es allerlei Fehlermeldungen gibt, der Boot-Vorgang vielleicht einige Zeit vergeblich versucht, Start-Jobs auszuführen und so weiter – habt Geduld. Manche Dinge brauchen einfach Zeit, im Zweifel könnt Ihr es mit STRG+C versuchen, um den laufenden Prozess abzubrechen, wenn klar ist, dass dieser eh nicht ausführbar ist (zum Beispiel irgendwelche Mounts).
Solltet Ihr dann irgendwann in den Genuss eines Logins kommen, müsst Ihr gegebenenfalls allerlei Dinge anpassen, schließlich haben sich aus Systemsicht plötzlich Dinge wie Hardware und Netzwerkadresse verändert.
