[Users] Migrating from KVM to oVirt 3.1 fails - corrupt OVF

Ayal Baron abaron at redhat.com
Sun Jul 22 20:20:50 UTC 2012


<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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
> 
> 
> --
> Shu Ming <shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
> 
> 
> 



More information about the Users mailing list