[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