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

[Anthony Liguori]

Andre Przywara wrote:
> Laurent Vivier wrote:
>
> > 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.

I recently was poking around at the loop device and discovered that it 
had a plugging xfer ops to allow for encrypted loop devices.  My initial 
analysis was that by simply adding a couple of operations to that 
structure (such as map_sector and get_size), you could very easily write 
a kernel module that registered a set of xfer ops that implemented QCOW 
support.

Of course, this would all be kernel code.  The best solution would be a 
proper userspace block device.  I think it's a pretty reasonable 
stop-gap though (that wouldn't be very difficult to get merged upstream).

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

You could only do something read-only with device mapper.  dm-userspace 
was an effort to try and work around that with a userspace daemon but it 
didn't move upstream as quickly as we would have liked.

Regards,

Anthony Liguori

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