Sie sind hier : Homepage →  > hier stehen die veralteten Seiten→  Linux (6) Ein Webtropia root-Server→  Eine VM "füllen"/umziehen

Wenn Sie eine XEN VM übertragen (klonen) möchten ........

..... gibt es diverse Methoden, den Virt-Manager auf dem Quell-Host oder auf dem Ziel-Host "zu bemühen". Dabei sind jedoch Randbedingunngen zu erfüllen. Bis das wieder läuft, haben Sie graue Haare oder gar keine mehr. - Wichtig sei, die XEN Versionen sollten gleich sein oder nahe beieinander liegen. Ausgiebig getestet hatte ich das noch nicht.

Bisher hat das Klonen von VMs von einm Remote-XEN Server zu einem anderen Remote-XEN-Server mit Hilfe des Virt-Manager nicht geklappt. Ein anderer Weg muß beschritten werden.
.

Vergleich von virt-manager "cloning" oder ftp Filetransfer

Mit dem Virt-manager soll das Klonen einer VM auch auf einen fremden XEN-Server funktonieren, bei mir hatte es nicht funktioniert. Beim Klonen auf dem gleichen Host fällt auf, eine 40GB VM braucht von Quell-Partition zur Klone-Partition locker 15 Minuten. Eine 100GB Partition braucht natürlich linear mehr. Über ein Netzwerk, sebst im gemeinsamen Server-Housing, wid deutlich langsamer kopiert. Es dauert weit über 1 Stunde. Die gesamte Partition der VM wird - voll oder leer - komplett rüber transferiert.
.
Unsere Dummi-Musterinstallation ist gepackt nur 700 MB groß und da sollte es erheblich schneller gehen.
.
Die Anpassungen an den neuen Host und die IP Nummern müssen wir sowieso noch nachtragen.
.

Die Platten unserer VMs sind anders konfiguriert

Bei uns sind in jeder VM 3 Partitionen im Gebrauch, die "swap", die "root" und die "data" Partition getrennt.

Wird die betroffene Quell-VM abgeschaltet, kann sich der host (oder auch das Server- Rescue-System) diese beiden Partitionen mounten und jeweils exakte "tar.gz" Abbilder (root und data getrennt) erstellen und direkt auf der Host- Partition (darum ist die bei uns 30GB groß) oder auf einer der "shared"- Partitionen (bei uns 55GB) abspeichern.

Das geht bei 30GB immer noch in wenigen Minuten rasend schnell und dann kann die Quell-VM nach dem entmounten dieser beiden Partitionen wieder für den Normalbetrieb gestartet werden - bis zur Übergabe an den neuen Server.

Auf jeden Fall dürfen Sie auf dem Host (um keinen Preis) ein "umount all" absetzen. Dann ist der Host komplett "kampfunfähig" und Sie können nicht mal mehr ein "reboot" absetzen. Es geht gar nichts mehr. Sie brauchen dann für diesen Host einen Hardware-Reset per ZKM-Webinterface.
.

Eine abgeschaltete VM vom Host aus sichern

Beispiel für das kurzzeitige Sichern/Kopieren/Bearbeiten von VM-Partitionen:

unser-Beispielserver:/ # mkdir /mnt/md6p2
unser-Beispielserver:/ # mkdir /mnt/md6p3

unser-Beispielserver:/ # mount /dev/md6p2 /mnt/md6p2
unser-Beispielserver:/ # mount /dev/md6p3 /mnt/md6p3

nach vollendetem Kopier- oder Service- Vorgang explizit diese beiden wieder entmounten :

unser-Beispielserver:/ # umount/mnt/md6p2
unser-Beispielserver:/ # umount/mnt/md6p3
.

Der "tar" Befehl für die beiden Partitionen

Wie gesagt, muß die Quell-VM runter gefahren sein. Dann kann man als "root"-user mit dem "tar" Befehl beide Partitionen (root und data) sichern und im /tmp/ Verzeichnis des Hosts ablegen.

Beispiel:

