Momentan beschäftige ich mich parallel mit dem Thema OpenTofu mit Proxmox inklusive cloud-init. Ein Punkt der mir besonders wichtig war bei der initialen Konfiguration von VMs während des Deployments war das Vergrößern des (LVM) root Volumes bei Bedarf. Und das ist ein bekanntes Problem und scheinbar löst es jeder anders – oder gar nicht.
Wenn man nach „cloud-init“ „growpart“ und „lvm“ sucht, findet man sehr schnell sehr viele Einträge mit diesem Problem. Die allgemeine Aussage zu dem Thema ist, dass das growpart-Modul von cloud-init mit LVM nicht funktioniert und nur für reguläre Partitionen gedacht ist. Einige andere haben das aber scheinbar doch irgendwie hinbekommen. Ich jedenfalls nicht.
Ich konnte es drehen und wenden wie ich will, growpart hat immer einen Fehler ausgeworfen.
Apr 12 09:59:09 debian cloud-init[300]: 2026-04-12 07:59:09,937 - performance.py[DEBUG]: Running ['growpart', '/dev/sda', '5'] took 0.130 seconds
Apr 12 09:59:09 debian cloud-init[300]: 2026-04-12 07:59:09,937 - log_util.py[WARNING]: Failed: growpart /dev/sda 5
Apr 12 09:59:09 debian cloud-init[300]: 2026-04-12 07:59:09,937 - log_util.py[WARNING]: Failed: growpart /dev/sda 5
Apr 12 09:59:09 debian cloud-init[300]: 2026-04-12 07:59:09,937 - log_util.py[DEBUG]: Failed: growpart /dev/sda 5
Apr 12 09:59:09 debian cloud-init[300]: Traceback (most recent call last):
Apr 12 09:59:09 debian cloud-init[300]: File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 113, in resize
Apr 12 09:59:09 debian cloud-init[300]: subp.subp(["growpart", diskdev, partnum], update_env=my_env)
Apr 12 09:59:09 debian cloud-init[300]: ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Apr 12 09:59:09 debian cloud-init[300]: File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 291, in subp
Apr 12 09:59:09 debian cloud-init[300]: raise ProcessExecutionError(
Apr 12 09:59:09 debian cloud-init[300]: stdout=out, stderr=err, exit_code=rc, cmd=args
Apr 12 09:59:09 debian cloud-init[300]: )
Apr 12 09:59:09 debian cloud-init[300]: cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Apr 12 09:59:09 debian cloud-init[300]: Command: ['growpart', '/dev/sda', '5']
Apr 12 09:59:09 debian cloud-init[300]: Exit code: 2
Apr 12 09:59:09 debian cloud-init[300]: Reason: -
Apr 12 09:59:09 debian cloud-init[300]: Stdout: FAILED: failed to resizeZurück zu bewährten Mitteln
Mittels Ansible vergrößere ich logical volumes bereits seit langer Zeit. Und dafür benutze ich u.a. parted. Schlussendlich war das dann auch hier die Lösung. Da ich meine Templates mit Packer baue, habe ich dort einfach in die preseed.cfg für die Debian Installation das Paket parted mit rein genommen.
# Extra packages to be installed
d-i pkgsel/include string sudo openssh-server partedDamit konnte ich in cloud-init im init-Bereich mittels bootcmd einfach die entsprechenden Befehle absetzen:
bootcmd:
- echo -e "resizepart\n2\n100%\n"| parted /dev/sda ---pretend-input-tty
- echo -e "resizepart\n5\n100%\n"| parted /dev/sda ---pretend-input-tty
- pvresize /dev/sda5
- lvresize --extents +100%FREE --resizefs /dev/mapper/debian--vg-rootWichtig ist natürlich zu wissen, wie die logical volumes nach einem Deplyoment aussehen.
Diese Konfiguration ist bei mir immer identisch.
Vorteil bei dieser Variante mit den entsprechenden Befehlen in bootcmd: Egal ob die Platte beim Deployment größer angegeben wurde oder nicht, die Befehle können ohne Probleme abgesetzt werden. Wenn nichts zum vergrößern da ist, wird auch nichts vergrößert.
Kommentare
18 Kommentare zu „cloud-init und LVM resizing“
@fedi
Was erwartet du dir von LVM in virtuellen Maschinen?
@Cinux @fedi Ich verstehe die Frage nicht 😄
@mauri @fedi
Welchen Mehrwert erwartet du dir von LVM innerhalb einer Virtuellen Maschine. Also welchen konkreten Nutzen hat es?
Vielleicht ist die Frage besser 😊
@Cinux @fedi Ne, kann dir nicht folgen 🙈 LVM ist halt der Standard und wesentlich flexibler.
@mauri @fedi
Nun nur weil etwas standard ist muss das nicht bedeuten das es immer Sinn macht es auch einzusetzen.
Ich war auch mal der Meinung LVM brauch man in einer VM. Heute wüsstw ich nicht wofür ich das dort bräuchte. Du sagst für mehr Flexibilität. Welche Flexibilität fehlt dir den wenn du LVM nicht einsetzten würdest?
Ich bin einfach nur neugierig. 😅
@Cinux @fedi Natürlich brauch man es nicht. Man braucht so vieles letztlich nicht. Die Diskussion ist so alt wie nur irgendwas. Wenn ich mit Packer und der Preseed die Debian Installation mache, ist es halt LVM. Ist für mich vollkommen in Ordnung. Drehen wir mal den Spieß um wenn du schon so konkret und indirekt gegen LVM fragst: Was hast du gegen LVM?
@mauri @fedi
Du missverstehst mich. Ich habe nichts gegen LVM. Es gibt Anwendungsfälle da macht es sinn. Gerade bei nicht virtuellen Maschinen oder eben beim PVE für die snapshot funktion.
Ich habe praktisch genau so wie du angefangen. Packer + Preseed und zack hat man ein Template.
Dann hieß es, lass mal cloud-init versuchen. Also Cloud-init Image von Debian gezogen und via Ansible auf PVE deployed. Das "lästige" Template bauen ist weggefallen. Als Image habe ich die generic variante …
@mauri @fedi
verwendet wo kein LVM drauf ist.
Zu der Zeit war ich noch der meinung ich brauche entweder LVM oder mehrere Partitionen für /var /var/log /tmp etc. Was man halt so als Standard hat.
Das führte zu massiven Problemen bzw. Mehraufwand und dann gabs einfach die Frage: Brauch man das den aktuell wirklich noch?
Am ende vom Lied war das Resultat so, dass man das in einer VM (also einem Wegwerfprodukt) gar nicht braucht. Im zweifel baut man eine neue.
Und selbst wenn man es braucht…
@mauri @fedi
Baut man es im Nachgang via Ansible ein.
So das mal kurz zum Abriss wie es bei mir gelaufen ist.
Seitdem sehe ich, ohne Usecase, keinen Sinn darin LVM in einer Virtuellen Maschine zu verwenden. Das heißt nicht das es kein Sinn macht.
Mich hat es also nur interessiert was für ein Anwendungsfall du hast das du unbedingt LVM brauchst und damit diesen Mehraufwand, von dem du ja selbst sagt den man nicht brauch, in Kauf nimmst.
@Cinux @fedi Deine Frage zielte schon auf diese Antwort ab. Hättest du auch direkt schreiben können 😉 Was waren das denn für massive Probleme? Mir sind keine Probleme (außer im aktuellen Artikel) bisher bekannt. Und ich nutze LVM schon verdammt lange.
@mauri @fedi
Die Massiven Probleme bzw. Mehraufwände bezog sich auf die Allgemeine Idee /var /var/log etc. in extra Partitionen/Volumes (o.ä.) zu packen.
Aufwand der keinen Nutzen generierte.
LVM selbst hätte sicherlich nie Probleme gemacht. Aber halt eher die Werkzeuge drum herum wie in deinem Beispiel. 😀
@Cinux @fedi Und was spricht gegen Packer mit dem net-install iso? Ein saubereres Template kann man glaube ich nicht bauen.
@mauri @fedi
An sich nichts. Denn du hast Recht, ABER 😀
Ziel war es nächtlich das Template neu zu bauen. Nach dem Motto "Fail fast, Fail often". Das bedeutet das wieder zusätzliche Logik ins CI/CD fließen muss um sicherzustellen das immer ein Produktives Template vorhanden ist. Logik die ich gerne vermeiden wollte. Alternativ hätte man Logik ins Deployment bringen müssen um immer das richtige Tempalte zu greifen. Auch das wollte ich nicht.
Daher die Idee mit Cloud-init. Zu der Zeit war ich,
@mauri @fedi
Ebenfalls noch überzeugt das man doch für /var /var/log etc. müssen eine eigene Platte verwenden. So sah entsprechend das Preseed aus. Im Cloud-init wäre das wieder neue Logik gewesen. Ein Kollege fragte dann ob man das wirklich bräuchte. Nach längerem überlegen war klar, man brauch es _erstmal_ nicht.
Also Cloud-init so belassen wie es ist und zack man hat ein sauberes Deployment ohne Abhänigkeiten. Spezialfälle könnte man immer noch mit Packer machen. Aber war ertmal nicht ziel
@mauri @fedi
So passierte es das auch ich mich von der Idee verabschiedete für alles eine extra Partition/Platte/Volume haben zu müssen.
Es ermöglichte gleichzeitig alles weitere in Ansible zu konfigurieren und somit die Logik auf ein Tool und ein "Platz" zu beschränken.
Das macht das ganze übersichtlicher und leichter wartbar.
Ich hätte natürlich Stunden reinversenken können um LVM in Cloud-init zum laufen zu brauchen, aber die Frage war ganz klar:
Was bringt es uns?
Und die Antwort war: Nix
@mauri @fedi
Das ist jetzt etwas stark gekürzt wegen der Zeichenbegrenzung. Aber das spricht für ein generisches Deployment einer Debian VM gegen ein Template, wenn man es nächtlich immer wieder neu bauen will.
Wenn du noch konkretere Fragen hast frag ruhig 🙂
@Cinux @fedi Spannend. Also getrennte Volumes für /var etc. mache ich seit Jahrzehnten nicht mehr 😅 Zuletzt wenn überhaupt noch bei FreeBSD. Und die Möglichkeit ein sauberes Template in kürzester Zeit autoatisiert mit Packer zu bauen finde ich nach wie vor sehr praktisch. Betrachte ich btw als eigenständigen Prozess. Und ob man cloud-init verwenden will, ist einem freigestellt – bzw. was per cloud-init bereits beim Deployment umgesetzt werden soll und was im Nachgang per Ansible & Co.
@mauri @fedi
Ich war da etwas vor geschädigt durch sen letzten Arbeitgeber und der sudosh. Daher war damals noch der drang dazu da. 😅
Ziel war es möglichst alles in ansible zu machen. Da bot auch dann cloud init an. Und das vergrößern der disks ist da halt nach einem reboot gleich mit dabei. Was mega praktisch war und Arbeit ab nimmt. 😊