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

[Nicolás]

If instead of copying on step 1 the disk has been moved, any chance to adapt this workaround so the disk is thin provisioned on the target? We moved some machines before knowing this and unfortunately once moved to iSCSI the disk is preallocated, so moving it back won't do the trick.

Otherwise the workaround works perfectly.

Thanks.

-------- Mensaje original --------
De: Nir Soffer <nsoffer at redhat.com> 
Fecha:04/03/2016  23:23  (GMT+00:00) 
Para: Pavel Gashev <Pax at acronis.com> 
Cc: Nicolás <nicolas at devels.es>,amureini <amureini at redhat.com>,users at ovirt.org 
Asunto: Re: [ovirt-users] Storage migration: Preallocation forced on destination 

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?

> Please note that while disk moving keeps disk format, disk copying changes format. So when you copy a thin provisioned disk to iSCSI storage it's being converted to cow. The issue is that size of converted lv still looks like preallocated. You can decrease it manually via lvchange, or you can move it to a file based storage and back. Moving disks keeps disk format, but fixes its size.

Yes, this seems to be the way to work around this issue currently:
1. Copy to the disk to block storage - will convert it to qcow format
on preallocated lv
2. Move disk from block storage to file storage
3. Move disk back to block storage

> 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.

>
>
>
> On 04/03/16 23:23, "users-bounces at ovirt.org on behalf of Nir Soffer" <users-bounces at ovirt.org on behalf of nsoffer at redhat.com> wrote:
>
>>On Fri, Mar 4, 2016 at 7:07 PM, Nicolás <nicolas at devels.es> wrote:
>>> Hi,
>>>
>>> We're migrating an existing storage (glusterfs) to a new one (iSCSI). All
>>> disks on glusterfs are thin provisioned, but when migrating to iSCSI the
>>> following warning is shown:
>>>
>>>     The following disks will become preallocated, and may consume
>>> considerably more space on the target: local-disk
>>>
>>> Why is that? Is there a way to migrate disks so they are thin provisioned on
>>> iSCSI as well?
>>
>>The issue is that we use raw sparse format for thin provisioned disks
>>on file based
>>storage. The file system provides the thin provisioning, maintaining holes in
>>the files.
>>
>>When we create the destination lv, we use the disk virtual size, so you get
>>practically a preallocated volume.
>>
>>I think we can do better - before copying the disk, we can check the actual used
>>space (e.g. what qemu-img info or stat report), and create the
>>destination lv using
>>the used size (plus additional space for qcow format).
>>
>>I tested this by extending the destination lv manually and then
>>copying data manually
>>using qemu-img convert, and it works.
>>
>>Can you file a bug for this, and explain the use case?
>>
>>Nir
>>_______________________________________________
>>Users mailing list
>>Users at ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160307/3409cc0f/attachment-0001.html>