Migration on LVM-thin


Well-Known Member
Aug 3, 2017

A strange (but possible normal) behavior when moving VMs or changing storage when using local LVM thin storage (online move, with vm running):

- when moving a VM from a host to another (in particular, with multiple disks)
qm migrate #ID #destination -migration_type insecure -online -with-local-disks 1
1. lvm-thin volume is created on destination
2. lvm-thin destination volume becomes 'thick' (usage rises to 100%)
3. ALL volume data (as in 100%, even unused data) is copied
4. lvm-thin source volume(s) are deleted, destination volume(s) remains at 100%
5. after issuing of fstrim -av (or fstrim -v / and another partitions), the used space on destination host is like original (maybe even better if fstrim was not used for longtime at source)
6. for swap partition/disks, it must be mounted with special arguments (and also get 'trimmed' after that)

- same on moving storage from LVM-thin to NFS storage, but fstrim works only when nfs is mounted as version 4.2 (below it does not support trim)

is this a normal behavior ? For me it's quite unusual to copy let's say 100GB partition when only 5, or 20 GB are used.
Am I missing some parameters in qm command ?

Thank you!
Thank you for your quick answer. Indeed, the agent was not installed on that test machine, so that's why I needed a manual fstrim.
But automatic or manual, that mitigation I call myself a 'horrible hack', because I need unused space on destination host just for the 'thickness' and also the required time for migration rises with of magnitude of at least 5 or 10, maybe even more (mileage may vary, of course).
Is there any local storage solution with thin and snapshots (and also unfortunately not zfs) that can improve the data transfer when moving 'thin' VMs (aka 10%-20%,maybe 30% actual data usage)? Or any planned 'upgrades' for this problem with LVM-thin ?
Last edited:
Yes, it should be working now. You need to:
  1. Install the QEMU guest agent within the guest
  2. Enable it in the Options pane of your guest and also check the Run guest-trim after clone-disk checkbox
  3. Reboot the guest so the changes in the config take effect
Yes, but I meant the underlying problem. This is just a workaround, but still copying e.g. 300 GB when only 5 GB would be needed.
You're right. I think this is a missing feature of QEMU's drive-mirror mechanism. As long as that is not implemented, I suggest copying such disks while the VM is not running; that should do sparse copying.


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!