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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] qemu-img: add FUSE-based image access
Date: Mon, 29 Mar 2010 11:39:17 +0200

On 29.03.2010, at 11:37, Jan Kiszka wrote:

> Alexander Graf wrote:
>> On 29.03.2010, at 09:46, Jan Kiszka wrote:
>> 
>>> Christoph Hellwig wrote:
>>>> On Thu, Mar 25, 2010 at 06:52:59PM +0100, 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).
>>>> Is there a good reason to throw this into qemu-img instead of making
>>>> a separate qemu-fuse or similar tool?  It's doing something quite
>>>> different than the rest of qemu-img.
>>>> 
>>> qemu-img is the swiss knife for QEMU disk image manipulation (like git
>>> is for everything around a git repository). So, IHMO, mapping the image
>>> content into the host filesystem for further manipulation with standard
>>> tools belongs to this.
>>> 
>>> If the "map" thing works out for most users, I could even imagine some
>>> helper sub-command "mount" that encapsulates map and mountlo (or some
>>> other unprivileged mounting mechanism). This should make it easier for
>>> users to explore all possibilities they have when working with disk images.
>> 
>> We also have a tool called "qemu-ext2" lying around that allows you to 
>> explore ext2 based file system contents in any qemu block layer supported 
>> backend.
> 
> "we" == SUSE?

"we" == "SUSE Studio" (in fact, Nat wrote it). It is GPL'ed, just not released 
yet. As soon as there will be a separate project with a broader scope than just 
qemu for the block layer, I'll happily invest the time to clean it up for 
upstream submission.


Alex



reply via email to

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