Hi Gianluca. This is most likely caused by the temporary snapshot we create when performing live storage migration. Please check your VM for snapshots and delete the temporary one. On Mon, Feb 13, 2017 at 5:07 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote: -- Adam Litke

Ok, thanks for clarifying that. So it looks like the temporary snapshot was already merged/deleted. As part of that operation, vdsm calculates how large the original volume would have to be (LV size) in order to guarantee that the base volume has enough space for the merge to complete. It looks like in this case we decided that value was the virtual size + 10% for qcow2 metadata. If your base volume was only about 16G allocated prior to all of this than it seems we were way too conservative. Did you remove the snapshot quickly after the move completed? One thing that could cause this is if you wrote about 12-15 GB of data into the that disk after moving but before deleting the temporary snapshot. Do you happen to have the vdsm logs from the host running the VM and the host that was acting SPM (if different) from during the time you experienced this issue? On Mon, Feb 20, 2017 at 10:02 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > On Mon, Feb 20, 2017 at 3:38 PM, Adam Litke <alitke(a)redhat.com> >> Hi Gianluca. This is most likely caused by the temporary snapshot we >> create when performing live storage migration. Please check your VM for >> snapshots and delete the temporary one. >> >> > Hi Adam, > as you see from my attachment, there is one line for snapshots, the > current one, and no others. > So the VM is without snapshots. > See bigger frame here: > https://drive.google.com/file/d/0BwoPbcrMv8mvbDZaVFpvd1Ayd0k/ > view?usp=sharing > > Gianluca > > -- Adam Litke

On Tue, Feb 14, 2017 at 12:07 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com Hi Gianluca, This is possible for thin disks. With thin disk we have some overhead for qcow2 metadata, which can be up to 10% in the worst case. So when doing operations on thin disk, we may enlarge it to the virtual size * 1.1, which is 33G for 30G disk. Can you share the output of this commands? (If the vm is running, you should skip the lvchange commands) lvchange -ay 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906- 0970ad09b660he qemu-img check /dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/ 9af3574d-dc83-485f-b906-0970ad09b660he lvchange -an 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906- 0970ad09b660he Nir

On Tue, Feb 21, 2017 at 12:17 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > > > On Mon, Feb 20, 2017 at 11:08 PM, Nir Soffer <nsoffer(a)redhat.com> >> On Tue, Feb 14, 2017 at 12:07 AM, Gianluca Cecchi < >> gianluca.cecchi(a)gmail.com>> >>> Hello, >>> I'm on 4.1 with 2 FC SAN storage domains and testing live migration of >>> disk. >>> >>> I started with a CentOS 7.3 VM with a thin provisioned disk of 30Gb. >>> It seems that I can see actual disk size in VM--> Snapshots--> Active VM >>> line and the right sub pane. >>> If I remember correctly before the live storage migration the actual >>> size was 16Gb. >>> But after the migration it shows actual size greater than virtual >>> (33Gb)?? >>> >> >> Hi Gianluca, >> >> This is possible for thin disks. >> >> With thin disk we have some overhead for qcow2 metadata, which can be >> up to 10% in the worst case. So when doing operations on thin disk, we >> may enlarge it to the virtual size * 1.1, which is 33G for 30G disk. >> >> Can you share the output of this commands? >> >> (If the vm is running, you should skip the lvchange commands) >> >> lvchange -ay 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906 >> -0970ad09b660he >> >> qemu-img check /dev/5ed04196-87f1-480e-9fee-9 >> dd450a3b53b/9af3574d-dc83-485f-b906-0970ad09b660he >> >> lvchange -an 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906 >> -0970ad09b660he >> >> Nir >> >> >>> >>> > Yes, the VM is active. > In this moment the disk name seems to be without the final "he" letters.... > Seems to be an issue between my keyboard and chair :-) So you have 2.5 G image in 33G lv? If this is internal volume, you can reduce it to the next power of 128m - 2688m If this is active volume, you want to leave empty space at the end. since you are using 4G extent size, you can reduce it to 6784m. To reduce the lv: 1. Move storage domain to maintenance 2. Check again the image end offset using qemu-img check lvchange -ay vg-name/lv-name qemu-img check /dev/vg-name/lv-name lvchange -an vg-name/lv-name 2. use lvreduce (update the size if needed) lvreduce -L 2688m vg-name/lv-name 3. Actvate the storage domain We are working now on integrating this into the flows like cold and live merge. Nir