Converting existing LVM volume to LVM-thin

A

Airw0lf

Active Member
Apr 11, 2021
83
5
28
it-visibility.net
Is there a way to convert an existing LVM volume (mounted as dir) to a LVM-thin pool without loosing the data? Where can I findnd more on this?

I can stop all VM's and LXC's - just would like to save some time on copying its disk files.

I have found this::
https://pve.proxmox.com/wiki/Storage:_LVM_Thin
But it doesn't say anything about loosing data (or not).
 
Last edited:
So, your existing disk is part of a Physical Volume (PV), which hosts a Volume Group (VG), which in turn contains a Logical Volume (LV)? Do you have any free space available in any of these? (You can check with pvdisplay and vgdisplay.)
  • If there is free space, you can create a separate LV thin pool and migrate data using qemu-img.
  • If there is no free space, you could try shrinking the filesystem, LV, and VG. However, this is not always possible and, if done incorrectly, can lead to data loss.
The safest approach is to back up your data first, then restructure your disk as needed. Alternatively, you could add a new disk, either permanently or temporarily.

Currently, your data is stored as files, and you want to migrate to block storage. Unfortunately, there is no single command to achieve this in one step.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Thank you for the prompt response.

As you probably noticed: I'm new in this area => forgive me the newbie type of questions.

I'm reviewing the current Proxmox setup because it seems that block storage has a better performance (i.e. less latency).
Hence the question about switching to LVM-thin.

The idea is to take the current LVM-volume as a whole and somehow start using (mount?) it as block storage (versus the current dir/file storage). I'm ok with PVE taking the complete diskspace when creating a VM/LXC. And I don't use snapshots.

The table here shows that the LVM volume is indeed considered block storage.
But since it is mounted as a directory it is used as file storage.

I have a separate boot disk and separate disk for backups/copies of the existing data.
So apart from being time consuming copying is not a problem.

The purpose of this "exercise" is to maximize performance and minimize latency within the current setup of hard- and software.
Meaning it doesn't have to be LVM-thin assuming that LVM (thin or non-thin) gives me the best possible performance.

So perhaps I should rephrase the question:
On this page it shows how to mount a LVM volume.
(1) - Can I do this with a volume currently mounted as directory (and without data loss)?
(2) - The same for a LVM-thin volume and convert/mount it as a non-thin LVM-volume?
(3) - Any other benefits from using LVM-thin (other then snapshots)?

Any other suggestion(s)? Or things I should be aware of?
 
Last edited:
Before making any changes, it’s important to first understand what you have. The following commands will help visualize your storage structure:
Code: 
lsscsi    # (may need to be installed)
lsblk
pvs / pvdisplay
vgs / vgdisplay
lvs / lvdisplay

Compare the output against the diagram .

VM (Logical Volume Manager) is a flexible volume management suite that allows you to slice your disk into logical portions, which can then be consumed as raw block storage or formatted with a filesystem. From what you’ve described, it sounds like you currently have a filesystem-based setup.

In theory, fewer layers in the storage stack lead to better performance. However, before optimizing, consider the following:
  • Are you operating in an environment where microseconds truly matter?
  • Do you have NVMe disk ? Is your disk an enterprise-grade or consumer-grade?
  • Does your CPU have the capability to extract meaningful benefits from reducing overhead?
If this is a home lab or non-production setup, the performance gains might be negligible, and the effort may not be worth it.

Airw0lf said:
(1) - Can I do this with a volume currently mounted as directory (and without data loss)?
Click to expand...
You cannot do it with data staying in place
Airw0lf said:
The same for a LVM-thin volume and convert/mount it as a non-thin LVM-volume?
Click to expand...
You can force LVM slice to pre-allocate all the space on creation. In that case it will not be thin. This is not something that has a checkmark in PVE GUI.
Airw0lf said:
Any other benefits from using LVM-thin (other then snapshots)?
Click to expand...
Thin provisioning gives you an option to overprovision. I.e. create a 1TiB disk on 500GB hard drive. It does not mean that its a good idea.

In the end, each environment is unique. If this is production/enterprise - consider hiring a consultant to help. If you have time and flexibility - experimenting is the way to go.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: waltar
This is a home lab. And yes - I have time and flexibility here.
Meaning it is not a big production like environment where a few milliseconds really matter.

It is mainly me and my mindset to squeeze everything out of this setup.
And learn in the different aspects of the migration process.

The current LVM setup is 2 times software raid-0. Where each raid-0 has 2 spindle disks to the same controller.
These 2 raid-0 volumes contain all the raw VM and LXC volumes - no qcow2.

I have started moving all the VM and LXC volumes to the backup volume.
Meaning after a few hours both raid-0 volumes will be empty.
And I can start with the "native" LVM mounts and move all VM and LXC volumes back to these raid-0 volumes.
This time as block devices

Where "native" means remove the entries in /etc/fstab and unmount the 2 volumes.
Then re-mount by changing the config in /etc/pve/storage.cfg.
Referencing them with the vgnames like this (examples):
Code: 
#
lvm: all-PVE-volumes
        vgname raid-0-pve
        content rootdir,vztmpl,import,iso,snippets,images
#
lvm: addn-volume
        vgname raid-0-addn
        content rootdir,vztmpl,import,iso,snippets,images
 
Last edited:
You must log in or register to reply here.
Top Bottom