EOS VMs mit Möglichkeit LVM Logical Volume Manager zu nutzen

    Ich betreibe meine Maschinen immer mit LVM (Logical Volume Manager), weil dies das Hinzufügen von Storage sehr vereinfacht.

    Ad-hoc sehe ich in EOS keine Möglicheit LVM zu nutzen. Zumindest das Ubuntu-Image ist ohne LVM vorbereitet, und in Ermangelung einer KVM-Konsole und in Ermangelung irgend ein ISO-Image zum Booten einzulegen sehe ich keine Möglichkeit die VM auf LVM zu migrieren.

    Ideal wäre freilich wenn die Wünsche KVM-Konsole und Einlegen von ISO-Images für das Booten unterstützt wären, dann könnte sich jeder sein System so installieren wie es beliebt, und auch LVM wäre dann möglich. So handhabe ich es bei den Netcup-VMs derzeit.

    Solange diese Features nicht zur Verfügung stehen wäre es aber eventuell ein Quick-Win ein Ubuntu 26.04 Minimal-Image das auf LVM basiert als Image zur Installation anzubieten.

    LVM should be the standard. The issue is that additional storage comes as a separate disk that cannot be attached to the `/` partition.

    I actually opened a ticket once asking them to adjust this.

    I purchased extra storage, but they simply attach a new disk; I can't expand the main disk using this additional one because the system isn't set up with LVM.

    Every time I need to upgrade storage by adding a disk, I have to boot into rescue mode to convert it.

    Having an image that already includes LVM would definitely be a huge help.

    Hallo zusammen,

    vielen Dank zunächst für eure Rückmeldungen.

    Da mir die Notwendigkeit aktuell noch nicht ganz klar ist, könntet ihr mir bitte ein bis zwei konkrete Beispiele nennen, in denen LVM innerhalb der VM-Images einen Vorteil bietet bzw. erforderlich ist?

    Das würde mir helfen, die Anforderung und den konkreten Anwendungsfall besser zu verstehen.

    Viele Grüße,
    Thorsten

    Danke [netcup eos] Thorsten L. für die Rückfrage.

    Ich installiere alle Systeme immer grundsätzlich unter Verwendung von LVM (Logical Volume Manager) mit Logical Volumes (LV), und zwar aus folgenden Gründen:

    • Bei der Installation muss ich mir (noch) keine Gedanken über das Kapazitätsmanagement machen. Ich lege einfach alle benötigten LVs (z.b. root, var, var-log, home, ...) mit einer Best-Guess Initial-Größe (eher klein / sparsam) an, und kann diesen LVs später wenn sich diese füllen unkompliziert und im laufenden Betrieb ohne etwas herunterfahren oder aushängen zu müssen zusätzlichen Speicher zuweisen.
    • Ich bin ein Freund davon Userdaten, Logs, System voneinander zu trennen, damit z.b. ein User der das System anfüllt nicht das System oder die Logfile-Haltung in Gefahr bringt. Das fällt mit LVs bei denen ich dann z.b. die User-Volumes dynamisch jederzeit vergrößern kann deutlich einfacher.
    • Das Hinzufügen von weiterem Speicherplatz durch Ergänzen eines weiteren Storage-Device welches einfach als Physical Volumes zum LVM ergänzt werden ist ebenfalls ohne vorherige Kapazitätsplanung möglich. Ebenfalls ist ein Shrinking möglich.

    Nun könntest du (vermutlich) meinen Argumenten entgegenhalten:

    • Lege doch einfach zusätzliche Volumes über die EOS-Cloud an und füge diese der VM hinzu statt LVs zu verwenden => Das kann ich aktuell aber erst NACH der Installation durchführen und ist doch ziemlich aufwändig wenn ich /var oder /home dann auf anderen Volumes haben möchte. Jede Änderung bedeutet VM herunterfahren, EOS Storage Volume vergrößern, VM wieder hochfahren, Filesystem Resizen etc... - jeweils mit Downtime und "Gefahr" verbunden. Bei Nutzung von LVM wäre ein ein Befehlsaufruf im laufenden Betrieb und die Sache ist erledigt, keinerlei Gefahr, keine Downtime.
    • Die EOS-Cloud erlaubt das Vergrößern von Storage Volumes ... ja, aber zumindest derzeit nur bis 100GB, und nur offline. Wenn ich z.B. 2TB Speicher haben möchte was mache ich dann? Mit LVM wäre mir das egal, ich lege einfach mehrere neue Storage Volumes an, füge diese der VM hinzu und binde diese ins LVM ein. Wie ich diese dann auf meine LVs verteile bleibt ganz mir überlassen und bedarf keiner Unterstützung durch die EOS-cloud mehr.

    Mal ketzerisch gefragt, wenn du heute keine Kapazitätsplanung machst, wann ungefähr fängst du mit ihr an?

    Dein Beitrag gibt mir leider den Eindruck, als das es Sinnvoller wäre, deine Strategie zu Überdenken, als ein einfaches System zuverkomplizieren, um an einem anderen Ende Zeit/Flexibilität zu gewinnen die es nie gab.

    Fakt ist das man in der IT Grundsätzlich nie ein Perfektes Ausgangsszenario haben wird. Man kann zu klein, aber auch zu groß planen. Die Erfahrung zeigt aber das zu klein, immer die schlechteste Ausgangslage ist. Zudem muss man auch die ganze Komplexität hinterfragen, die mit LVM plötzlich in die Konstruktion Einzug gewinnt.

    Ich gestalte meine Systeme mittlerweile so das 8GB (2G,boot,vfat;6G,root,btrfs+xxhash) das OS stellen und alles was Applikation ist, weit weg auf eigenen Disks/Partitionen residiert. Damit habe ich klare Abgrenzung zwischen einem relativ Statischen Datenberg und einem dynamischen der mit seinen Herausforderungen wächst.

    Vorteil? Mein OS kann einfach als template mit cloud-init repliziert werden. Meine Anwendungen sind klar distanziert dazu und haben Ressourcen die sie wirklich benötigen und können jederzeit um den gestiegenen Bedarf erweitert werden.

    Da ich für die Applikation oder einen Pool dessen, nur eine Partition mit btrfs + xxhash checksum habe. Lässt sich diese jederzeit online vergrößern ohne Kopfschmerzen und downtime. Das macht auch sämtliche deklarationen in allen Tools einfacher, vom Deployment bis zum Backup.

    Das ganze kommt natürlich mit dem Knackpunkt das man seine Anwendungen, dann richtig konfigurieren muss, damit diese im korrekten Verzeichniss arbeitet. Was entsprechend zum lesen der Dokumentation anregt und zum Schluss zu einem besseren Verständnis führt.

    Eine Platte zuverkleinern, sollte einfach nie in Betracht gezogen werden.

    Skulduggery eine Kapazitätsplanung kann immer nur den aktuellen Kenntnisstand berücksichtigen. Niemand kann hellsehen und zukünftiges Anwender-Nutzungs-Verhalten lässt sich nicht zwingend aus der Historie ableiten. Daher strebt man - wenn es denn sinnvoll machbar ist - nach höchstmöglicher Flexibilität, also jederzeit Kapazitäten ergänzen zu können, und diese ohne riskante Aktionen und Wartungsfenster (downtime) auch nutzen zu können.

    Und die Cloud-Plattform bietet hierfür grundsätzlich beste Voraussetzungen.

    Du kannst ein Filesystem nur vergrößern wenn das Volume oder Logical Volume auf dem es residiert freien Spreicher aufweist. LVM schafft diese Möglichkeit jederzeit Speicher hinzuzufügen, ganz ohne Downtime, Shutdown, reboot.

    Gerne nehme ich zur Kenntnis, dass Du der Meinung bist LVM wäre "komplex". Meinem Empfinden nach ist das Gegenteil der Fall, es vereinfacht meine UseCases enorm.

    Hallo zusammen!

    Vielen Dank für eure ausführlichen Rückmeldungen und die konkreten Beispiele zu euren Anwendungsfällen.

    Wir nehmen die unterschiedlichen Perspektiven und Anforderungen gerne mit und werden die verschiedenen Optionen intern evaluieren. Gerade die unterschiedlichen Ansätze zeigen uns, dass es hier durchaus verschiedene Use Cases und Anforderungen gibt.

    Vielen Dank daher für den konstruktiven Austausch und eure Zeit, uns diese Rückmeldungen zu geben!

    Für eine Individuelle Linux Installation genügt es schon, wenn man eine Live-CD wie z.b. archlinux oder eben ein optimiertes Rescue image booten kann, das mit provisionierten ssh-key daher kommt.

    Ab da steht es, dann jeden frei, wie er sich sein kram partitioniert und installiert. Was ich insgesamt neben fertig Images als ausreichend empfinden würde.

    KVM sehe ich maximal für eine Windows installation, aber mit Linux ist das überflüssig.

    Es muss nicht zwingend eine KVM-Konsole sein, serielle Konsole nehme ich für Linux auch. Oder wenn es möglich ist ein bei mir lokal erstelltes qcow File selbst hochzuladen. Aber der universellste Weg ist nun mal das Einlegen eines ISO-Image zu ermöglichen und eine KVM Konsole anzubieten, dann sind auch "Bare-Metal-Restore-Lösungen" wie Boot von Veeam-Recover-ISO-Image problemlos möglich und alle Szenarien stehen offen.