qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access
Date: Fri, 26 Mar 2010 08:59:24 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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<address@hidden>
>>>>>>
>>>>>>
>>>>>>            
>>>>> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]