From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nv4Wm-0002rB-58 for qemu-devel@nongnu.org; Fri, 26 Mar 2010 04:04:24 -0400 Received: from [140.186.70.92] (port=42309 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nv4T7-0001Xz-JK for qemu-devel@nongnu.org; Fri, 26 Mar 2010 04:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nv4S4-0002LZ-Qe for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:59:34 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:35320) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nv4S4-0002LT-DS for qemu-devel@nongnu.org; Fri, 26 Mar 2010 03:59:32 -0400 Message-ID: <4BAC695C.5050002@web.de> Date: Fri, 26 Mar 2010 08:59:24 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access References: <4BABA2FB.8050505@web.de> <4BABCE82.7000105@codemonkey.ws> <4BABD9C3.9010309@web.de> <4BABDDF9.2070705@codemonkey.ws> <4BABE35D.70909@web.de> <4BABE98F.1050506@codemonkey.ws> In-Reply-To: <4BABE98F.1050506@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig176C7D58BEADFF7AC9B616BB" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig176C7D58BEADFF7AC9B616BB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > On 03/25/2010 05:27 PM, Jan Kiszka wrote: >> Anthony Liguori wrote: >> =20 >>> On 03/25/2010 04:46 PM, Jan Kiszka wrote: >>> =20 >>>> Anthony Liguori wrote: >>>> >>>> =20 >>>>> On 03/25/2010 12:52 PM, Jan Kiszka wrote: >>>>> >>>>> =20 >>>>>> This adds the "map" subcommand to qemu-img. It is able to expose t= he >>>>>> raw >>>>>> content of a disk image via a FUSE filesystem. Both the whole disk= >>>>>> can >>>>>> be accessed, e.g. to run partitioning tools against it, as well as= >>>>>> individual partitions. This allows to create new filesystems in th= e >>>>>> image or loop-back mount exiting ones. Using the great mountlo too= l >>>>>> from the FUSE collection [1][2], the latter can even be done by >>>>>> non-root >>>>>> users (the former anyway). >>>>>> >>>>>> There are some dependency to fulfill to gain all features: Partiti= on >>>>>> scanning is done via recent libblkid (I used version 2.17.1). If t= his >>>>>> library is not available, only the disk file is provide. Fortunate= ly, >>>>>> mountlo can do partition scanning as well ("-p n") to work around >>>>>> this. >>>>>> >>>>>> Moreover, libfuse>=3D 2.8 and a host kernel>=3D 2.6.29 is required= for >>>>>> seamless disk access via fdisk. Otherwise, the BLKGETSIZE64 IOCTL >>>>>> cannot >>>>>> be provided, and the number of cylinders has to set explicitly (e.= g. >>>>>> via >>>>>> "-C n"). >>>>>> >>>>>> This work was inspired by Ashley Saulsbury's qemu-diskp [3]. >>>>>> >>>>>> [1] >>>>>> http://sourceforge.net/apps/mediawiki/fuse/index.php?title=3DFileS= ystems#Mountlo >>>>>> >>>>>> >>>>>> >>>>>> [2] http://sourceforge.net/projects/fuse/files/mountlo/ >>>>>> [3] http://www.saulsbury.org/software/virtualization.html >>>>>> >>>>>> Signed-off-by: Jan Kiszka >>>>>> >>>>>> >>>>>> =20 >>>>> This has been proposed quite a few times. >>>>> >>>>> In fact, I wrote something like this prior to implementing qemu-nbd= =2E >>>>> >>>>> The problem with fuse is that as default configured, you can't >>>>> actually >>>>> enter into a fuse filesystem as root and since you need to be root = to >>>>> loopback mount it, it pretty nasty from a usability perspective. >>>>> >>>>> =20 >>>> You don't, see mountlo. >>>> >>>> =20 >>> That definitely changes things. I assume it just uses libe2fs et al = to >>> display filesystem contents? >>> =20 >> Nope. It's a bit like libguestfs as it uses Linux to access the >> filesystems, but that Linux runs in UML mode, thus does not require an= y >> qemu/kvm underneath. It simply maps the FUSE requests on corresponding= >> VFS services in the UML kernel. >> >> =20 >>> Does it preserve ownership? >>> =20 >> Yep. >> >> =20 >>> You still can't do things as root I take it which is problematic. >>> =20 >> At least my default config does not prevent running qemu-img map as ro= ot >> and then performing a classic "mount -o loop" on the partitions it >> provides. Or what do you mean? >> =20 >=20 > You need user_allow_other set in /etc/fuse.conf which isn't set by defa= ult. I don't see the need for sharing the mount. Either your are root, then you can do this anyway. Or you are a normal user, and then the vision is that you can do everything you need for setting up and maintaining guest images without ever becoming root. We aren't completely there yet. E.g., the Linux kernel blocks mknod of devices although FUSE filesystems are automatically mounted with nodev. But that should be fixable as well. I think this approach already covers the majority of use cases of manipulating guest images as normal user, and that without requiring more than 500 lines of code here plus the external mountlo tool. Jan --------------enig176C7D58BEADFF7AC9B616BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkusaWIACgkQitSsb3rl5xQ/HgCfVGTXk9JZWF/xa5jDHebZXjex moAAni5+w7uQIY/3xQ3jMgnpiFEpyFsF =8ZWS -----END PGP SIGNATURE----- --------------enig176C7D58BEADFF7AC9B616BB--