[Top][All Lists]

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

Re: [Qemu-devel] Design of the blobstore

From: Stefan Berger
Subject: Re: [Qemu-devel] Design of the blobstore
Date: Thu, 15 Sep 2011 10:19:06 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

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
<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?
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...



reply via email to

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