VM - Failed to start VM {name}, nach OS-Disk Vergrößerung

  • Ich habe das Szenario (Root-Volume von 10 auf 20 GB vergrößern) jetzt bei meiner neu angelegten myVM2 abermals versucht.

    Problem tritt erneut auf, scheint also nachvollziehbar zu sein.

    Betroffene VM: 019fdbad-95bc-76d6-9d23-089c9fcff4c8

  • Problem tritt erneut auf, scheint also nachvollziehbar zu sein.

    Das Problem ist reproduzierbar und sollte in einen Systemtest Testfall gegossen werden für die storage action "increase size"!

    Schritte zum Reproduzieren:

    1. VM anlegen (z.B. debian) vServer Mini mit Standard Minimalgröße 10 GB root volume
    2. VM stoppen
    3. root volume vergrößern (z.B. auf 12 GB)
    4. VM wieder starten

    Ich habe einen extra Eintrag im Subforum Feedback & Bugs angelegt, weil ich nicht sicher bin, ob man den Thread hier verschieben könnte.
    [eos] Failed to start VM {name} Notification Fehlermeldung ersetzt name nicht beim Start einer defekten VM Unschönheit - Feedback & Bugs

    WH1000 SE OST22 OST23 OST24 | WH1000 SE ADV25 | WH 🥚🧶🥛🐖 | 🦆 VPS 200 🇺🇦🕊️ ➡️ VPS nano G11s

  • Das Vergrößern von root Volumes scheint nun möglich zu sein und funktioniert auch.

    Allerdings tut euer Mechanismus da meines Erachtens ungefragt "zu viel des guten". Ihr vergrößert auch gleich die sda2 Partition und erweitert das Filesystem. Das ist zwar sicherlich sehr komfortabel für jemanden, der das genau so gewollt hat. Aber wenn ich die Disk eigentlich vergrößern wollte um im Freespace eine neue Partition anzulegen habe ich nun ein Problem, denn es gibt keinen Freespace.

    Vor der Vergrößerung des Volumes:

    Code
    root@myVM1:~# fdisk --list /dev/sda
    Disk /dev/sda: 55.88 GiB, 60000000000 bytes, 117187500 sectors
    ...
    Device      Start       End   Sectors  Size Type
    /dev/sda1    2048    206847    204800  100M EFI System
    /dev/sda2  206848 117187466 116980619 55.8G Linux filesystem

    Nach der Vergrößerung des Volumes über die EOS-Console:

    Code
    root@myVM1:~# fdisk --list /dev/sda
    Disk /dev/sda: 74.51 GiB, 80000000000 bytes, 156250000 sectors
    ...
    Device      Start       End   Sectors  Size Type
    /dev/sda1    2048    206847    204800  100M EFI System
    /dev/sda2  206848 156249966 156043119 74.4G Linux filesystem

    Ich denke, dass dieser Komfort optional sein sollte bzw. beim Vergrößern parametrierbar / abwählbar sein sollte.

  • Hallo!

    Vielen Dank für das Feedback und die ausführliche Darstellung des Anwendungsfalls.

    Bei root_volumes ist die aktuelle Implementierung bewusst so vorgesehen, dass bei einer Vergrößerung des Volumes auch die vorhandene Partition und das Dateisystem entsprechend erweitert werden. Dieses Verhalten ist insbesondere für die üblichen Anwendungsfälle gewünscht und orientiert sich an den Anforderungen der Mehrheit unserer Kunden.

    Für Szenarien, in denen die zusätzliche Kapazität beispielsweise für eine oder mehrere separate Partitionen oder für LVM verwendet werden soll, sind weitere Volumes die vorgesehene Möglichkeit, dies entsprechend flexibel abzubilden. LVM sowie individuelle Partitionierungen und deren anschließende Vergrößerung lassen sich damit umsetzen, ohne dass das Verhalten von root_volumes dafür angepasst werden muss.

    Falls bei einem root_volume die automatische Erweiterung der Partition und des Dateisystems nicht gewünscht ist, kann das automatische Wachstum auch gezielt deaktiviert werden. Dazu kann vor der Vergrößerung des Volumes der incus-growpart.service deaktiviert werden. Dadurch bleibt der zusätzlich bereitgestellte Speicher zunächst unpartitioniert und kann anschließend entsprechend der individuellen Anforderungen, beispielsweise für LVM oder zusätzliche Partitionen, verwendet werden.

    Uns ist bewusst, dass es darüber hinaus weitere Anwendungsfälle gibt. Die aktuelle Implementierung deckt bewusst die häufigsten Szenarien ab. Für darüber hinausgehende Anforderungen besteht die Möglichkeit, diese über die entsprechenden Volume-Konfigurationen bzw. eine andere Aufteilung der Volumes umzusetzen.

    Vielen Dank nochmals für das Feedback!

    Viele Grüße,
    Thorsten

  • Danke [netcup eos] Thorsten L. für die ausführlicher Erläuterung.

    Dass das beim StartUp automatisch vergrößert wird kommt wie gesagt für mich unerwartet. Vielleicht möchte man das zumindest im Web-GUI Dialogfeld erwähnen und einen Link zu einer Erläuterung in der Doku setzen.

    Was die Information das incus-growpart.service zu deaktivieren betrifft: Das existiert auf meiner Ubuntu 26.04 Cloud VM nicht.

    Code
    root@myVM1:~# systemctl list-units | egrep -i "incus|grow" 
      run-incus_agent.mount          loaded active     mounted   /run/incus_agent
      incus-agent.service            loaded active     running   Incus - agent

    Das wird denke ich nicht mit incus sondern mit cloud-init hiermit erledigt: Module "growpart" und "resizefs" in der /etc/cloud/cloud.cfg

    Code
    # The modules that run in the 'init' stage
    cloud_init_modules:
      - seed_random
      - bootcmd
      - write_files
      - growpart
      - resizefs
      - disk_setup
      - mounts
    ...
  • gunnarh Vielen Dank für die Infos!

    Die Dokumentation erwähnt nun, dass eine Vergrößerung der root Parition automatisch von statten geht.

    Mit einen normalen Debian 13 Image (kein cloud-init) haben wir folgendes gemacht um dein gewünschtes Verhalten zu erzielen:

    root_volume in der UI vergrößert und wie folgt eine neu partition angelegt


    Je nach Image kann es natürlich sein, dass man sowohl incus-growpart.service deaktivieren und auch die von dir erwähnte cloud-init.cfg anpassen muss.

    Hast du das Ubuntu image mit oder ohne cloud init verwendet ?


    Danke für die Rückmeldung,
    Thorsten

  • Danke [netcup eos] Thorsten L.... habe mir euren Hinweis in https://docs.eoscloud.io/products/volum…rage-user-guide jetzt durchgelesen. Zitat:

    Zitat

    The default behavior when growing a root Volume is to automatically extend the size of the root disk. If you want to disable this behavior, ensure that incus-growpart.service is disabled and also check that a potential cloud-init.cfg does now grow the root disk.

    Das beschreibt das aktuelle Verhalten, dass die Partitionen automatisch vergrößert und auch die Filesysteme automatisch vergrößert werden meinem Verständnis nach nicht deutlich genug. Da steht, wenn man das Volume vergrößert, vergrößert sich die Root-Disk (wollte man vielleicht Root-Partition schreiben und hat sich geirrt?).

    Ich denke da sollte geschrieben stehen (Vorschlag):

    When growing a root volume, the default behavior is that the root disk expands and the primary partition and filesystem are automatically extended. This happens on next startup and is performed either by incus-growpart.service and/or by the growpart and resizefs modules of cloud-init Service, configured in /etc/cloud/cloud.cfg, depending on the operating system of the VM.

    To prevent the root partition and filesystem from growing automatically, check for and disable these mechanisms before growing the volume.

    If you need additional separate partitions and filesystems for specific mount points, consider attaching a separate new volume that can be grown independently.