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