Re: [Qemu-devel] Design of the blobstore

[Kevin Wolf]

Am 15.09.2011 13:58, schrieb Stefan Hajnoczi:
>>> 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.

I'm not so sure if being able to integrate it in the VM state is a
feature or a bug. There is no other persistent data that is included in
VM state data.

Kevin