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-9dd450a3b53b/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....