[ovirt-users] Storage migration: Preallocation forced on destination

[Nir Soffer]

On Sat, Mar 5, 2016 at 10:52 AM, Pavel Gashev <Pax at acronis.com> wrote:
> On 05/03/16 02:23, "Nir Soffer" <nsoffer at redhat.com> wrote:
>
>>On Sat, Mar 5, 2016 at 12:19 AM, Pavel Gashev <Pax at acronis.com> wrote:
>>> I think it's hard to calculate the additional space for cow format without analysing raw image. It's better to allocate enough space, and then decrease it after qemu-img convert.
>>
>>We use 10% as a rough estimate for additional space when converting
>>from raw to qcow format. Sure it will waste some space, but it is good
>>enough.
>>
>>How to you plan to check the used size on the destination lv?
>
> "qemu-img check" reports image end offset. Also it has --output=json option.
>
> # qemu-img check --output=json /rhev/data-center/00000002-0002-0002-0002-0000000002db/2e9250bd-5cf3-40c2-8e85-1e31d4c4d779/images/bc4c68be-0bb0-436a-b18d-014d9ae4e580/9b63d90e-cb1e-4a30-a0b6-0b80fa201f8d
> {
>     "image-end-offset": 14648672256,
>     "total-clusters": 524288,
>     "check-errors": 0,
>     "allocated-clusters": 223439,
>     "filename": "/rhev/data-center/00000002-0002-0002-0002-0000000002db/2e9250bd-5cf3-40c2-8e85-1e31d4c4d779/images/bc4c68be-0bb0-436a-b18d-014d9ae4e580/9b63d90e-cb1e-4a30-a0b6-0b80fa201f8d",
>     "format": "qcow2",
>     "fragmented-clusters": 6
> }

Right, actually we are already doing this after cold merge,
- https://github.com/oVirt/vdsm/blob/d87d031ea52eb76aab29cd0c55d7f3b5f0743ccd/vdsm/storage/blockVolume.py#L581
- https://github.com/oVirt/vdsm/blob/d87d031ea52eb76aab29cd0c55d7f3b5f0743ccd/vdsm/storage/image.py#L1262

We should start doing this after moving and copying thin disks, and after
live mege.

With live merge, we make sure that the base volume is large enough to
include all data from the top volume. This does overallocation and having
automatic shrinking after that can be nice.

>>> Also please consider qcow compat=1.1 as default disk format both for file and block storages.
>>
>>This will make your disk incompatible with old ovirt versions on el6.
>>In storage domain format v3
>>we are using comapt=0.10.
>>
>>We plan to move to compat=1.1 in 4.0.
>
> Too long to wait :) Currently it's hardcoded. It would be great, if it was configurable via /etc/vdsm/vdsm.conf at least. It would allow early adopt compat=1.1 in el7 environments.

Good idea, If you file a bug and send a patch it will be available in
the next release.

Nir