Re: Eliminating the need for qemu for file images on Xen unikernels

  • From: George Dunlap <george.dunlap@xxxxxxxxxx>
  • To: Dave Scott <Dave.Scott@xxxxxxxxxx>, Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Mon, 10 Aug 2015 10:32:38 +0100

On 08/05/2015 07:45 PM, 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?

From an objective perspective, I don't think there are more likely to be
security issues in the qdisk backends than in blktap; I would expect
both to have similar amounts of complexity. Switching *might* be better
from a marketing perspective, if people began to think of qemu as
unreliable across the board, but I rather doubt people in general will
know that much about the internals to connect qdisk with qemu.

There is certainly something to be said for having a much smaller codebase.

One disadvantage of blktap is that at the moment (as I understand it) it
relies on a kernel module, even if you're not primarily using the
in-kernel datapath. Felipe seemed to think that this was mainly to have
a central place to allocate minor numbers for the device node; but that
still it would take some massive re-architecting to get the code to work
without it.

Also, just as an FYI, you need some patches to get the blktap on get hub
to compile and work.

With my CentOS / xen.git hat on, having more people acting as a
"downstream" to blktap would be really helpful. :-)

I'm on holiday starting tomorrow until 27 August; let me know by EOD
today if you're keen and I can see about pushing drafts of the
blktap.git, xen.git, and raisin.git patches required to get stuff working.

-George


Other related posts: