On Thu, Sep 15, 2011 at 12:40 PM, Kevin Wolf <kw...@redhat.com> wrote: > Am 15.09.2011 13:17, schrieb Stefan Hajnoczi: >> On Wed, Sep 14, 2011 at 6:05 PM, Stefan Berger >> <stef...@linux.vnet.ibm.com> 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
