WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PV drivers on HVM using Xen 4.1.1

To: Alex Bligh <alex@xxxxxxxxxxx>
Subject: Re: [Xen-devel] PV drivers on HVM using Xen 4.1.1
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 27 Oct 2011 15:10:45 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 27 Oct 2011 07:18:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AA9CBD34E1D59F9039BABF9F@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <A853EEFF3A385ED3FA09E5F0@xxxxxxxxxxxx> <1319723089.9436.124.camel@xxxxxxxxxxxxxxxxxxxxxx> <AA9CBD34E1D59F9039BABF9F@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-10-27 at 15:04 +0100, Alex Bligh wrote:
> Ian,
> 
> --On 27 October 2011 14:44:49 +0100 Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> 
> 
> >> 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?
> 
> No, the Xen3 kernel is 2.6.18 Centos, and the Xen 4 kernel is 3.0
> Ubuntu Oneiric.

OK, that is important information now that Xen is not supplied with a
particular kernel.

> >>  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.
> 
> We are using xl (though have tried xend).

Good to know.

> > 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.
> 
> OK. The idea here is a production xen4.1 system, so "might not work"
> sounds like a bad idea :-)
> 
> >> Isn't this what blkback does?
> >
> > blkback can only export raw block devices to guests.
> 
> We will in production use raw block devices, so that's ok. We were
> just using files for testing. Is the same restriction there is
> Xen3.3, because it works there (possibly for the reason below).

The 2.6.18 kernel has blktap.ko and 3.0 does not, which is going to be a
big factor. blkback.ko is in both so you should be ok. For testing you
could try using loopback like Stefano suggests.

> > 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.
> 
> I think xl /must/ be doing this, or it is difficult to explain the
> behaviour below.

Indeed, I can't explain it either. I think I would expect xl to fall
back to the qemu based backend if blktap wasn't available. I _think_
that functionality was backported to the qemu-xen in 4.1, but I'm not
sure.

> We discovered Ubuntu's Xen 4.1 hypervisor package does not contain
> blktapctrl, so we copied that across from a build from source, plus some
> libraries, and did an mknod on /dev/xen/blktap0 (which it appeared to want
> to open). pvdrivers then appeared in the guest. But we then reversed
> everything we'd done (we think), and pvdrivers continued to appear. We are
> reinstalling to find out exactly what it was that changed.
> 
> I must admit to remaining almost totally confused as to how this is
> meant to work, but thanks for your help thus far!
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel