From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AE0-0000r1-CZ for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4ADy-00037t-Vl for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:35:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4ADy-00037j-Mf for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:35:22 -0400 Date: Thu, 15 Sep 2011 12:35:14 +0100 From: "Daniel P. Berrange" Message-ID: <20110915113514.GI29309@redhat.com> References: <4E70DEE8.8090908@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Design of the blobstore Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Anthony Liguori , "Michael S. Tsirkin" , Stefan Berger , QEMU Developers , Markus Armbruster On Thu, Sep 15, 2011 at 12:17:54PM +0100, Stefan Hajnoczi wrote: > On Wed, Sep 14, 2011 at 6:05 PM, Stefan Berger > wrote: > > =C2=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 wr= iter 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 th= e data > > on the disk lets QEMU calculate the total required (minimum) size tha= t the > > image has to have to accommodate all blobs in a particular blobstore. >=20 > Libraries like tdb or gdbm come to mind. We should be careful not to > reinvent cpio/tar or FAT :). qcow2 is desirable because it lets us provide encryption of the blobstore which is important if you don't trust the admin of the NFS server, or the network between the virt host & NFS server. > 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. NB, I'm not neccessarily recommending this, but it is possible to format a raw block device, to contain a qcow2 image. So it does not actually require a shared filesystem. it would however require an additional LUN, or require that the existing LUN be partitioned into two parts. Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|