Re: [Qemu-devel] Design of the blobstore

[Kevin Wolf <kwolf@redhat.com>]

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
>>> <stefanb@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