Benutzer-Werkzeuge

Webseiten-Werkzeuge


de.bkp:technische-dokumentationen:tutorials:migration-xenvm-nach-pve-kvmvm

Tutorial - Migration einer Xen-VM auf Proxmox

Version Status Datum Author URL
0.1 Erster Entwurf 22.05.2020 Egil Rüefli
0.2 Ergänzungen TT.MM.JJJJ Vorname Nachname
1.0 Review und Freigabe TT.MM.JJJJ Vorname Nachname

1. Kurzfassung

Eine konzeptionelle Zusammenfassung der Arbeit und des erarbeiteten Ergebnisses erleichtert dem mit dem Projekt befassten Leser des Berichts (Fachvorgesetzte, Experten) den Einstieg für das Verständnis der geleisteten Arbeit. Die Kurzfassung enthält nur Text und keine Grafik.

  1. Die Kurzfassung richtet sich an die fachlich kompetenten Leser.
  2. Die Kurzfassung enthält die Punkte: Kurze Ausgangssituation - Umsetzung - Ergebnis.
  3. Die Kurzfassung enthält zu jedem dieser gennanten Punkte die wesentlichen Aspekte.
  4. Die Kurzfassung ins nicht länger als 1 A4-Seite Text (ein allfällig von der PK verlangtes Websummary is erstellt und hochgeladen)

2. Tutorial

2.1 Erzeugen der Raw-Image-Datei auf dem Xen-System

Die Befehle in diesem Tutorial müssen alle als User root ausgeführt werden. Auf dem XEN-System findet man mit xm list die ID der zu migrierenden VM heraus. In diesem Tutorial soll wekan.syscon.ch migriert werden,

Danach stoppt man die VM mit xm shutdown 69 (69 ist die ID der VM, die migriert werden soll). Sollte die VM nicht heruntergefahren werden dürfen, muss zunächst ein Snapshot des Images angelegt werden. Mit dem Befehl lvscan findet man das LV-Image der VM:

