debian von rechner in vm exportieren

[DEBIO]

hallo, ich frage mich seit einiger zeit wie und ob man überhaupt ein linux system in eine vm exportieren kann, oder ob man ein laufendes linux system mit z.b. einem raid 5 auf einen anderen rechner exportieren kann.

also ein image und das wieder auf einen anderen rechner rückspielen, wie bei windows shadow copy.

gibts da auch was bei linux

[schorsch_76]

Hi,

also ich mach das immer auf die folgende Art:
1. mit tar alle Dateien des Linux Systems sichern. Persönlich hab ich immer extra Archive für jedes Mount.
2. Auf dem Zielsystem ein Livesystem oder Rettungssystem booten
3. Tar Archive dort entpacken (Laufwerke aufpassen - Mounts) /etc/fstab gegebenenfalls anpassen
4. chroot ins neue System
5. Bootloader in MBR schreiben
6. kernel reconfigure machen für initrd

Danach läuft das System wieder auf der neuen Hardware. Unter Linux ist alles nur ein file. Deshalb funktioniert das hier so gut

Gruß

schorsch

[DEBIO]

bedeutet das du tarst die system dateien im laufendem betrieb?

[Faber38]

macht die unterschiedliche Hardware vom PC zu VM-ware nicht Probleme?

ich kann mir das nicht vorstellen ohne Komplikationen.

[schorsch_76]

Nein. Ich mach das tar mit einem Rettungssystem. Da der Linuxkernel modular ist und die initrd beim neukonfigurieren des Kernel neu gebaut wird, hab ich da keine Probleme

Was soll den die VM von echten System unterscheiden? Nix ... Module ausgetauscht (beim dpkg-reconfigure) und die API ist da

Der kritischte Punkt ist der Bootloader, dass der richtig in den MBR kommt. Das rootdevice dem kernel richtig übergeben wird sind die wichtigsten Punkte.

Gruß

schorsch

[DEBIO]

bedeutet das du fährst mit knoppix hoch und machst dann ein image vom system?

oder machst du das im laufendem betrieb?
also eine copy mit cp vom root verzeichnis aus?

[debianoli]

Mit cp geht das nicht, du brauchst tar! Dann geht es auch vom laufenden Betrieb aus. Dazu gibt es einige Threads hier im Forum. Hier hab ich zB mal geschrieben, wie du per tar eine Sicherung eines laufenden Systems erstellst. Die musst du dann nur in der virtuellen Machine entpacken (über eine Live-CD, die du in der virt. Manschine startetst). http://debianforum.de/forum/viewtopic.p ... =0#p756574

[gbotti]

Ich würd das so machen:
Knoppix-CD in VM starten und überprüfen, ob der SSH-Client aktiviert ist und die
Festplatte mit dem passenden Filesystem und den entsprechenden Partitionen vorbereiten und mounten!

Weitere Knoppix-CD auf dem zu virtualisierenden Rechner starten.
Auf dem zu virtualisierenden Rechner dann die Partitionen "read only" mounten und mit

Code: Alles auswählen

cd /MOUNTPUNKT
tar -czf - * | ssh ZIELRECHNER tar -xvzf -

auf den anderen Rechner transferieren.

Das ganze dann mit den anderen Partitionen wiederholen.
Zuletzt muss der Bootloader natürlich noch in der VM eingerichtet werden.

Vorteile: - Du musst nicht eine riesen TGZ-Datei erstellen und wieder entpacken
- Das zu lesende Dateisystem kann als "read only" gemountet werden und
wird nicht verändert.
- Das VM-Filesystem wird nicht unnötig aufgebläht, da keine große TGZ-Datei in das Filesystem kopiert werden muss
- Verschlüsselte Übertragung.

Beschreibung zum Befehl:
Zuerst wird mit tar eine tgz im Speicher auf STDOUT "-" geschrieben. Mit der PIPE wird das ganze an
SSH übergeben, dass auf dem Zielrechner den tar-Befehl mit STDIN startet.

Das ganze könnte man natürlich auch mit "dd" machen. Da hast du dann nur das Problem, dass die VM-Festplatte
mindestens genau so groß sein muss und falls du dynamisch anwachsende Festplatten verwendest sofort die gesamte
Größe der Ursprungsfestplatte fällig wird. Das Problem entfällt mit der TAR-Methode.

Viel Erfolg.

[debianoli]

Ich würd das so machen:
Knoppix-CD in VM starten und überprüfen, ob der SSH-Client aktiviert ist und die
Festplatte mit dem passenden Filesystem und den entsprechenden Partitionen vorbereiten und mounten!

Vorteile: - Du musst nicht eine riesen TGZ-Datei erstellen und wieder entpacken
- Das zu lesende Dateisystem kann als "read only" gemountet werden und
wird nicht verändert.
- Das VM-Filesystem wird nicht unnötig aufgebläht, da keine große TGZ-Datei in das Filesystem kopiert werden muss
- Verschlüsselte Übertragung.

Deine Methode eignet sich, um ein System von einem Rechner auf einen anderen per Netzwerk zu übertragen. Aber wozu willst du auch den zu klonenden Rechner per Knoppix starten? Wenn schon per ssh gearbeitet werden soll, dann kannst du dein System auch per rsync im laufenden Betrieb übertragen.

Und dein Kritikpunkt "Das VM-Filesystem wird nicht unnötig aufgebläht, da keine große TGZ-Datei in das Filesystem kopiert werden muss" zählt nicht, da das tar-File nach dem Entpacken gelöscht wird. Oder man legt das tar-File (ist ja eine Sicherungskopie des eigenen Systems!) in einen Austausch-Ordner, über den man zB per Samba von der virtuellen Machine aus zugreift und entpackt es dann wie oben.

Und wie soll deine Methode funktionieren, wenn man auf einem Rechner im laufenden Betrieb das BS auf eine virtuelle Machine auf dem gleichen Rechner übertragen will? das geht nicht, da müsstest du ein Knoppix mit zB virtualbox haben...

mfg

PS: Ein tar mit gunzip-Kompression eines ganzen Debians inkl KDE hat so um die 1,5 bis 2,5 GB. Das ist in der heutigen Zeit keine Größe mehr für eine Datei...

[gbotti]

Hallo.

Deine Methode eignet sich, um ein System von einem Rechner auf einen anderen per Netzwerk zu übertragen. Aber wozu willst du auch den zu klonenden Rechner per Knoppix starten? Wenn schon per ssh gearbeitet werden soll, dann kannst du dein System auch per rsync im laufenden Betrieb übertragen.

Das ist mir durchaus bewusst, dass es sich eignet um ein System von einem Rechner auf den anderen zu übertragen. Den zu klonenden Rechner würde ich per Knoppix starten, da man dort das FS nur "read only" einbinden kann und durch einen falschen Befehl nicht aus versehen etwas löscht.

Das mit dem "laufenden Betrieb (shadow copy)" hab ich ehrlich gesagt überlesen.
Ein laufendes System sichert man natürlich besser mit rsync. In diesem Fall ist das aber nochmal schwieriger. Rsync "kopiert" die Dateien über das Netzwerk / synchronisiert die Laufwerke. Die "shadow copy" funktion unter Windows ist aber nochmal anders, weil diese eine Versionierung der Dateien vornehmen kann. Dies geht mit rsync auch nicht. Dafür gibts zum Beispiel FSVS, Fast System VerSioning (http://fsvs.tigris.org/), welches auf eine Versionierung mittels "Subversion" setzt.

Und dein Kritikpunkt "Das VM-Filesystem wird nicht unnötig aufgebläht, da keine große TGZ-Datei in das Filesystem kopiert werden muss" zählt nicht, da das tar-File nach dem Entpacken gelöscht wird.

Selbst wenn Du die Datei nachträglich wieder löscht bleibt der Speicherplatz auf dem dynamisch wachsenden Datenträger vorerst mal reserviert und die Volume-Datei verkleinert sich nicht wieder. Wenn man keinen dynamischen Datenträger verwendet ist das selbstverständlich egal.

Oder man legt das tar-File (ist ja eine Sicherungskopie des eigenen Systems!) in einen Austausch-Ordner, über den man zB per Samba von der virtuellen Machine aus zugreift und entpackt es dann wie oben.

Auch ne Möglichkeit. Aus den Informationen konnte ich aber nicht davon ausgehen, dass ein dritter Rechner mit benutzt werden soll.

Und wie soll deine Methode funktionieren, wenn man auf einem Rechner im laufenden Betrieb das BS auf eine virtuelle Machine auf dem gleichen Rechner übertragen will? das geht nicht, da müsstest du ein Knoppix mit zB virtualbox haben...

Das funktioniert natürlich nicht, wie bereits erwähnt hab ich das mit dem "laufenden Betrieb" überlesen. Außerdem steht im Text von DEBIO nicht, dass die VM-Software auf dem gleichen Rechner läuft. Das wäre ja auch (meines erachtens) blödsinnig dort eine Sicherungskopie in die VM reinzulegen. Wenn das Host-System "abraucht" kommt man dann auf die Kopie auch erst mal nicht mehr.

PS: Ein tar mit gunzip-Kompression eines ganzen Debians inkl KDE hat so um die 1,5 bis 2,5 GB. Das ist in der heutigen Zeit keine Größe mehr für eine Datei...

Bei einer Neuinstallation kann ich Dir recht geben, aber was ist mit den Dateien, die ggf. hinzugekommen sind?

In diesem Sinne...

Gruß
Georg

[debianoli]

Das mit dem "laufenden Betrieb (shadow copy)" hab ich ehrlich gesagt überlesen.
Ein laufendes System sichert man natürlich besser mit rsync. In diesem Fall ist das aber nochmal schwieriger. Rsync "kopiert" die Dateien über das Netzwerk / synchronisiert die Laufwerke. Die "shadow copy" funktion unter Windows ist aber nochmal anders, weil diese eine Versionierung der Dateien vornehmen kann. Dies geht mit rsync auch nicht. Dafür gibts zum Beispiel FSVS, Fast System VerSioning (http://fsvs.tigris.org/), welches auf eine Versionierung mittels "Subversion" setzt.

ok, dafür habe ich das mit FSVS überlesen. Ich habe schon öfters den anderen Weg beschrieben und ein in einer virt. Maschine installiertes Linux später auf eine Festplatte übertragen. Klappt auch ganz gut.

Selbst wenn Du die Datei nachträglich wieder löscht bleibt der Speicherplatz auf dem dynamisch wachsenden Datenträger vorerst mal reserviert und die Volume-Datei verkleinert sich nicht wieder. Wenn man keinen dynamischen Datenträger verwendet ist das selbstverständlich egal.

War mir neu, danke für den Hinweis. Du redest sicher von Virtualbox, oder?

Auch ne Möglichkeit. Aus den Informationen konnte ich aber nicht davon ausgehen, dass ein dritter Rechner mit benutzt werden soll.

War auch nicht auf einen dritten Rechner bezogen, sondern mehr auf das Einrichten der Maschine auf einem Rechner. Leider sagt der Thread-Starter nicht, was mit dem Umzug erreicht werden soll. Ich dachte zuerst, da soll eine virtuelle Maschine zum gefahrlosen Rumspielen erstellt werden (dann würde das ja Sinn machen).

Bei einer Neuinstallation kann ich Dir recht geben, aber was ist mit den Dateien, die ggf. hinzugekommen sind?

Selbst dann wird es nicht "übermäßig" groß, man bleibt da bei max. 4 GB tar.gz, wenn ich da an meinem Arbeitsrechner denke, auf dem wirklich sehr viel installiert ist.

Grüße

Oli

[gbotti]

Hi Oli.

Du redest sicher von Virtualbox, oder?

Das macht Virtualbox, VMWare Workstation, Player und der kostenfreie Server auch...

Das is ein ziemlich interessantes Thema. Glücklicherweise is es aber trotzdem irgendwie einfacher als mit den M$-Systemen...

Gruß
Georg

[sumpi]

Ich hab das jetzt mal versucht udn folgendes gemacht:
Auf der ersten Maschine hab ich alle Verzeichnisse im root getart. Diese Archive hab ich dann auf eine VirtualBox-Installation geschoben (mit rsync) und dort den Bootloader in den MBR geschrieben. Das hat auch alles funktioniert und das System bootet in der VirtualBox. Aber wenn ich mich als Benutzer versuche einzuloggen, dann bekomm ich die Meldung: Kann /bin/bash nicht ausführen: Keine Berechtigung.
Als root geht alles einwandfrei. Auch wenn ich einen Benutzer mit adduser anlege passiert das gleiche. Der kann sich auch nicht einloggen. Auch ein su benutzername funktioniert nciht. Da bekomm ich dann: keine Shell.

Hat irgendwer eine Idee, was ich da jetzt noch drehen muss?
Bin für jeden Hinweis dankbar.

Bye,
Sumpi

[debianoli]

Aber wenn ich mich als Benutzer versuche einzuloggen, dann bekomm ich die Meldung: Kann /bin/bash nicht ausführen: Keine Berechtigung.
Als root geht alles einwandfrei. Auch wenn ich einen Benutzer mit adduser anlege passiert das gleiche. Der kann sich auch nicht einloggen. Auch ein su benutzername funktioniert nciht. Da bekomm ich dann: keine Shell.

Wie sehen denn die Nutzerrechte von /home/dein_user aus bzw gibt es das Verzeichnis überhaupt?

Code: Alles auswählen

ls -la /home

[sumpi]

ls -la | grep sumpi
drwxr-xr-x sumpi sumpi 4096 2010-08-10 09:42 sumpi