On 6 Aug 2015, at 15:34, Martin Lucina <martin@xxxxxxxxxx> wrote:
On Wednesday, 05.08.2015 at 18:45, Dave Scott wrote:
On 5 Aug 2015, at 19:33, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
Reducing the dependency on qemu is very desirable given the recent rash
of security issues from the codebase as well.
There's another alternative method which was used in the form of the
'blktap' driver. This redirects block traffic to a userspace daemon
that can then write to (e.g.) a VHD or VMDK file. Blktap also doesnt
require using up a loop device.
Blktap's been through a series of rewrites though, and never seems to
have been upstreamed even though it's the default storage mode used
in XenServer. CCing Dave Scott: do you know if using blktap is a viable
option these days?
I think George Dunlap (cc:d) has been adding support to the Xen build for
the XenServer-derived blktap:
http://lists.xen.org/archives/html/xen-devel/2015-04/msg01853.html
I’ve not had a chance to try it myself, but it ought to be pretty good. What
do you think, George?
Note: the vhd support in blktap/tapdisk is well tested, but it doesn’t
support vmdk IIRC (or at least if it does it won’t be anywhere near as well
tested). It supports raw format too, which is equivalent to using a loop
device + blkback.
I'm not familiar with the underlying protocols involved so the answers to
these might be obvious, but I have a couple of questions:
1) The blkback+qdisk setup is already talking to a userspace daemon (QEMU).
It follows that it should be easy to swap out QEMU for a single-purpose
daemon which does nothing except provide the same qdisk interface to a
bunch of raw files, right?
2) Is there any technical reason why the Linux blkback driver requires a
block (loop) device and cannot access a raw format image file directly? For
example, the in-kernel nfsd can access files, so I don't understand why
blkback can't.