Das LV-Image wird mit dem Befehl dd [(https://www.cyberciti.biz/faq/unix-linux-dd-create-make-disk-image-commands/)] in eine Image-Datei kopiert:

dd if=/dev/vg0/wekan.syscon.ch-root of=/xenbkp/wekan.syscon.ch-root.img

Möchte man über den Fortschritt des Kopiervorgangs informiert werden, ist der Befehl noch durch den Pipe-Viewer pv [(https://www.thomas-krenn.com/de/wiki/Linux_Pipe_Viewer_(pv))] zu ergänzen:

dd if=/dev/vg0/wekan.syscon.ch-root | pv | dd of=/xenbkp/wekan.syscon.ch-root.img

2.2 Transfer der Raw-Image-Datei auf das Proxmox-System

Das kopierte Raw-Image wird für den Transfer auf das Zielsystem komprimiert. Das Raw-Image enthält neben den Nutzdaten auch noch bereits gelöschte Dateien. Um eine effiziente Kompression zu erreichen, muss der Datenmüll auf dem Image vor dem Komprimieren mit Nullen überschrieben werden. Wie das geht erfahren Sie im Tutorial Verkleinern eines DD-Disk-Images.

Danach kann die preparierte Image-Datei mit folgendem Befehl kopiert, komprimiert und auf das Zielsystem transferiert werden:

dd if=/xenbkp/wekan.syscon.ch-root.img | gzip -1 - | ssh user@server.rafisa.net dd of=wekan.syscon.ch-root.img.gz

2.3 Erzeugen einer Partitionstabelle

Voraussetzung für diesen Schritt ist, dass das Image erfolgreich vom Xen-System auf das Remote-System kopiert worden ist. Die Arbeiten werden von nun an auf dem Proxmox-System durchgeführt.

Als erstes wird das Image mit gunzip wekan.syscon.ch-root.img.gz dekomprimiert. Danach wird mit dem Befehl dd if=/dev/zero of=./wekan.syscon.ch-root-final.img count=1 bs=1MiB ein kleines Raw-Image erstellt und mit pv wekan.syscon.ch-root.img » wekan.syscon.ch-root-final.img das Boot-Image und das Original-Image gemergt. Das Original-Xen-Image verfügt über keine Partitionstabelle, diese muss zunächst angelegt werden:

fdisk wekan.syscon.ch-root-final.img 
#Danach gibt man im interaktiven Dialog folgende Parameter ein:
n #neue Partition
p #primäre Partition
1 #Partitionsnummer
#Die Sektorgrössen lassen wir bei den Standardwerten, die ext-Signatur wird nicht gelöscht.
a #Partition bootbar machen
w #Änderungen übernehmen 

2.4 Erzeugen einer virtuellen Maschine und Import des vorbereiteten Disk-Images

Zunächst wird unter Proxmox eine neue VM erstellt. Auf dem Reiter OS wählt man Do not use any media:

Auf dem Reiter Hard Disk darauf achten, das richtige Storage-Medium einzubinden:

Mit folgendem Befehl wird das vorbereitete Image wekan.syscon.ch-root-final.img in die frisch erzeugte VM importiert:

qm importdisk 105 ./wekan.syscon.ch-root-final.img local-lvm

105 ist die VM-ID. Während des Import-Vorgangs wird wird das Raw-Format-Image zunächst in das QCOW-Format konvertiert, damit wird dynamisches LVM möglich. Nach dem erfolgreichen Import ist im Hardware-Reiter der entsprechenden VM eine zweite Disk mit importierten Image vorhanden. Die erste Disk mit Detach aus dem System entfernt und danach gelöscht. Die Disk mit dem Image wird dem System hinzugefügt. Dazu wird die Harddisk zunächst markiert und dann über den Knopf Edit editiert. Mit Add lässt sie sich dem System hinzufügen.

2.5 Installation des Boot-Loaders und Anpassungen an die neue Umgebung

Zunächst muss die LVM-Harddisk der VM gemountet werden, um einige Anpassungen vornehmen zu können. Da die Disk über zwei Partitionen verfügt, kann sie nicht direkt mit dem mount-Befehl eingehägt werden, sondern die Partitionen müssen zunächst mit dem Tool kpartx zugänglich gemacht werden:

kpartx -a /dev/vg0/vm-105-disk-1

Jetzt kann die entsprechende Partition eingehängt werden:

mount /dev/mapper/vg0-vm--105--disk--1p1 /mnt/

Auf dem XEN-Quellsystem war kein Bootloader vonnöten, da XEN mit dem Loader pygrub die VMs startet. Um die VM unter KVM starten zu können, muss zunächst ein Bootloader installiert werden:

grub-install --target=i386-pc --recheck --debug --boot-directory=/mnt/boot /dev/mapper/vg0-vm--105--disk--1

Auf dem Ziel-System müssen folgende Dateien angepasst werden:

  • /mnt/etc/network/interfaces (IP-Adresse)
  • /mnt/etc/fstab (währende Boot einzuhängende Partitionen)
  • /mnt/etc/inittab (hvc0 durch tty1 ersetzen, nicht immer notwendig)

In der Datei /mnt/etc/network/interfaces muss die IP-Adresse angepasst werden, unter /mnt/etc/resolv.conf der DNS-Server. Danach wird die Datei /mnt/etc/fstab, das Konfig-File für das automatische Einhängen von Partitionen während des Systemstarts überarbeitet. Alle Partitionen, die mit xv (XEN-spezifische Bezeichnung für Partitionen) beginnen, müssen auf s geändert werden, also /dev/xvda1 → /dev/sda1:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0      $
#/dev/sda2      none            swap    sw              0       0
/dev/sda1       /               ext3    errors=remount-ro  0    1

Die Swap-Partition wird auskommentiert, da im nächsten Schritt ein Swap-File angelegt wird. Damit sparen wir uns das Anlegen einer weiteren Disk für die Swap-Partition1). In der Datei /mnt/etc/inittab muss der Eintrag 1:2345:respawn:/sbin/getty 38400 hvc0 durch 1:2345:respawn:/sbin/getty 38400 tty1 ersetzt werden, falls vorhanden.

Für die letzten beiden Schritte, die Installation von grub sowie das Anlegen der Auslagerungsdatei muss mit dem Befehlt chroot ins Root-Verzeichnis der VM gewechselt werden. Dazu müssen folgende Verzeichnisse eingehängt werden:

mount -t proc proc /mnt/proc   
mount -t sysfs sys /mnt/sys   
mount -o bind /dev /mnt/dev  

Danach wird mit chroot /mnt das Root-Verzeichnis gewechselt. Nach Eingabe des Befehls bildet /mnt das neue /.

Mit apt-get install grub2-common wird das Grub-Paket installiert. Danach wird mit grub-mkconfig -o boot/grub/grub.cfg das Konfigurationefile für Grub erstellt. Ein 2GB Swap-File wird mit dd if=/dev/zero of=/swap bs=1024 count=2097152 erzeugt. Danach wird ein Swap-Filesystem mit mkswap /swap generiert. In /etc/fstab wird der Eintrag für das Swap-File angepasst:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0      $
#/dev/sda2      none            swap    sw              0       0
/swap   none            swap    sw              0       0
/dev/sda1       /               ext3    errors=remount-ro  0    1

3. Testing

Beschreibung des Testkonzepts: Was sind die Voraussetzungen des Testings? Was soll wie getestet werden, welche Tests werden gemacht?

3.1 Test 1 (Beispiel)

Testfall Nr. #1
Beschreibung Die Namensauflösung im Netzwerk funktioniert
Vorgehen mit nslookup die Namen von internen und externen Hosts auflösen:
nslookup srv-zh-01.dotcom.intern
nslookup pc-zh-01.dotcom.intern
Voraussetzung / Umfeld Auf dem AD-Server srv-zh-01 ist der DNS-Dienst aktiviert
Erwartetes Resultat Die Namen werden richtig aufgelöst
OK / nicht OK OK
Aufgetretene Fehler / Bemerkungen Keine

3.2 Test 2

Testfall Nr. #2
Beschreibung
Vorgehen
Voraussetzung / Umfeld
Erwartetes Resultat
OK / nicht OK
Aufgetretene Fehler / Bemerkungen

3.3 Test 3

Testfall Nr. #3
Beschreibung
Vorgehen
Voraussetzung / Umfeld
Erwartetes Resultat
OK / nicht OK
Aufgetretene Fehler / Bemerkungen

4. Auswertung

Was hat funktioniert, was nicht, was waren die grössten Herausforderungen/Probleme, wie habe ich die Probleme gelöst, was mache ich beim nächsten Mal besser, Reflexion

5. Quellenverzeichnis

de.bkp/technische-dokumentationen/tutorials/migration-xenvm-nach-pve-kvmvm.txt · Zuletzt geändert: 2020/09/14 16:26 von 127.0.0.1