11:18 a.m.
On Mon, Feb 20, 2017 at 11:39 PM, Nir Soffer <nsoffer(a)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....