VM with LVM (Thick) to LVM-Thin

[jsterr]

Hello Proxmox-Forum

maybe someone has already tested this out:

a customer has made the following setup:

* LVM (THICK) Pool 16 TB
* Windows VM (VM100) with 3-4 disks
** Disk 1: 2TB
** Disk 2: 500 GB
** Disk 3: 4TB

Is there a way to convert a lvm thick to lvm-thin pool? Is there any way to convert the disks, so they will get thin? What about backuping the VM100 with its thick-disks and restoring it to a lvm-thin pool on a different node, would this work? Or would vm-disks still be thick?

Or is the only way to do a fresh win-server install and recover on application-level?

Thanks for the help
Greetings Jonas

 

[damo2929]

you create your new thin lvm based pool them migrate your disks over to it. at which point the system will convert it to thin provision.

 

[jsterr]

you create your new thin lvm based pool them migrate your disks over to it. at which point the system will convert it to thin provision.

The pool is already in use, so I cant create another one while having the current one still active. Or is there a way to actually do this on cli without loosing the thick pool? Creating lvmthin via webui doesnt give me any options.

 

[aaron]

Technically a thin LVM consists of 2 LVs in a thick LVM, which are then used to store the metadata and data. The LVM tooling will usually hide that fact nicely, but you can see it with lsblk for example.

You could probably create a new thin LVM inside the thick LVM manually, add a matching storage CFG and Move Disk the guests disks over. There is no magic to convert it on the fly AFAIU.

The code to create the thin LVM can be found in the storage repo: https://git.proxmox.com/?p=pve-stor...d3b4176879d57b459f54d7f7ed6ec94f;hb=HEAD#l132

You see that it calls the regular LVM code to create the base thick LVM and then the actuall command to create the thin pool.

 

[jsterr]

Technically a thin LVM consists of 2 LVs in a thick LVM, which are then used to store the metadata and data. The LVM tooling will usually hide that fact nicely, but you can see it with lsblk for example.

You could probably create a new thin LVM inside the thick LVM manually, add a matching storage CFG and Move Disk the guests disks over. There is no magic to convert it on the fly AFAIU.

The code to create the thin LVM can be found in the storage repo: https://git.proxmox.com/?p=pve-stor...d3b4176879d57b459f54d7f7ed6ec94f;hb=HEAD#l132

You see that it calls the regular LVM code to create the base thick LVM and then the actuall command to create the thin pool.

Thanks Aaron! Make sense now! So move-disk to lvm-thin would make them thin-provisioned?

 

[VictorSTS]

Is there any way to convert the disks, so they will get thin? What about backuping the VM100 with its thick-disks and restoring it to a lvm-thin pool on a different node, would this work? Or would vm-disks still be thick?

This depends on how the disks had been used while in the thick pool and if the VM has discard ticked for the drives. Without discard, If the guest OS has written data to the drives and then deleted it, the bytes will still be there filling "empty" space and a backup/restore will move those bytes to the destination thin-pool, making the drives "thicker", so to say.

If discard was ticked, in theory those lingering bytes from deleted data should have been discarded, at least at the guest OS level... but I'm not 100% sure if a thick LVM supports any kind of discard at the storage level, so deleted data might still be in the storage and a QEMU backup might still read them and include in the backup/restore.

In any case, after restoring in a LVM thin pool you can issue an fstrim -v (Linux) or an Optimize-Volume -DriveLetter LETTER -ReTrim -Verbose (Windows >= 8/2012, powershell) to retrim the drives from the guest OS and finally recovering the space in you storage.

 

[LnxBil]

keep also in mind that AFAIK the extents for thin LVM are 2 MB in size so that a defraged disk which has also been reordered on disk will yield the smallest possible trimming. You can archieve this on ext4 for example by resizing the disk to the smallest possible size, then resize it again to full size and trim afterwards. Just checked that this week (on ceph) for some automatic optimization.