From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JIQn6-00055d-P5 for qemu-devel@nongnu.org; Fri, 25 Jan 2008 10:48:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JIQn2-00053X-02 for qemu-devel@nongnu.org; Fri, 25 Jan 2008 10:48:27 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIQn1-00053P-M8 for qemu-devel@nongnu.org; Fri, 25 Jan 2008 10:48:23 -0500 Received: from ecfrec.frec.bull.fr ([129.183.4.8]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JIQn1-0006yh-9o for qemu-devel@nongnu.org; Fri, 25 Jan 2008 10:48:23 -0500 Subject: Re: [Qemu-devel] [PATCH][RFC] To mount qemu disk image on the host From: Laurent Vivier In-Reply-To: <4799FDBE.6030502@codemonkey.ws> References: <1201264245.4114.42.camel@frecb07144> <4799FDBE.6030502@codemonkey.ws> Date: Fri, 25 Jan 2008 16:49:13 +0100 Message-Id: <1201276153.4114.57.camel@frecb07144> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Le vendredi 25 janvier 2008 =C3=A0 09:18 -0600, Anthony Liguori a =C3=A9cri= t : > Laurent Vivier wrote: > > Hi, > > > > this patch allows to mount qemu disk images on the host. > > =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 conversations=20 > on the topic. Yes, I experimented some problems with heavily loaded I/O (2 * dbench 64 on a 4 CPUs SMP) But perhaps to edit config files or fsck partition of a virtual machine it is acceptable. What I'm wondering is how loop and device mapper can work ? > Regards, >=20 > Anthony Liguori Thank you, Laurent > > It is based on the Network Block Device protocol and allows qemu-img to > > become an NBD server (Yes, Anthony, userspace block device is the right > > way to do that... :-P ). > > > > Once you've applied the attached patch to Qemu and build the binaries, > > you can use it like that: > > > > # ./qemu-img server -d 1234 etch.qcow2 > > > > This starts an NBD server on port 1234. This server will expose > > the disk image etch.qcow2. "-d" means it will be daemonize and will run > > in background. > > > > Then you need to connect the block device to the server: > > > > # nbd-client localhost 1234 /dev/nbd0 > > Negotiation: ..size =3D 4194304KB > > bs=3D1024, sz=3D4194304 > > > > This will link etch.qcow2 to /dev/nbd0. > > > > Then to see partitions, you can use kpartx, as explained Daniel, or my > > patched loop modules (I can send an updated and bug free version). > > ... > > # kpartx -a /dev/nbd0 > > ... > > or > > ... > > # rmmod loop > > # insmod drivers/block/loop.ko max_part=3D64 > > # losetup -f /dev/nbd0 > > ... > > # mount /dev/loop0p1 /mnt > > # ls /mnt > > bench cdrom etc initrd.img media proc selinux tmp vmlinuz > > bin clients home lib mnt root srv usr > > boot dev initrd lost+found opt sbin sys var > > # cd > > # umount /mnt > > # losetup -d /dev/loop0 > > # nbd-client -d /dev/nbd0 > > > > TODO: security/host client checking, device lock... > > > > As usual all comments are welcome, > > have fun, > > Laurent > > =20 >=20 >=20 >=20 >=20 --=20 ----------------- Laurent.Vivier@bull.net ------------------ "La perfection est atteinte non quand il ne reste rien =C3=A0 ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry