In diesem Beitrag erkläre ich, wie man unter Verwendung von LVM das Basis-Betriebssystem des Servers, VMs und Container auf einen anderen Datenträger umzieht – in meinem Fall vom RAID-Array drehender Platten auf die SSD.

Weitere Beiträge aus dieser Reihe:

Planung

Bevor der Umzug stattfindet, müssen einige Details geklärt werden:

Datensicherheit

In meinem HP Microserver ist ein RAID-Controller und ich betreibe die Platten in RAID1, d.h. der Inhalt wird auf beiden Platten gespiegelt und fällt eine aus, läuft die andere weiter. Das ersetzt zwar kein Backup, schafft aber Ausfallsicherheit. Diese Sicherheit verliert man, zieht man die Systeme auf eine einzelne SSD um. Das nehme ich hin, da ich mein ganzes Setup in Puppet habe und nur die Daten auf den drehenden Platten speichere. Was an Verlaufsdaten anfängt, etwa die Datenbanken zum Betrieb verschiedener Software, wird mit Backups gesichert. Dafür erhalte ich eben die Geschwindigkeit der SSD.

Live oder offline

Der Umzug des Basis-Betriebssystems ist, verwendet man LVM, nicht besonders schwierig: es wird einfach ein Abbild der Partition auf den anderen Datenträger gespielt. Dabei ist es aber sinnvoll, wenn das Betriebssystem nicht läuft und das Dateisystem nicht eingehängt ist. Die einfachste Möglichkeit ist also, den Server mit einem USB-Stick zu booten und so die ganze Arbeit offline zu erledigen. Möchte man nicht den laufenden Betrieb anhalten, kann man dazu vorher einfach einen LVM-Snapshot der Root-Partition machen und einfach diesen spiegeln. Das soll weiter Inhalt dieses Beitrags sein.

Durchführung

Im ersten Schritt wird das Basis-Betriebssystem auf die SSD umgezogen, dann wird das auch direkt von dort gestartet. An der Konfiguration der VMs und Container ändert sich nichts, dadurch bleiben sie auch zunächst auf den drehenden Platten. Im nächsten Schritt werden dann nach und nach VMs und Container umgezogen. Später können die dazugehörigen Images auf den drehenden Platten gelöscht werden.

SSD vorbereiten

Dieser Beitrag geht davon aus, dass die SSD angeschlossen und weder partitioniert noch formatiert. Die weiteren Schritte zerstören alle auf dem Datenträger bereits vorhandenen Daten! Zunächst ist eine neue Volume Group auf der SSD anzulegen:

$ df -h  /  # Herausfinden, wie groß die Root-Partition ist
$ sudo cfdisk /dev/sdX
$ sudo partprobe
$ sudo pvcreate /dev/sdX3
$ sudo vgcreate ssd /dev/sdX3
$ sudo lvcreate -L 50G -n root ssd

Gleich zu Beginn wird die Partitionierung gestartet. Für meinen Microserver habe ich das Layout so gewählt, dass sdX1 vom Typ BIOS Boot 1 MiB groß ist, sdX2 vom Typ EFI System 256 MiB groß ist, wie es Proxmox bei der Installation auch auf den drehenden Platten angelegt hat. Der restliche verfügbare Platz wird dann sdX3 mit Typ Linux LVM zugewiesen.

Danach wird sdx3 als Physical Volume bereitgestellt und im Anschluss eine Volume Group namens ssd angelegt, mit dem Datenträger als Mitglied. Schlussendlich wird ein neues Logical Volume erstellt, also quasi eine Partition, mit 50 GiB Größe, in der Volume Group ssd mit Name root, d.h. sie wird unter /dev/mapper/ssd-root erreichbar sein. Die Größe der Partition muss natürlich passend zur Root-Partition des laufenden Betriebssystems gewählt werden.

Proxmox umziehen

Nachdem das System weiterhin läuft, kann nicht einfach ein Abbild davon gezogen werden. Im laufenden Betrieb ist das nie eine gute Idee. Besser ist, einen Snapshot des Root-Datenträgers erstellen zu lassen und diesen zu spiegeln:

Zuerst muss man herausfinden, wo / gemountet ist, also wo das Betriebssystem liegt:

$ mount|grep ' /'
/dev/mapper/pve-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

Hier ist zu sehen, dass / in der Volume Group pve gespeichert ist, auf dem logischen Volume root. Davon wird jetzt ein Snapshot gezogen:

$ sudo lvcreate -L 200M -s -n schnappi /dev//mapper/pve-root
  Using default stripesize 64,00 KiB.
  Logical volume "schnappi" created.

Die Inhalte von /dev/mapper/pve-root zum Zeitpunkt des Snapshots sind jetzt also unter /dev/mapper/pve-schnappi eingefroren, während sich die Inhalte des Systems weiter ändern können. Das klappt aber nur, solange diese Inhalte sich nicht um mehr als 200 MiB von denen im Snapshot unterscheiden. Das sollte auf dem Hypervisor aber reichen.

Jetzt kann der Inhalt gespiegelt werden:

$ sudo dd bs=4096 if=/dev/sdY1 of=/dev/sdX1  # /dev/sdY ist hierbei der alte Datenträger
$ sudo dd bs=4096 if=/dev/sdY2 of=/dev/sdY2
$ sudo dd bs=4096 if=/dev/mapper/pve-schnappi of=/dev/mapper/ssd-root
$ sudo lvremove /dev/mapper/pve-schnappi  # den Snapshot wieder löschen

Proxmox-Konfiguration anpassen

Die Dateien sind jetzt alle transferiert, die Konfiguration von GRUB und des Betriebssystems muss allerdings noch angepasst werden, damit nicht weiter von den drehenden Platten gestartet wird.

Dazu wird zuerst /etc/fstab angepasst, um in Zukunft / und die EFI-Partition von der SSD zu laden:

$ sudo blkid /dev/sdX2  # die PARTUUID der EFI-Partition kopieren!
$ sudo sed -i -e 's|/dev/pve/root|/dev/ssd/root|' /etc/fstab
$ sudo sed -i -e '/efi/d' /etc/fstab
$ echo "$(blkid /dev/sdX2|grep -o -E 'PARTUUID=.*?') /boot/efi vfat defaults 0 1"| sudo tee -a /etc/fstab

Jetzt ist noch notwendig, GRUB richtig zu konfigurieren. Am einfachsten geht das, wenn man sich innerhalb des auf der SSD hinterlegten Betriebssystems befindet:

$ sudo mount /dev/ssd/root /mnt
$ sudo mount -t proc none /mnt/proc
$ sudo mount -t sysfs none /mnt/sys
$ sudo mount -o bind /dev /mnt/dev
$ sudo mount -o bind /run/lvm /mnt/run/lvm
$ sudo mount -o bind /run/lock/lvm /mnt/run/lock/lvm
$ sudo chroot /mnt /bin/bash
$ update-grub
$ grub-install /dev/sdX

Nun ist der Bootloader auch umkonfiguriert, mit den neuen Einstellungen aus der /etc/fstab und neuem Installationsort im MBR der SSD.

Das umgezogene Betriebssystem booten

Der Server kann jetzt neu gestartet werden. Dabei ist die Bootreihenfolge im UEFI so anzupassen, dass von der SSD gestartet wird und nicht mehr vom RAID-Array. Das System sollte dabei hoch kommen, als wäre nie was gewesen.

VMs und Container umziehen

Das Umziehen der VMs und Container wird relativ einfach. Vorher muss nur noch unterschieden werden, ob man das LVM thin provisioned haben will oder nicht.

Thin-Pool provisionieren

In meinem Setup möchte ich das, also sind folgende Schritte noch notwendig:

$ sudo lvcreate -L 100G -n data ssd
$ sudo lvconvert --type thin-pool ssd/data
$ sudo pvesm add lvmthin ssd --vgname ssd

Dabei werden 100 GiB (bitte Zahl entsprechend anpassen) aus der ssd Volume Group reserviert und im nächsten Schritt für die Verwendung als thin pool konvertiert. Der Platz ist dann für reguläre LVM-Operationen wie Snapshots usw weg! Deswegen sollte man in der Volume Group noch ein 2-3 GiB frei lassen, damit man ggf. mit Platz rangieren, voll gelaufene Systemplatten retten oder Snapshots erstellen kann. Der letzte Schritt macht den Speicher dann noch Proxmox bekannt.

Umzug der Container und VMs

Bevor man eine laufende VM oder einen laufenden Container umziehen kann, muss dieser heruntergefahren werden. Danach kann auf der Kommandozeile einfach gesagt werden, man möchte ein Volume auf einen anderen Speicher umziehen. Dabei wird auch direkt der neue Speicher eingebunden; der alte wird deaktiviert aber auf der Platte gelassen, falls was schief geht.

Container umziehen

$ sudo pct list  # um die VMID der Container zu ermitteln
# Ab hier für jeden Container wiederholen
$ sudo pct shutdown 100
$ sudo pct move_volume 100 rootfs ssd
$ sudo pct start 100

Danach sollte der Container wieder starten, diesmal von der SSD. rootfs bezeichnet hier die Systemplatte des Containers. Hat man weitere Mount Points zum Container hinzugefügt, bekommen die für gewöhnlich den Titel mp0 mit aufsteigender Zahl. Möchte man diese auch auf die SSD migrieren, ist das getrennt notwendig.

VMs umziehen

Virtuelle Maschinen umziehen dauert etwas länger aber klappt analog:

$ sudo qm list  # um die VMID der VMs zu ermitteln
$ sudo qm shutdown 101
$ sudo qm config 101  # um die an der VM angeschlossenen Datenträger zu ermitteln
$ sudo qm move_disk 101 scsi0 ssd
$ sudo qm start 101

Je nachdem, welche Anschlussart beim Erstellen der VM gewählt wurde, kann statt scsi0 etwa auch virtio0 o.Ä. notwendig sein. Welchen Typ die Systemplatte hat, steht in der Zeile bootdisk, alle weiteren Platten sind weiter unten aufgeführt.

Nach den Befehlen von oben sollten die VMs wieder laufen.