Am 15.09.2011 16:19, schrieb Stefan Berger: > On 09/15/2011 07:40 AM, Kevin Wolf wrote: >> Am 15.09.2011 13:17, schrieb Stefan Hajnoczi: >>> On Wed, Sep 14, 2011 at 6:05 PM, Stefan Berger >>> <stef...@linux.vnet.ibm.com> wrote: >>>> One property of the blobstore is that it has a certain required size for >>>> accommodating all blobs of device that want to store their blobs onto. The >>>> assumption is that the size of these blobs is know a-priori to the writer >>>> of >>>> the device code and all devices can register their space requirements with >>>> the blobstore during device initialization. Then gathering all the >>>> registered blobs' sizes plus knowing the overhead of the layout of the data >>>> on the disk lets QEMU calculate the total required (minimum) size that the >>>> image has to have to accommodate all blobs in a particular blobstore. >>> Libraries like tdb or gdbm come to mind. We should be careful not to >>> reinvent cpio/tar or FAT :). >> We could use vvfat if we need a FAT implementation. *duck* >> >>> What about live migration? If each VM has a LUN assigned on a SAN >>> then these qcow2 files add a new requirement for a shared file system. >>> >>> Perhaps it makes sense to include the blobstore in the VM state data >>> instead? If you take that approach then the blobstore will get >>> snapshotted *into* the existing qcow2 images. Then you don't need a >>> shared file system for migration to work. >> But what happens if you don't do fancy things like snapshots or live >> migration, but just shut the VM down? Nothing will be saved then, so it >> must already be on disk. I think using a BlockDriverState for that makes >> sense, even though it is some additional work for migration. But you >> already deal with n disks, doing n+1 disks shouldn't be much harder. >> >> >> The one thing that I didn't understand in the original mail is why you >> think that raw works with your option but qcow2 doesn't. Where's the >> difference wrt creating an image? > I guess you are asking me (also 'Stefan'). > > When I had QEMU create the disk file I had to pass a file parameter to > -drive ...,file=... for it to know which file to create. If the file > didn't exist, I got an error. So I create an empty file using 'touch' > and could at least start. Though an empty file declared with the format > qcow2 in -drive ...,file=...,format=qcow2 throws another error since > that's not a valid QCoW2. I wanted to use that parameter 'format' to > know what the user wanted to create. So in case of 'raw', I could start > out with an empty file, have QEMU calculate the size, call the > 'truncate' function on the bdrv it was used with and then had a raw > image of the needed size. THe VM could start right away...
Oh, so you created the image manually instead of using bdrv_img_create?() That explains it... Kevin