[ovirt-users] actual size greater than virtual size?

Nir Soffer nsoffer at redhat.com
Mon Feb 20 22:39:43 UTC 2017


On Tue, Feb 21, 2017 at 12:17 AM, Gianluca Cecchi <gianluca.cecchi at gmail.com
> wrote:

>
>
> On Mon, Feb 20, 2017 at 11:08 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>
>> On Tue, Feb 14, 2017 at 12:07 AM, Gianluca Cecchi <
>> gianluca.cecchi at gmail.com> wrote:
>>
>>> Hello,
>>> I'm on 4.1 with 2 FC SAN storage domains and testing live migration of
>>> disk.
>>>
>>> I started with a CentOS 7.3 VM with a thin provisioned disk of 30Gb.
>>> It seems that I can see actual disk size in VM--> Snapshots--> Active VM
>>> line and the right sub pane.
>>> If I remember correctly before the live storage migration the actual
>>> size was 16Gb.
>>> But after the migration it shows actual size greater than virtual
>>> (33Gb)??
>>>
>>
>> Hi Gianluca,
>>
>> This is possible for thin disks.
>>
>> With thin disk we have some overhead for qcow2 metadata, which can be
>> up to 10% in the worst case. So when doing operations on thin disk, we
>> may enlarge it to the virtual size * 1.1, which is 33G for 30G disk.
>>
>> Can you share the output of this commands?
>>
>> (If the vm is running, you should skip the lvchange commands)
>>
>> lvchange -ay 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906
>> -0970ad09b660he
>>
>> qemu-img check /dev/5ed04196-87f1-480e-9fee-9
>> dd450a3b53b/9af3574d-dc83-485f-b906-0970ad09b660he
>>
>> lvchange -an 5ed04196-87f1-480e-9fee-9dd450a3b53b/9af3574d-dc83-485f-b906
>> -0970ad09b660he
>>
>> Nir
>>
>>
>>>
>>>
> 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 :-)


> [root at 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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170221/5a7edf82/attachment.html>


More information about the Users mailing list