Konzept mit dem LVM-Pool verstehen

[pixel24]

Hallo zusammen,

ich versuche noch immer das Konzept mit dem LVM in Proxmox zu verstehen. Ich nutze LVM schon länger auf diversen Servern und dachte immer ich habe es verstanden. "Früher" habe ich meine PV's devieniert, Eine VG-Group erstellt und darain die LV's für die VM's.

Jedes LV war von der Größe eindeutig definiert und hat auch genau diesen Platz sofort beansprucht. Genau da würde ich wieder gerne mit Proxmox hin. Falls das geht. Hier scheint es ja so zu sein dass ich die virtuellen Platten mit einer max. Größe definiere und diese lediglich den Platz allokieren der tatsächlich "verbraucht" ist. Im Umkehrschluss bedeutet dies dass die Summer aller Max-Größen der LV's den tatsächlich verfügbaren Platz übersteigen kann.

Habe ich das richtig verstanden?

Ich möchte es an einem Beispiel verdeutlichen. Der kleiner Heimserver hat ein Hardware-RAID5 mit 3 x 1TB Platten was im OS (PVE 7.1) zu einer Rohkapazität von 2TB führt und im PVE als /dev/sda "ankommt". Nach der Installation zeigt sich folgende Partitions-Layout:

root@vmhost01:~# fdisk -l /dev/sda
Disk /dev/sda: 1.82 TiB, 1999978364928 bytes, 3906207744 sectors
Disk model: 9650SE-8LP DISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7CBCAF64-A34B-4247-831B-44B0067528FB

Device       Start        End    Sectors  Size Type
/dev/sda1       34       2047       2014 1007K BIOS boot
/dev/sda2     2048    1050623    1048576  512M EFI System
/dev/sda3  1050624 3906207710 3905157087  1.8T Linux LVM

Währen der Installation wurde die vggroup "pve" angelegt:

root@vmhost01:~# vgdisplay
  --- Volume group ---
  VG Name               pve
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  75
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               4
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <1.82 TiB
  PE Size               4.00 MiB
  Total PE              476703
  Alloc PE / Size       462751 / <1.77 TiB
  Free  PE / Size       13952 / 54.50 GiB
  VG UUID               0ZP9ak-0iQQ-yFDC-34PU-fX3s-J81r-I532TE

Soweit ist für mich alles verständlich. Der Befehl lvdispaly zeigt mir alle LV's welche ja die virtuellen Platten der VM's bzw. dessen Snapshots darstellen. Zusätzlich exisitiert noch das LV "data". Und hier hört mein Verständnis auf. Für was ist das?

 --- Logical volume ---
  LV Name                data
  VG Name                pve
  LV UUID                rcZQtx-PthC-FVFT-lwq3-6QID-mhrr-o9Ai8V
  LV Write Access        read/write (activated read only)
  LV Creation host, time proxmox, 2022-02-22 14:40:13 +0100
  LV Pool metadata       data_tmeta
  LV Pool data           data_tdata
  LV Status              available
  # open                 0
  LV Size                <1.68 TiB
  Allocated pool data    1.33%
  Allocated metadata     0.21%
  Current LE             439807
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:5

Auf dem PVE laufen lediglich zwei VM's mit nicht allzu großen virtuellen Disk:



Trotzdem wird mir im Web-UI unter LVM eine Auslastung von 97% angezeigt:



Unter LVM-Thin sehe ich "data" mit einer Auslastung von 1%:



Daraus würde ich jetzt schließen dass das LV "data" in der Volumegroup PVE liegt und darin die virtuellen Disks der VM's. Nur mit den angezeigten Größen komme ich nicht klar. Auf der Konsole wird mir die VG "pve" mit "<1.77 TiB" angezeigt, im Web-UI mit 2TB.

Gleiches mit dem LV "data". Auf der Konsole "<1.68TiB", im Web-UI 1.84TB.

Kann mir jemand dieses Konzept erklären?

Wenn ich nun einen Snapshot einer VM erstelle erhalte ich einen Meldung dass der Pool nicht gegen das "überbelegen" durch die LV's geschützt ist (frei aus dem Kopf). In den virtuellen Disk finde ich aber keine Option die besagt dass diese mitwachsen sollen und es so ggf. zu einer Überbelegung kommen kann. Wo kann ich das "abstellen" damit die Disks einfach den Platz belegen wie ich sie anlege?

Ein weiteres "Problem" was damit zu tun haben dürfte ist. Wenn ich versuche das komplette System (wie gesagt 2TB Volume) mittels Clonezilla im Device-to-Device Modus auf eine 3TB Disk zu klonen erhalte ich die Meldung die Zieldisk wäre zu klein. So habe ich dass mit den Virt-Servern (vor PVE) immer gemacht.

Hoffe jemand kann hier Licht ins Dunkel bringen

Beste Grüße
pixel24

 

[fabian]

PVE verwendet mittlerweile LVM thin. klassisches LVM wird auch unterstuetzt, hat aber einige features nicht (eben kein thin provisioning, aber auch keine snapshots). die leicht unterschiedlichen groessen sind vermutlich durch TB vs TiB erklaert (1000 vs 1024 als faktor zur naechsten einheit).

 

[MarkusF]

Hallo,

Soweit ist für mich alles verständlich. Der Befehl lvdispaly zeigt mir alle LV's welche ja die virtuellen Platten der VM's bzw. dessen Snapshots darstellen. Zusätzlich exisitiert noch das LV "data". Und hier hört mein Verständnis auf. Für was ist das?

data beinhaltet den lvm-thin pool.
Ein lvm thin pool wird zusaetzlich in eine volume group geschrieben.

Wenn ich nun einen Snapshot einer VM erstelle erhalte ich einen Meldung dass der Pool nicht gegen das "überbelegen" durch die LV's geschützt ist (frei aus dem Kopf). In den virtuellen Disk finde ich aber keine Option die besagt dass diese mitwachsen sollen und es so ggf. zu einer Überbelegung kommen kann. Wo kann ich das "abstellen" damit die Disks einfach den Platz belegen wie ich sie anlege?

Mit einfachen lvm statt lvm-thin

https://pve.proxmox.com/wiki/Logical_Volume_Manager_(LVM)
https://pve.proxmox.com/wiki/Storage:_LVM_Thin

bei den Größen sollte alles passen (1TiB=1024*1024*1024*1024 Byte, TB=1 000 000 000 000 Byte):
1.68TiB = 1.68*1024*1024*1024*1024 = 1847179534663.68 Byte = 1.84TB

 

[pixel24]

Mit einfachen lvm statt lvm-thin

lvm-thin wurde ja bei der Installation automatisch gewählt bzw. ich habe eine entsprechende Option übersehen. Das würde bedeuten dass wenn ich LVM anstatt LVM-Thin einrichte ich die Snapshot-Funktion verliere?

Und weiter dass ich wenn ich LVM-Thin verwende diese Meldung einfach so lassen muss?

Das wäre so auch ok da ich die Auslastung des Pools ohnehin im Auge behalte.

Was für mich eher ungünstig ist dass ich dieses System nicht 1:1 mit Clonezilla auf einen Datenträger der größer ist klonen kann. Gibt es hierzu einen Trick?

 

[fabian]

lvm-thin wurde ja bei der Installation automatisch gewählt bzw. ich habe eine entsprechende Option übersehen. Das würde bedeuten dass wenn ich LVM anstatt LVM-Thin einrichte ich die Snapshot-Funktion verliere?

ja

Und weiter dass ich wenn ich LVM-Thin verwende diese Meldung einfach so lassen muss?

ja

Das wäre so auch ok da ich die Auslastung des Pools ohnehin im Auge behalte.

das ist generell sinnvoll wenn speicherplatz overprovisioned wird

Was für mich eher ungünstig ist dass ich dieses System nicht 1:1 mit Clonezilla auf einen Datenträger der größer ist klonen kann. Gibt es hierzu einen Trick?

ich bin mir nicht ganz sicher was du mit clonezilla kopierst. wenn du alle logischen volumes einzeln sicherst dann sind die ja (potenziell) in summe groesser als die eigentliche disk auf der sie liegen. wenn du die physische disk deines PVE systems sicherst, kann der fehler nur woanders liegen (hier wuerde das LVM thin ja gar nicht beachtet werden..)

 

[pixel24]

ich bin mir nicht ganz sicher was du mit clonezilla kopierst. wenn du alle logischen volumes einzeln sicherst dann sind die ja (potenziell) in summe groesser als die eigentliche disk auf der sie liegen. wenn du die physische disk deines PVE systems sicherst, kann der fehler nur woanders liegen (hier wuerde das LVM thin ja gar nicht beachtet werden..)

ich denke hier liegt das Problem da das LV "data" + alle LV's der VM-Disks in Summe ja größer sind als die 2TB die vom RAID-Controller kommen und die Kapazität der 3TB Zieldisk überschreiten. Deshalb funktioniert der Clonezilla-Modus: Device-to-Device in dieser Konstellation nicht.

Was ich suche ist eine Möglichkeit den PVE einfach 1:1 auf einen Datenträger zu klonen und im Bedarfsfall zurück zu spielen.

 

[MarkusF]

Schon versucht mit dd zu kopieren?

 

[fabian]

ich denke hier liegt das Problem da das LV "data" + alle LV's der VM-Disks in Summe ja größer sind als die 2TB die vom RAID-Controller kommen und die Kapazität der 3TB Zieldisk überschreiten. Deshalb funktioniert der Clonezilla-Modus: Device-to-Device in dieser Konstellation nicht.

Was ich suche ist eine Möglichkeit den PVE einfach 1:1 auf einen Datenträger zu klonen und im Bedarfsfall zurück zu spielen.

das 'data' LV musst du ja nicht sichern, wenn du die einzelnen darin enthaltenen LVs ohnehin sicherst sonst kopierst du alles 2x, dann geht es sich natuerlich nicht aus.

 

[pixel24]

Schon versucht mit dd zu kopieren?

Nein, noch nicht. Wenn ich mich richtig erinnere muss ich danach den Bootloader manuell wiederherstellen. Das war immer das schöne an Clonezilla

 

[MarkusF]

Ja so wie @fabian es schon geschrieben hat, würdest du gerade ein paar Virtuelle Maschinen doppelt kopieren, wenn du wirklich alles im lvm kopierst.

Entweder du laesst das data LV aus oder kopierst die gesamte Platte (/dev/sda) mit zum Beispiel dd.

 

[pixel24]

Ok, vielen Dank. Jetzt kenne ich zumindest mal das ursächliche Problem. Ich werde es mal mit dd versuchen und den Restore auf einem anderen Rechner versuchen. Danke für die Hilfe