Re: [Qemu-devel] Design of the blobstore

[Kevin Wolf]

Am 15.09.2011 13:17, schrieb Stefan Hajnoczi:
> On Wed, Sep 14, 2011 at 6:05 PM, Stefan Berger
> <address@hidden> 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?

Kevin