From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JIUd7-0008JG-Ai for qemu-devel@nongnu.org; Fri, 25 Jan 2008 14:54:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JIUd5-0008IP-Gj for qemu-devel@nongnu.org; Fri, 25 Jan 2008 14:54:24 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIUd5-0008IL-9Q for qemu-devel@nongnu.org; Fri, 25 Jan 2008 14:54:23 -0500 Received: from outbound-va3.frontbridge.com ([216.32.180.16] helo=outbound1-va3-R.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JIUd4-0005Ih-Pq for qemu-devel@nongnu.org; Fri, 25 Jan 2008 14:54:23 -0500 Message-ID: <479A3E1B.2020500@amd.com> Date: Fri, 25 Jan 2008 20:52:59 +0100 From: "Andre Przywara" MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH][RFC] To mount qemu disk image on the host References: <1201264245.4114.42.camel@frecb07144> <4799FDBE.6030502@codemonkey.ws> <1201276153.4114.57.camel@frecb07144> In-Reply-To: <1201276153.4114.57.camel@frecb07144> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent.Vivier@bull.net Cc: qemu-devel@nongnu.org Laurent Vivier wrote: > Le vendredi 25 janvier 2008 =C3=A0 09:18 -0600, Anthony Liguori a =C3=A9= crit : >> Laurent Vivier wrote: >>> Hi, >>> >>> this patch allows to mount qemu disk images on the host. >>> =20 >=20 > Sorry, I didn't see you did a similar work 19 months ago. >> Note, the general problem with this approach is that mounting a NBD=20 >> device locally with write access can lead to dead locks. If you look=20 >> through the mailing list archives, you'll find a number of conversatio= ns=20 >> on the topic. I sometimes ago was also working on a nbd implementation for=20 qcow-images, but I came to the same deadlock conclusion. (At least=20 theoretically, I didn't finish this as I ran first into debugging=20 problems and secondly out of time). But IMHO this only applies to=20 localhost mounts, real network mounting should work (this is actually=20 not different from "native" nbd). Perhaps one could use a qemu instance=20 for the server part ;-) BTW: nbd-server should be quite portable, I once had it run on an=20 ancient PA-RISC machine under HP-UX 10.20. > What I'm wondering is how loop and device mapper can work ? I shortly evaluated the loop device idea, but came to the conclusion=20 that this not so easy to implement (and would require qcow code in the=20 kernel). I see only little chance for this go upstream in Linux and=20 maintaining this out-of-tree is actually a bad idea. If you think about deferring the qcow code into userland, you will=20 sooner or later run into the same deadlock problems as the current=20 solution (after all this is what nbd does...) I have implemented a clean device-mapper solution, the big drawback is=20 that it is read-only. It's a simple tool which converts the qcow map=20 into a format suitable for dm-setup, to which the output can be directly=20 piped to. I will clean up the code and send it to the list ASAP. Read/write support is not that easy, but maybe someone can comment on=20 this idea: Create a sparse file on the host which is as large as the number of all=20 still unallocated blocks. Assign these blocks via device mapper in=20 addition to the already allocated ones. When unmounting the dm device,=20 look for blocks which have been changed and allocate and write them into=20 the qcow file. One could also use the bmap-ioctl to scan for non-sparse=20 blocks. This is a bit complicated, but should work cleanly (especially for the=20 quick fsck or file editing case). If you find it worth, I could try to=20 implement it. Regards, Andre. --=20 Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business letters: AMD Saxony Limited Liability Company & Co. KG, Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896, General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy