Migration on LVM-thin

[macleod]

Hello

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!

 

[Stoiko Ivanov]

The behavior is currently "normal", but was mitigated some time ago in qemu-server
see https://bugzilla.proxmox.com/show_bug.cgi?id=1242 for a description.

The mitigation is letting the qemu-guest-agent run the fstrim after a disk-move happens.

 

[Stoiko Ivanov]

The behavior is currently "normal", but was mitigated some time ago in qemu-server
see https://bugzilla.proxmox.com/show_bug.cgi?id=1242 for a description.

The mitigation is letting the qemu-guest-agent run the fstrim after a disk-move happens.

 

[macleod]

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 ?

 

[larsen]

Any solution to this problem, yet?

 

[fiona]

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

 

[larsen]

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.

 

[fiona]

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.