[ovirt-users] actual size greater than virtual size?
Gianluca Cecchi
gianluca.cecchi at gmail.com
Tue Feb 21 08:18:26 UTC 2017
On Mon, Feb 20, 2017 at 11:39 PM, Nir Soffer <nsoffer at 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 at 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 at ovmsrv07 ~]$
>
>
>> [root at 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 at 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 at c7service ~]#
[root at 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 at 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....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170221/09017941/attachment.html>
More information about the Users
mailing list