From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42616) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4TUB-0005GT-BF for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:09:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4TU5-0007uD-KS for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:09:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4TU5-0007u1-3X for qemu-devel@nongnu.org; Fri, 16 Sep 2011 04:09:17 -0400 Message-ID: <4E7304D1.6020705@redhat.com> Date: Fri, 16 Sep 2011 10:12:01 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4E70DEE8.8090908@linux.vnet.ibm.com> <4E71E41B.9050906@redhat.com> <4E72095A.7020300@linux.vnet.ibm.com> In-Reply-To: <4E72095A.7020300@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Design of the blobstore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: QEMU Developers , Stefan Hajnoczi , Anthony Liguori , Markus Armbruster , "Michael S. Tsirkin" Am 15.09.2011 16:19, schrieb Stefan Berger: > 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 >>> 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... Oh, so you created the image manually instead of using bdrv_img_create?() That explains it... Kevin