[Top][All Lists]

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

Re: [Qemu-devel] [PATCH][RFC] To mount qemu disk image on the host

From: Andre Przywara
Subject: Re: [Qemu-devel] [PATCH][RFC] To mount qemu disk image on the host
Date: Fri, 25 Jan 2008 20:52:59 +0100
User-agent: Thunderbird (X11/20070728)

Laurent Vivier wrote:
Le vendredi 25 janvier 2008 à 09:18 -0600, Anthony Liguori a écrit :
Laurent Vivier wrote:

this patch allows to mount qemu disk images on the host.

Sorry, I didn't see you did a similar work 19 months ago.
Note, the general problem with this approach is that mounting a NBD device locally with write access can lead to dead locks. If you look through the mailing list archives, you'll find a number of conversations on the topic.
I sometimes ago was also working on a nbd implementation for qcow-images, but I came to the same deadlock conclusion. (At least theoretically, I didn't finish this as I ran first into debugging problems and secondly out of time). But IMHO this only applies to localhost mounts, real network mounting should work (this is actually not different from "native" nbd). Perhaps one could use a qemu instance for the server part ;-) BTW: nbd-server should be quite portable, I once had it run on an ancient PA-RISC machine under HP-UX 10.20.

What I'm wondering is how loop and device mapper can work ?
I shortly evaluated the loop device idea, but came to the conclusion that this not so easy to implement (and would require qcow code in the kernel). I see only little chance for this go upstream in Linux and maintaining this out-of-tree is actually a bad idea. If you think about deferring the qcow code into userland, you will sooner or later run into the same deadlock problems as the current solution (after all this is what nbd does...)

I have implemented a clean device-mapper solution, the big drawback is that it is read-only. It's a simple tool which converts the qcow map into a format suitable for dm-setup, to which the output can be directly piped to. I will clean up the code and send it to the list ASAP. Read/write support is not that easy, but maybe someone can comment on this idea: Create a sparse file on the host which is as large as the number of all still unallocated blocks. Assign these blocks via device mapper in addition to the already allocated ones. When unmounting the dm device, look for blocks which have been changed and allocate and write them into the qcow file. One could also use the bmap-ioctl to scan for non-sparse blocks. This is a bit complicated, but should work cleanly (especially for the quick fsck or file editing case). If you find it worth, I could try to implement it.


Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

reply via email to

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