Re: [ovirt-users] Storage migration: Preallocation forced on destination
On 05/03/16 02:23, "Nir Soffer" <nsoffer(a)redhat.com> wrote:
On Sat, Mar 5, 2016 at 12:19 AM, Pavel Gashev <Pax(a)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
}
> 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
Yes. This is how I've moved my stuff from M$ NFS to iSCSI. Note this works well since
3.6.3 only, see https://bugzilla.redhat.com/1304405
> 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.