KVM-storage LVM vs LVMimLVM

Hi,

die betrifft zunächst mal @cmer, wenn sie gerade am installieren ist, daher frag ich mal spontan @baumhof oder auch andere:

die Appliance zum Download für den Server enthält:

  • 1 Festplatte - serverroot
  • 1 Festplatte - LVM - mehrere LVs für serverdata

Zur Zeit habe ich dokumentiert dass es sinnig ist, die Festplatte jeweils auf ein LV des KVM-Host-LVMs zu bringen, dann sieht es so aus:

KVM-Host
+- LVM +--- lv-serverroot
       +--- lv-serverdata --LVM vg_srv + var
                                       + global
                                       + linbo
                                       + default-school

Jetzt frage ich mich, warum ich das interne LVM nicht aufgebe und gleich alle (5) LVs an die server-VM durchreiche:

KVM-Host
+- LVM vg_srv - lv-serverroot
              + var
              + global
              + linbo
              + default-school

Der Hintergrund ist, dass ich momentan mit den Snapshots nicht richtig zurecht komme. Ich will einen snapshot von lv-serverdata machen und dann entweder backupkopieren und löschen oder den snapshot mergen und das funktioniert aus seltsamen Gründen mit dem internen LVM nur sehr speziell. Also ich hab LVM noch nicht ganz durchschaut, deswegen frage ich mich, ob die zweite Variante nicht sowieso schlauer wäre.

Das Argument für nr. 2 wäre eigentlich: man kann direkter die Verzeichnisse mounten und mit rsync wegkopieren. Allerdings hab ich ja gehört, dass man als root sowieso nicht mehr an die Homes richtig drankommt, richtig?

Die Frage, ob nr. 2 überhaupt geht, müsste an die Entwickler gehen: ist der server davon abhängig, dass er ein LVM sieht? Denn das durchreichen der lv-var, lv-global, lv-linbo etc würde natürlich einzelne Festplatten in der Server-VM bedeuten.

VG, Tobias

Hallo @Tobias.
Bist du bei dieser Überlegung schon weiter gekommen?
Ich denke auch gerade darüber nach, ob ich überhaupt das LVM virtualisieren soll – oder die voreingestellten Partitionen nicht lieber gleich auf jeweils getrennte virt. HDDs auslagern sollte, die ich dann im Hypervisor vergrößern/snapshotten kann.
Wie hast du dich entschieden? Die Alternative wäre ansonsten: die voreingestellten Server-Partitionen auf dem Hypervisor vergrößern und dann das LVM anpassen (vor allem für LINBO).

Schöne Grüße,
Michael

Hallo Michael,

inzwischen glaube ich nicht, dass der server ein LVM haben muss, aber da sollte man die fragen, die von scratch installiert haben: Haben die ein LVM, das vg_srv heißt? Oder einfach nur Partitionen.
Die Partitionen sind m.E. wichtig, weil man spezielle mount-parameter hat, z.B. xattr und usrquota, usw.
Gr, Tobias

Hallo,

inzwischen glaube ich nicht, dass der server ein LVM haben muss, aber da
sollte man die fragen, die von scratch installiert haben: Haben die ein
LVM, das vg_srv heißt? Oder einfach nur Partitionen.
Die Partitionen sind m.E. wichtig, weil man spezielle mount-parameter
hat, z.B. xattr und usrquota, usw.

ich habe vanilla installiert.
Dazu verwendet man ein linuxmuster-paket (ich gleube
linuxmuster-appliance oder linuxmuster-prepair: steht ind er Anleitung …).
Und dieses Paket erstellt auf einer zweiten bereitgestellten
„Festplatte“ ein LVM. Die Größen kann man nur umständlich während des
installs anpassen (aber es geht).
Gedacht ist aber eher, dass man danach die LMVs die erschaffen werden
auf die eigenen Bedürfnisse vergrößert (da hatte ich keinen Bock drauf.
Hatte ich zwar schon auf meinem Laptop mal gemacht … ist aber Jahre her
…).

LVM in LVM geht ohne Probleme.

Ich habe mich für den Defaultweg der lmn entschieden: habe aber nun das
Problem beim Backup, weil ich LVM aufschließen muss und danach mehrere
Partitionen wegsichern muss … das war mal einfacher…

LG

Holger

