Inhaltsverzeichnis
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.
- Die Kurzfassung richtet sich an die fachlich kompetenten Leser.
- Die Kurzfassung enthält die Punkte: Kurze Ausgangssituation - Umsetzung - Ergebnis.
- Die Kurzfassung enthält zu jedem dieser gennanten Punkte die wesentlichen Aspekte.
- 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