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&gt; > IBM China Systems and Technology Laboratory > > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users