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?