On 05/03/16 02:23, "Nir Soffer" <nsof...@redhat.com> wrote:
>On Sat, Mar 5, 2016 at 12:19 AM, Pavel Gashev <p...@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.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
