Lvm thin get's fat after moving / cloning disks.

[mailinglists]

As stated in the title, when one moves LVM thin it get's fat. And by fat I mean as fat as it can get (100%).
I think this is a bug. It happens only when disk of a _running_ VM is moved.

Here is an example using almost latest PM from public/free repos.
VM is created from KVM CentOS 7 template I prepared.

VM 103 created and is thin (12.29% usage):
# lvs | grep 103
  vm-103-disk-1 pve     Vwi-aotz-- 15.00g data            12.29

VM disk get's moved to external NFS storage to qcow2 format and get's fat:
# du -sh *
16G    vm-103-disk-1.qcow2

Moving it back keeps it fat:
# lvs | grep 103
  vm-103-disk-1 pve     Vwi-aotz-- 15.00g data            100.00 

And because we hate fatties, it get's killed. Then fresh thin one is created and _started_:
# lvs  | grep 102
  vm-102-disk-1 pve     Vwi-a-tz-- 15.00g data        12.29 

It get's moved to another LVM thin VG and becomes fat right away.
# lvs | grep 102
  vm-102-disk-1 pvesata Vwi-aotz-- 15.00g datasata        100.00

So basically thin LVM is not really thin when one uses disk migration in order to move VM's in order to do maintenance on host which is what every good admin should do. I'm reporting this as a bug.

 

[mailinglists]

Added bug report here:
https://bugzilla.proxmox.com/show_bug.cgi?id=1242

Also when migrating running VMs disk, it takes much much longer and the system becomes quite a bit less responsive (iowait maybe?).

 

[DarkUmbra]

To the developers: It would be nice to receive a warning that this size increase is going to happen before committing to the action. I now have a fat disk, ten times the previous thin size before moving, and I don't know how to shrink it.

 

[mailinglists]

You can reclaim disk space by rebooting the VM and then running trim operation from the guest.
And I completely agree with you, but no developer will read this.