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

[Jan Kiszka <jan.kiszka@web.de>]

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

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?

[ Wow - just typed "qemu-ext2" into Big Brother's search bar and found
the very same mail I'm just replying to. That's fast. ]

> 
> IMHO the best move to do here (Anthony's idea) is to somehow get the full block layer into a library, move it out of qemu into a separate project and allow other tools in there too.
> 
> That move would vastly improve the situation of distributions too. I don't want to have a qemu-img each coming from the Xen, KVM and Qemu packages. One is enough :-). And it could enable block layer experienced people to be the project maintainers, making that more valuable.
> 

Full ack.

Jan


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