qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access
Date: Fri, 26 Mar 2010 08:59:24 +0100	[thread overview]
Message-ID: <4BAC695C.5050002@web.de> (raw)
In-Reply-To: <4BABE98F.1050506@codemonkey.ws>

[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]

Anthony Liguori wrote:
> On 03/25/2010 05:27 PM, Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>   
>>> On 03/25/2010 04:46 PM, Jan Kiszka wrote:
>>>     
>>>> Anthony Liguori wrote:
>>>>
>>>>       
>>>>> On 03/25/2010 12:52 PM, Jan Kiszka wrote:
>>>>>
>>>>>         
>>>>>> This adds the "map" subcommand to qemu-img. It is able to expose the
>>>>>> 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 the
>>>>>> image or loop-back mount exiting ones. Using the great mountlo tool
>>>>>> 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: Partition
>>>>>> scanning is done via recent libblkid (I used version 2.17.1). If this
>>>>>> library is not available, only the disk file is provide. Fortunately,
>>>>>> mountlo can do partition scanning as well ("-p n") to work around
>>>>>> this.
>>>>>>
>>>>>> Moreover, libfuse>= 2.8 and a host kernel>= 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=FileSystems#Mountlo
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2] http://sourceforge.net/projects/fuse/files/mountlo/
>>>>>> [3] http://www.saulsbury.org/software/virtualization.html
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka<jan.kiszka@web.de>
>>>>>>
>>>>>>
>>>>>>            
>>>>> This has been proposed quite a few times.
>>>>>
>>>>> In fact, I wrote something like this prior to implementing qemu-nbd.
>>>>>
>>>>> 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.
>>>>>
>>>>>          
>>>> You don't, see mountlo.
>>>>
>>>>        
>>> That definitely changes things.  I assume it just uses libe2fs et al to
>>> display filesystem contents?
>>>      
>> 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 any
>> qemu/kvm underneath. It simply maps the FUSE requests on corresponding
>> VFS services in the UML kernel.
>>
>>   
>>> Does it preserve ownership?
>>>      
>> Yep.
>>
>>   
>>> You still can't do things as root I take it which is problematic.
>>>      
>> At least my default config does not prevent running qemu-img map as root
>> and then performing a classic "mount -o loop" on the partitions it
>> provides. Or what do you mean?
>>    
> 
> You need user_allow_other set in /etc/fuse.conf which isn't set by default.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  reply	other threads:[~2010-03-26  8:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-25 17:52 [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access Jan Kiszka
2010-03-25 20:58 ` Anthony Liguori
2010-03-25 21:46   ` Jan Kiszka
2010-03-25 22:04     ` Anthony Liguori
2010-03-25 22:27       ` Jan Kiszka
2010-03-25 22:54         ` Anthony Liguori
2010-03-26  7:59           ` Jan Kiszka [this message]
2010-03-28 11:02 ` Christoph Hellwig
2010-03-29  7:46   ` Jan Kiszka
2010-03-29  8:57     ` Alexander Graf
2010-03-29  9:37       ` Jan Kiszka
2010-03-29  9:39         ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BAC695C.5050002@web.de \
    --to=jan.kiszka@web.de \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).