Re: [Qemu-devel] Design of the blobstore

[Stefan Hajnoczi]

On Thu, Sep 15, 2011 at 12:40 PM, Kevin Wolf <address@hidden> wrote:
> 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.

Sure, you need a file because the data needs to be persistent.  I'm
not saying to keep it in memory only.

My concern is that while QEMU block devices provide a convenient
wrapper for snapshot and encryption, we need to write the data layout
that goes inside that wrapper from scratch.  We'll need to invent our
own key-value store when there are plenty of existing ones.  I
explained that the snapshot feature is actually a misfeature, it would
be better to integrate with VM state data so that there is no
additional migration requirement.

As for encryption, just encrypt the values you put into the key-value store.

Stefan