tar cvfz /tmp/IPW-DNS-MAIL-etc-2020-05-03.tar.gz /dev/md6p2/etc/*

oder die gesamte Partition:

tar cvfz /tmp/IPW-DNS-MAIL-alles-2020-05-03.tar.gz /dev/md6p2/*
.

Ganz wichtige Vorarbeiten auf dem Ziel-Host

Eine auf den Ziel-Host rüber kopierte Sicherung könnte und würde in der neuen VM zuerst mal gar nicht laufen. Die UUIDs und die Netzwerk-Konfigurationen stimmen nicht mehr. Das Betriebssystem würde damit auch nicht starten.
.
Dem Host ist es egal, welches Betriebsystem in einer VM gestartet wird, solange, wie der Link bei der VM aus dem Masterbootrecord - dem MBR - kommt. Die wichtigen Host-Dateien zum Starten von VMs sind die XML Datein in

[unser-Beispielserver] /etc/libvirt/libxl/

hier nur als Beispiel :  /etc/libvirt/libxl $ dir

-rw------- 1 root root 1423  9. Mai 04:31 generic-VM.xml
-rw------- 1 root root 1553  8. Mai 21:46 md6-40GB-opensuse-15.1-VM1-DNS.xml
-rw------- 1 root root 1553  9. Mai 22:08 md9-40GB-opensuse-42.3-Installation.xml
-rw------- 1 root root 1416  9. Mai 00:44 opensuse42.3-2.xml
-rw------- 1 root root 1427  9. Mai 01:09 opensuse42.3-3.xml
-rw------- 1 root root 1412  9. Mai 00:16 opensuse42.3-4xml
.
Bislang habe ich noch nicht rausgefunden, wie man eine VM einrichten könnte, ohne ein 1,2GB großes Betriebssystem zu installieren. Daß dabei die ausgewählte RAID1 Platte (bislang im RAW Format) partitioniert und formatiert wird, ist unabdingbar. Dabei werden auch die UUIDs und eine virtuelle MAC-Adresse für die virtuelle Netzwerkkarte erstellt.

Ist die Installation einer VM fertig und die VM wieder abgeschaltet, kann man auf dem Host die angelegte "xml-Datei" betrachten und dort Texte und Namen und sogar den Dateinamen editieren (und danach libvirt neu starten !). Am eigentlichen Boot-System sollte man nichts ändern, sondern das dem Virt-Manager überlassen.
.

Die Konfiguration der neu erstellten VM sichern

Auf der für die neue Ziel-VM ausgesuchten Partition (bei uns als Beispiel "md6") wird mit dem Virt-Manager eine minimalistische opensuse Variante (aus dem myloc Reposistory) installiert, deren erstellte Variablen wir sichern müssen. Und das sind die Boot-Parameter und die Netzwerk-Parameter, die in der XML Datei angesprochen werden und die das Betriebssystem zum Starten braucht.

Ich "klone" dazu zusätzlich diese Vorab-Mini-Installation mit dem Virt-Manager auf irgendeine Reserve-Partition auf diesem Host, von denen wir genügend haben. Es würde aber auch das Sichern der Verzeichnisse /etc/ und /boot/ ausreichen.
.
In einer funktionierenden VM sind das :
.

  • Der Bootloader enthält und braucht in "/boot/grub2/grub.cfg" die UUIDs der "swap" und der "root" Partition in seinem bootloader-Script.
  • In der "/etc/fstab" stehen auch mindestens diese ersten beiden UUIDs (für swap and root) drinnen, bei uns eigentlich immer für alle drei angesprochenen Partitionen.

.

Hier die Beispiele :

Die Sicherungs-Dateien auf den Host (nicht die VM) kopieren

Inzwischen sollte man insbesondere auf den Hosts, den kritischen DOM0s, möglichst wenige allseits bekannte Ports offen halten. Die Chinesen baggern Tag und Nacht in unseren Netzen herum.
.

Eine fertige VM umziehen und benutzen ist nicht trivial

Wenn ich daher zwei VMs vergleiche, was ist gleich und was ist unterschiedlich ?
.

Ein grafischer ftp Client ist hilfreich

Die Installation von "filezilla" auf dem Ziel-host war nicht berauschend. Die aktuelle Version ist sehr gewöhnungsbedürftig. Da ist "gftp" aus 2008 deutlich überlegen. "gftp" ist deutlich einfacher und übersichtlicher als "filezilla". Was an dem FIlzilla so gelobt wird, ist mir inzwischen schleierhaft. Ich habe ganz andere Sorgen, als auch noch einen ftp Client zu erlernen und zu verstehen.

Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum