On Mon, Feb 20, 2017 at 11:39 PM, Nir Soffer <nsoffer@redhat.com> wrote:
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 :-)
Actually you wrote the correct name that I intercepted during live storage migration. The output disk of the migration was /rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660he But I see that indeed the name is now without the final "he" part... don't know if the suffix is in place only during the migration as a sort of notifier/lock.... [g.cecchi@ovmsrv07 ~]$ ll /rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660 lrwxrwxrwx. 1 vdsm kvm 78 Feb 13 22:39 /rhev/data-center/mnt/blockSD/5ed04196-87f1-480e-9fee-9dd450a3b53b/images/6af3dfe5-6da7-48e3-9eb0-1e9596aca9d3/9af3574d-dc83-485f-b906-0970ad09b660 -> /dev/5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906-0970ad09b660 [g.cecchi@ovmsrv07 ~]$
[root@ovmsrv07 ~]# qemu-img check /dev/5ed04196-87f1-480e-9fee-9 dd450a3b53b/9af3574d-dc83-485f-b906-0970ad09b660 No errors were found on the image. 41734/491520 = 8.49% allocated, 3.86% fragmented, 0.00% compressed clusters Image end offset: 2736128000
So you have 2.5 G image in 33G lv?
Yes, I created a 30Gb disk but in the mean time only a small part of it is used. Inside the VM: [root@c7service ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 30G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 29G 0 part ├─cl-root 253:0 0 26G 0 lvm / └─cl-swap 253:1 0 3G 0 lvm [SWAP] sr0 11:0 1 1024M 0 rom [root@c7service ~]# [root@c7service ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/cl-root 26G 2.2G 24G 9% / devtmpfs 2.0G 0 2.0G 0% /dev tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 2.0G 17M 2.0G 1% /run tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sda1 1014M 150M 865M 15% /boot tmpfs 396M 0 396M 0% /run/user/0 [root@c7service ~]#
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
Thanks for the information, that could be useful But my concern was not to reduce the disk size in this case: I'll let the free space for future applications I have to install. My concern was that one would expect to see actual size of a thin provisioned disk always less or equal the virtual one and not the opposite....