From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VraBB-0001OJ-A9 for qemu-devel@nongnu.org; Fri, 13 Dec 2013 16:21:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VraB5-0001VX-Bd for qemu-devel@nongnu.org; Fri, 13 Dec 2013 16:21:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VraB5-0001VS-3i for qemu-devel@nongnu.org; Fri, 13 Dec 2013 16:21:43 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBDLLgLZ006017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Dec 2013 16:21:42 -0500 Date: Fri, 13 Dec 2013 22:21:39 +0100 From: Kevin Wolf Message-ID: <20131213212139.GK3916@dhcp-200-207.str.redhat.com> References: <1386954633-28905-1-git-send-email-mreitz@redhat.com> <1386954633-28905-13-git-send-email-mreitz@redhat.com> <20131213201958.GZ3916@dhcp-200-207.str.redhat.com> <52AB6FE2.2070903@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <52AB6FE2.2070903@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 12/22] block: Allow recursive "file"s List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 13.12.2013 um 21:36 hat Eric Blake geschrieben: > On 12/13/2013 01:19 PM, Kevin Wolf wrote: > > Am 13.12.2013 um 18:10 hat Max Reitz geschrieben: > >> It should be possible to use a format as a driver for a file which in > >> turn requires another file, i.e., nesting file formats. > >> > >> Signed-off-by: Max Reitz > >=20 > > Hm, does this do what I think it does? >=20 > That depends on what you think it's doing :) >=20 > >=20 > > $ ./qemu-img convert -O qcow2 /home/kwolf/images/hd.img /tmp/hd.qcow2 > > $ ./qemu-img convert -f raw -O qcow2 /tmp/hd.qcow2 /tmp/hd.qcow2.qcow2 > > $ x86_64-softmmu/qemu-system-x86_64 -drive driver=3Dqcow2,file.driver= =3Dqcow2,file.file.driver=3Dfile,file.file.filename=3D/tmp/hd.qcow2.qcow2 > >=20 > > I can't decide whether this is awesomeness or insanity, but in any case > > it works with this patch. :-) >=20 > So if I understood your example, you just created a qcow2 file, where > the non-metadata contents of that file are themselves a qcow2 data format. >=20 > Oh my. Hehe, that was exactly my first thought as well. But if we're serious about the direction that we're taking with blockdev-add - that is, letting the user build his graph of block drivers - then this is something we have to allow. It's just a proof that we do provide the flexibility we had in mind. > This could get nasty if someone ever wanted to try to get > libvirt to feed the nested contents to a guest (right now, libvirt has a > hard-coded assumption that qcow2 files only ever wrap raw data in the > non-metadata portion; there's no easy way to represent in the libvirt > storage volume XML a file where you want the nested guest contents of > qcow2 data wrapped inside the non-metadata portion of an outermost qcow2 > file). I don't think there's a good use case for nested qcow2, so I wouldn't expect libvirt to implement this. Until the first user comes up with a use case, of course. And like with everything scary that we assume nobody will ever do, someone will turn up eventually... > I guess it's not much different from a raw block device that has a > partition table, then in the first partition, you recursively add > another partition table (which is what you get when you hand one > partition of a host block device to the guest, and the guest then > partitions what it thinks is a full disk). And libguestfs is able to > see through nested partition tables, so on that front, the functionality > is similar. >=20 > Of course, the recursion has its use for blkverify and blkdebug, but > maybe (for our sanity) it would be worth preventing nesting across any > format that has metadata wrapping contents. I don't think qemu should prevent it. The architecture we want to have in the end doesn't really distinguish between formats and filters, there are only drivers. And technically there is nothing that allowing this breaks. libvirt, on the other hand, can probably expose something simpler. But as we discussed on KVM Forum, it's not unlikely that you'll have to have your own blockdev project sooner or later because users will want to have some of the flexibility - and then maybe nesting qcow2 falls out as naturally as it does in qemu now. Kevin --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSq3pjAAoJEH8JsnLIjy/Wf4MQAL5jlQgwyKeSQKDcHlepTBnu 5MEZ75VL0wHofGc2qWpoAKFy/5MnOh1qkZC0HtUjt3leKmJ0gvGKZP9LN5t+X4in Mpy4tdqYhoMyuspIociF5BkI/7Cv7FBi4Akap7ajHef0jw9yGrNZZzdPPCB1YXCB 0SQ6mlImRckrBtc1gv/mJRzqkuHkVIq6HMvcX/Sqyhq0Ws7HA2e3dGAwQZzJtsne 4zuUwwY1E39PQ+doqijNLMcIicpz/843G19z9e/e8lPbNzlFxOgAI81u2dEsM5cR nOeai39AcRDhz+w6amaysSxx0OorgcERxijJ8RrqvHTWIUxXu88n2eeGrVJZgFan NpALfe3N1ipm2L/FjoXlZ1d8NJ6m4KAaIwKUBRT8M+lxIuJl1zWbJ38MIhq27UK8 /zXK6zA/91qibDh7No73pas1EiyKkzgTfcCGH79fsoPozsi5CgEyRt85xFd5qDLe AWnPAxH/NHkeJSugp0wKle3AYiQHhgNUauIglX1FJiA3KCW2f+QL+0H06RkUQGrG zE4hL04wdeFhU1+IPoGdilGbATEzgv0SJcw+3NWK+ZT86fWyWf8bObqomDqu25LB dYCcMBe7v5yDAzXz2gSeNrW+pz+rSfDj11yycZjS3jW+WPa5sR0IPRtfdC+IRwjw 69aZvtSnZbsY5KFV9/fI =ko4V -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw--