Re: where to find blktap2 kernel module

[Ian Campbell <Ian.Campbell@citrix.com>]

On Fri, 2012-04-06 at 22:24 +0100, Tim Wood wrote:
> In xen 4.0.X I was able to write custom blktap2 drivers as a nice way
> to intercept VM disk traffic.  I'm now trying to take a step up to xen
> 4.1.2 and find that blktap2 doesn't seem to be supported anymore, or
> at least it requires a kernel module which I'm not sure where to
> find.  Is blktap2 still in use, or is there an entirely different way
> I should be approaching this?
> 
> 
> Previously I could run commands like:
> 
> 
> tapdisk2 -n tap:aio:/home/twood/vms/testdisk.img 
> 
> 
> the new tapdisk2 doesn't support that interface anymore,

What do you mean? I don't think the tap interface has changed (but I'm
not sure). In any case I'm pretty sure the functionality should be there
even if the command line has changed.

>  but it seems like the correct approach is now:
> 
> 
> xm block-attach 0 tap2:aio:/path/disk.img xvda w 0 
> Error: ('create', '-aaio:/path/disk.img') failed (55808 blktap kernel
> module not installed )

I think this ultimately turns into the same sort of command as the one
above.

> What is the "proper" way of getting the blktap kernel module
> installed?  I found this:
> http://packages.debian.org/sid/blktap-dkms

Unfortunately the blktap2 module is not something which can be
upstreamed.

The DKMS package is probably a good bet for now. The other alternative
is to switch to a slightly older kernel which has the blktap2 driver in
it, for example the 2.6.32 based xen.git kernel tree or one of the
classic Xen forward ports.

You mentioned writing your own blktap modules so the qemu-supplied qdisk
backend is probably not much use to you. This is used by the "xl"
toolstack by default when blktap is not present, but isn't supported by
xm and doesn't allow for custom modules .

I'm actually quite interested in the fact that you are writing custom
blktap modules -- are you able to share the details?

> but couldn't get it to actually install.

Please share the details so we can try and figure out why.

> In any case, it seems unlikely that is the best way to go.

Sadly it is, for now.

Long term someone is working on a "blktap3" which is fully userspace and
so doesn't require a kernel module. We hope to see this for 4.3. For 4.2
it looks like we'll be sticking with the qdisk backend.

Ian.