LVM vergrössern

Im Folgenden ein kurzes Howto, wie man einem bestehenden LVM eine weitere physikalische Festplatte hinzufuegt und anschliessend einer bestehenden Partition den neuen Speicherplatz zur Verfuegung stellt.
Ausgangsbasis ist ein bestehendes LVM mit dem Namen vg_ucs-shares und einer EXT3-Partition, welche unter /shares gemountet ist.

Nach dem Einbau der neuen Festplatte (/dev/sdb) muss diese zunaechst partitioniert werden:

root@ucs:/# fdisk /dev/sdb

Hier wird zunaechst eine neue Primaere Partition mit dem kompletten Speicherplatz und vom Typ LVM erstellt :

n -> p -> 1
t -> 8e
w

Anschliessend wird das System einmal neu gestartet um dem System die neu partitionierte Platte bekannt zu machen.

root@ucs:/# reboot

Nach dem Neustart wird nun aus der neuen Platte ein Physical Volume im LVM erstellt:

root@ucs:/# pvcreate /dev/sdb1

Danach wird die bestehende Volume Group um die neue Platte erweitert:

root@ucs:/# vgextend vg_ucs /dev/sbd1

Den Namen der Volume Group erhaelt man durch Eingabe des Befehls:

root@ucs:/# pvscan

Im naechsten Schritt wird das bestehende Volume um den neuen Plattenplatz erweitert. Im Beispiel wird ein bestehendes 300 GB-Volume um weitere 200 GB erweitert, d.h. die neue Zielgroesse ist 500 GB.

root@ucs:/# lvextend -L 500G /dev/vg_ucs/shares

Anschliessend wechselt man in den SingleUserMode

root@ucs:/# init 1

und unmountet die zu vergroessernde Partition

root@ucs:/# umount /shares

Bevor das Volume vergroessert werden kann, ist ein Dateisystem-Check erforderlich:

root@ucs:/# e2fsck -f /dev/vg_ucs/shares

Jetzt wird das EXT3-Dateisystem noch vergroessert:

root@ucs:/# resize2fs /dev/vg_ucs/shares

Anschliessend kann das System neu gestartet werden und das neue vergroesserte Volume steht unter /shares zur Verfuegung.

Hallo,

vielen Dank für die detaillierte Beschreibung. Dieses Thema ist sicher auch für viele weitere Anwender interessant.

Mit freundlichen Grüßen
Janis Meybohm

super Anleitung, vielen Dank!

root@ucs:/# pvcreate /dev/sdb1

Danach wird die bestehende Volume Group um die neue Platte erweitert:

root@ucs:/# vgextend vg_ucs /dev/sbd1

da ist ein kleiner Buchstabendreher drin :wink: Wenn man, wie ich, mit Copy And Paste arbeitet, führt das zu “leichten” Irritationen.

Ich finde immer ein bisschen Fortschrittsanzeige, insbesondere bei potenziell lang dauernden Aktionen wie den letzten zweien, interessant und würde deshalb folgendermaßen ergänzen:

root@ucs:/#  e2fsck -f -C 0 /dev/vg_ucs/shares

und

root@ucs:/#  resize2fs -p /dev/vg_ucs/shares

Gruß, Valentin

Hallo,

ich würde mir eine “offizielle” Anleitung zur Vergrößerung der Partition wünschen. Der normale Migrationsvorgang ist mittlerweile wohl jener, dass zunächst virtualisiert, getestet und anschließend die VM auf das Produktivsystem aufgespielt wird. Erst auf dem RAID des Servers würde ich die VM auf die volle Größe “aufblasen” (z.B. von 20 GB auf 120…)

Und der Sinn dahinter ist welcher? qcow-Images wachsen doch bei Bedarf und sollten somit bei größerer Maximalgröße nicht größer werden als bei einer kleineren sofern diese nicht überschritten wird.

Wenn ich UCS auf ESX betreibe, muss ich gezwungenermaßen mit einer VMDK Größe starten. Wenn ich erweiterten Platzbedarf habe, kann ich die VMDK problemlos verschieben und vergrößern. Unter Windows kostet mich das daraufhin drei Mausklicks, unter den typischen Linux-Distris drei Zeilen in der Shell.
Mit LVM habe ich (und nicht nur ich) keine Erfahrung, wenn dies also die Standardmethode ist, könnte die nachträgliche Vergrößerung doch ein offizielles HowTo werden, oder macht das keinen Sinn?

Es ging mir um den Sinn, das Image nicht mit einer ausreichenden Größe anzulegen. Den Sinn einer ausführlicheren Dokumentation von LVM hab nicht angezweifelt :slight_smile: Allerdings gibts da natürlich auch schon massig zu im Netz.

Ah, OK. :slight_smile:
Das Image der VM startet mit einer Größe, die das vorhandene System zur Erstellung nicht überlastet. Typischerweise wird das Image mit bis zu 40 GB vorbereitet, darf auf dem produktiven Host dann aber 120 GB und mehr haben.
Aber wir schweifen ab: die Dokumentation wäre auf jeden Fall sinnvoll.

Nur zur Ergänzung, hier die Anleitung nach der ich vorgegangen bin (mit leichten Abweichungen):
http://forum.univention.de/viewtopic.php?f=48&t=1879

Mastodon