Hello, I was hoping that in 2026 there would be some kind of fix for this by now but I'm still not seeing one. Hopefully I'm just missing something.

Context: I have 4x PVE 9.1 nodes in a cluster. Each has local storage as local-lvm.

After live migrating a VM from one host to another. The disk becomes "thick" that is, if it's a 200GB disk, but only 10GB are used. The size of the virtual drive on the host disk expands to 200GB (No longer being "thin").

This can be resolved by enabling "discard" on the VM disk and performing an fstrim in the guest. However there are two issues with that.
1. If the VM has discard enabled, the live migration process absolutely thrashes the destination host. Causing high io load and freezing disk access for the most part for the other VMs on the destination host. If you disable discard on the disk, and do the same migration. This doesn't occur.
2. Enabling/Disabling discard requires a power down of the guest VM to apply. So the process becomes Migrate>Power Down VM>Enable Discard>Boot VM>Do fstrim>Power Down VM>Disable Discard>Boot VM. Which is a pretty painful process end-to-end. And has to be done after each host migration.

Besides some kind of shared storage (Ceph, a SAN..etc.) is there really no other option?

Thank you!

Yes. That option is already enabled. But if discard isn't enabled on the disk, the trim doesn't flow to the virtual disk on the host storage and remains "thick".

ZFS may be an option (Currently using RAID cards, so would need to convert to an HBA..etc). These migrations don't happen super often. So it's probably best that I just leave it. Just was hoping for a better solution!. Thank you for your reply!

Thank you!

Yes. That option is already enabled. But if discard isn't enabled on the disk, the trim doesn't flow to the virtual disk on the host storage and remains "thick".

ZFS may be an option (Currently using RAID cards, so would need to convert to an HBA..etc). These migrations don't happen super often. So it's probably best that I just leave it. Just was hoping for a better solution!. Thank you for your reply!

although not tested: lvm-vdo beneath the lvm-thin pool could be a solution ... it adds additional burden but for the zero block detection only -> compression and dedup can be disabled .... which helps performance