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

["Andre Przywara" <andre.przywara@amd.com>]

Laurent Vivier wrote:
> Le vendredi 25 janvier 2008 à 09:18 -0600, Anthony Liguori a écrit :
>> Laurent Vivier wrote:
>>> Hi,
>>>
>>> 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.

Regards,
Andre.

-- 
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