| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] PV drivers on HVM using Xen 4.1.1
On Thu, 2011-10-27 at 13:56 +0100, Alex Bligh wrote:
> I think I've found one reason why we can't get PV block drivers on HVM
> domUs working on Xen 4.1.1 - whether we use a pvops or a xenlinux
> domU kernel.
>
> We are using a line like:
>
> disk = [ "tap:aio:/tmp/centos-pvd.img,xvda,w" ]
>
> We are using effectively a standard 3.0 kernel. Config options including
> the word XEN are below.
>
> We do not see blktapctrl starting in Xen 4.1.1 dom0, but it does
> start in Xen3.
Are you changing dom0 kernel as well as hypervisor when you say "3" and
"4.1.1" or is the dom0 kernel constant?
> In fact as far as I can tell the Ubuntu Xen4 package
> does not contain blktapctrl at all (which would explain why it doesn't
> start). Do we need this?
AFAIK tap:aio: usually requires blktap (both kernel side and userspace).
There is also a block backend in qemu which can be by xl used under some
circumstances when blktap is not available but the same is not true of
xend.
> It has been suggested that we don't need this, but we do need a kernel
> module that provides blktap.
>
> http://www.vr.org/knowledgebase/1112/Xen-Paravirt-Ops.html
>
> suggests these might be queued for the non-existent "2.6.40", but
> it's suggested these aren't in 3.0.
>
> http://wiki.xensource.com/xenwiki/XAPI_on_debian
>
> suggests there are dmks modules available, but that blktap is currenly
> only 32 bit. Can that be correct?
XCP (from whence that blktap version comes) is only developed/test using
32 bit. Taht's not to say 64 bit doesn't work, but it might not.
> Isn't this what blkback does?
blkback can only export raw block devices to guests.
blktap can be used to export more "structured" image types, such as vhd.
A raw img like you have cannot be directly handled by blkback (since it
is a file and not a block device). You can consider it a dengenerate
case of a structured image so blktap can deal with it. A raw image can
also be mounted with a loop back device which itself can be exported via
blkback. Some toolstacks (xend) can do this automatically (but won't for
a tap:aio: AFAIK) but xl will not.
Unfortunately blktap (at least in its current form) is not suitable to
go upstream. If someone wants to step up and implement the blkring
protocol in userspace (i.e. do away with the kernel component by merging
that bit into the tapdisk process itself) then that would be very much
appreciated.
> domU config is below. Note the very same VM with the same config file
> works just fine on xen 3.3.1. This domU is Centos 2.6.18 with
> unmodified_drivers xenlinux type kernel (as supplied by Centos). Every
> other kernel we've tried does the same, save that modern ones also
> unplug the emulated devices so no disks appear as well.
>
> PV nics work fine.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home