Re: [Users] Migrating from KVM to oVirt 3.1 fails - corrupt OVF
<SNIP>
>>
>>> Would a qcow2 image with preallocation=metadata be possible on an
>>> iSCSI data store?
>> ayal?
>>
> nope. metadata preallocation means that each logical block has a
> corresponding physical block.
Ayal, by saying "logical block" and physical block here, what do
they
stand for in linux systems? I guess, physical block is "the scsi lun
disk", logical block is "lvm disk"? right?
No, guest writing to block X, qcow maps X to Y on underlying device (e.g. LV)
X is logical in example above.
Y is 'physical'
*Warning*, following explanation is a bit convoluted ;)
Metadata preallocation means that all qcow clusters are already preset with every X mapped
to a Y.
Now on block storage, if guest writes to an X where X is mapped to Y which is beyond
device size (because it's thinly provisioned), we would need to extend device to at
least Y if not beyond.
Worst case is if the guest I/O is to a block which is mapped to offset = size of virtual
disk, which would force us to preallocate the entire disk at this point for a single
block.
> With files this is fine as you can seek wherever you want and the
> file will remain sparse. With block devices this makes little
> sense as the second the guest accesses a block which is mapped to
> an unallocated physical block we'd have to allocate all the area
> up to that point.
> (btw, qemu-img will fail if you try to create such an image on a
> block device)
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
--
Shu Ming <shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory