From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AZu-0003cL-VW for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4AZt-0000ft-ER for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:02 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:52319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AZt-0000fB-7S for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:01 -0400 Received: by gye5 with SMTP id 5so2483972gye.4 for ; Thu, 15 Sep 2011 04:58:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E71E41B.9050906@redhat.com> References: <4E70DEE8.8090908@linux.vnet.ibm.com> <4E71E41B.9050906@redhat.com> Date: Thu, 15 Sep 2011 12:58:00 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Design of the blobstore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Markus Armbruster , Anthony Liguori , "Michael S. Tsirkin" , QEMU Developers , Stefan Berger On Thu, Sep 15, 2011 at 12:40 PM, Kevin Wolf wrote: > Am 15.09.2011 13:17, schrieb Stefan Hajnoczi: >> On Wed, Sep 14, 2011 at 6:05 PM, Stefan Berger >> wrote: >>> =A0One 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 writ= er of >>> the device code and all devices can register their space requirements w= ith >>> 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. =A0We 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? =A0If 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? =A0If you take that approach then the blobstore will get >> snapshotted *into* the existing qcow2 images. =A0Then 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