2.6.38-rc4 dom0 kernel

[M A Young]

I have a new kernel (2.6.38-0.rc4.git3.1.xendom0.fc15) at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2833991 . This uses the 
Konrad's devel/next-2.6.38 branch (from 
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git ), as I have been 
having trouble which Jeremy's xen/next-2.6.38 branch.
It has the revised xen-netback patches, so doesn't need the hack to 
/etc/sysconfig/modules/xen.modules that the previous kernel needed to 
avoid backtraces (indeed the hack stops xen-netback loading with this 
kernel as the netback_kthread parameter has been dropped).

 	Michael Young

[W. Michael Petullo]

>  I have a new kernel (2.6.38-0.rc4.git3.1.xendom0.fc15) at 
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2833991 . This uses the 
>  Konrad's devel/next-2.6.38 branch (from 
>  http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git ), as I have been 
>  having trouble which Jeremy's xen/next-2.6.38 branch.
>  It has the revised xen-netback patches, so doesn't need the hack to 
>  /etc/sysconfig/modules/xen.modules that the previous kernel needed to 
>  avoid backtraces (indeed the hack stops xen-netback loading with this 
>  kernel as the netback_kthread parameter has been dropped). 
I just booted 2.6.38-0.rc4.git3.1.xendom0.fc15 on
xen-4.1.0-0.1.rc4.fc14.x86_64. I end up with the xen_netback kernel
module loaded:

$ lsmod | grep net
xen_netback            24607  0 [permanent]

I'm not sure if this is what you were refering to by "indeed the hack
stops xen-netback loading..."

It also seems that my DomU does not have its network facilities set up. I
don't end up with a vifX.Y device on Dom0. This is different behavior
than what was provided by Michael's previous kernel package. With
the previous one, DomU would have network connectivity after booting,
although eventually it would seem to break.

-- 
Mike

:wq

[M A Young]

On Fri, 11 Feb 2011, W. Michael Petullo wrote:

>  I just booted 2.6.38-0.rc4.git3.1.xendom0.fc15 on
>  xen-4.1.0-0.1.rc4.fc14.x86_64. I end up with the xen_netback kernel
>  module loaded:
>
>  $ lsmod | grep net
>  xen_netback            24607  0 [permanent]
>
>  I'm not sure if this is what you were refering to by "indeed the hack
>  stops xen-netback loading..." 
The latest dom0 kernel and the latest xen rc should work unaltered. The 
hack I referred to was an edit to a file from the xen rc to get the 
previous dom0 kernel working.

 	Michael Young

[W. Michael Petullo]

> > I just booted 2.6.38-0.rc4.git3.1.xendom0.fc15 on
> > xen-4.1.0-0.1.rc4.fc14.x86_64. I end up with the xen_netback kernel
> > module loaded:
> >
> > $ lsmod | grep net
> > xen_netback            24607  0 [permanent]
> >
> > I'm not sure if this is what you were refering to by "indeed the hack
> > stops xen-netback loading..." 
 
>  The latest dom0 kernel and the latest xen rc should work unaltered.
>  The hack I referred to was an edit to a file from the xen rc to get
>  the previous dom0 kernel working. 
I've looked more into my trouble, and it seems that "xl" does not want
to play nicely with the vif-route script.

First, the udev subsystem executes vif-setup after Xen creates the
vif device. For some reason, this script does not have $script defined
and so it defaults to vif-bridge. Once I changed it to run vif-route
things went further. I'm not entirely sure how $script is supposed to
be set, but it worked fine with xm.

Next, vif-route did not pick up $ip from my domain configuration's "vif =
[ 'ip=w.x.y.z' ]." When using xm, vif-route would find $ip set properly
and would create a route based on its value.

Networking between Dom0 and DomU works with a modified vif-setup script
and a manually added route. Once I get it going, networking seems to be
stable.

-- 
Mike

:wq

[Pasi Kärkkäinen]

On Sun, Feb 13, 2011 at 11:17:00AM -0600, W. Michael Petullo wrote:
>  >> I just booted 2.6.38-0.rc4.git3.1.xendom0.fc15 on
>  >> xen-4.1.0-0.1.rc4.fc14.x86_64. I end up with the xen_netback kernel
>  >> module loaded:
>  >>
>  >> $ lsmod | grep net
>  >> xen_netback            24607  0 [permanent]
>  >>
>  >> I'm not sure if this is what you were refering to by "indeed the hack
>  >> stops xen-netback loading..."
>   
>  > The latest dom0 kernel and the latest xen rc should work unaltered.
>  > The hack I referred to was an edit to a file from the xen rc to get
>  > the previous dom0 kernel working.
>  
>  I've looked more into my trouble, and it seems that "xl" does not want
>  to play nicely with the vif-route script.
>  
>  First, the udev subsystem executes vif-setup after Xen creates the
>  vif device. For some reason, this script does not have $script defined
>  and so it defaults to vif-bridge. Once I changed it to run vif-route
>  things went further. I'm not entirely sure how $script is supposed to
>  be set, but it worked fine with xm.
>  
>  Next, vif-route did not pick up $ip from my domain configuration's "vif =
>  [ 'ip=w.x.y.z' ]." When using xm, vif-route would find $ip set properly
>  and would create a route based on its value.
>   
I think you should report these issues to xen-devel mailinglist!

-- Pasi

>  Networking between Dom0 and DomU works with a modified vif-setup
> script
>  and a manually added route. Once I get it going, networking seems to be
>  stable.
>  
>  -- 
>  Mike
>  
>  :wq
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen