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 10:57:07 +0200

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.

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.


Alex



reply via email to

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