[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Design of the blobstore

From: Kevin Wolf
Subject: Re: [Qemu-devel] Design of the blobstore
Date: Fri, 16 Sep 2011 10:46:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]