From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Cmy-0000Zi-1q for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:19:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Cmt-0002Qy-Rq for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:19:40 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:60405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Cmt-0002QI-PI for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:19:35 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Thu, 15 Sep 2011 10:19:34 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8FEJH62227294 for ; Thu, 15 Sep 2011 10:19:18 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8FEJ70g030876 for ; Thu, 15 Sep 2011 08:19:07 -0600 Message-ID: <4E72095A.7020300@linux.vnet.ibm.com> Date: Thu, 15 Sep 2011 10:19:06 -0400 From: Stefan Berger MIME-Version: 1.0 References: <4E70DEE8.8090908@linux.vnet.ibm.com> <4E71E41B.9050906@redhat.com> In-Reply-To: <4E71E41B.9050906@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Kevin Wolf Cc: QEMU Developers , Stefan Hajnoczi , Anthony Liguori , Markus Armbruster , "Michael S. Tsirkin" 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... Stefan > Kevin >