Ja, das geht schon … ich frage aber wegen der Performance(verluste), wenn man das LVM (unnötigerweise?) nochmal virtualisiert. Hier hat das mal jemand direkt miteinander verglichen:

Wenn man das virtualisierte LVM umgehen will, müsste man also

/dev/mapper/vg_srv-global on /srv/samba/global type ext4 (rw,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
/dev/mapper/vg_srv-default--school on /srv/samba/schools/default-school type ext4 (rw,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
/dev/mapper/vg_srv-linbo on /srv/linbo type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg_srv-var on /var type ext4 (rw,relatime,data=ordered)

diese 4 Mountpoints einzeln behandeln, wovon 2 quotiert sind.

Wenn der Hypervisor diese Partitionen direkt verwaltet, kann man die Partitionen auch direkt vergrößern, ohne sich mit LVM-Befehlen herumschlagen zu müssen. Wir setzen ZFS im Hintergrund ein. Das kann selbst Snapshots anfertigen. Da wäre LVM gar nicht notwendig …

Da ich nun unmittelbar vor dem Schritt stehe, die ganzen Files von v6.x aus linbo, var und home zum v7-Server rüberzuholen, wäre es wahrscheinlich schlau, vorher zu wissen, welcher Weg der bessere ist. Die Werte, mit denen das LVM ausgeliefert wird, reichen bei uns jedenfalls in dieser Größe nicht **:

[root@server:]$ lvs
  LV             VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  default-school vg_srv -wi-ao---- <40,00g                                                    
  global         vg_srv -wi-ao----  10,00g                                                    
  linbo          vg_srv -wi-ao----  40,00g                                                    
  var            vg_srv -wi-ao----  10,00g  

Schöne Grüße,
Michael

Nun, da hänge ich mein Problem mal dran (evtl wäre es ein eigenes Thema):
Ich habe nun die VM’s in Proxmox importiert stehe vor dem Problem, die linbo-LV vergrößern zu müssen.
In Proxmox habe ich zwar schon die zweite (lvm-partitionierte) Festplatte des Servers vergrößert (geht ja wunderbar einfach). Aber wie bringe die diesen zusätzlichen Speicherplatz an die gewünschte Serverpartition (vg_srv/linbo)?
Für linuxfachmännische Kommandohilfe wäre ich seeeeeehr dankbar.

Nebelige Grüße aus dem bayerischen Teil des Donautals.
Roland

Hast du den Link in @Tobias’ bzw meinem Beitrag gesehen? Da steht es imho

Ich habe mittlerweile im Proxmox Forum gefragt. Die Meinung dort lautet ebenfalls: „(auf das) LVM verzichten, da es in diesem Setup keine Vorteile hat“. (wie gesagt: ZFS kann selbst Snapshots und der Hypervisor kann selbst die Partitionen verwalten/vergrößern. Daher dürfte das LVM unter KVM nicht wirklich notwendig sein – Performance mal außen vor gelassen).

Ich habe daher heute 4 weitere virt HDDs mit reichlich Platz zum lmn70 Server hinzugefügt und mit ext4 formatiert (davor noch gdisk --> /dev/sdx). Daraufhin alle o.g. Pfade mit rsync rüber kopiert und in die fstab eingebunden. Dann die alten LVM-Einträge in der fstab auskommentiert und Server neu gestartet. Lief fehlerfrei hoch! Wenn man das erst nach der Migration macht, dauert natürlich alles entsprechend länger, da dann die User-Daten und Linbo-Daten bereits enthalten sind…

Ich kann Montag genauer sagen, ob alles andere auch funktioniert – im Moment sieht es gut aus. Wenn alles gut geht, kann man ganz am Ende das LVM „deaktivieren“
vgchange -a n vg_srv
0 logical volume(s) in volume group "vg_srv" now active
Die virt. HDD, die das LVM enthält (hier zZ /dev/sdf) ist im Moment noch erhalten – aber ich denke, dass dieser Weg für die Proxmoxer performanter sein dürfte und ich diese virt. Platte langfristig löschen werde…

Da ich die User-Daten nun auf einer getrennten virt. HDD habe, kann man mit den ZFS-Tools jetzt natürlich blitzschnell einen Snapshot dieses zvols erstellen und zurückholen. Ich würde sagen: :+1:

(nachträgliche Ergänzung:
HowTo: virt. HDD und Dateisystem unter Proxmox vergrößern (auch KVM, ZFS) )

Schöne Grüße
Michael