Re: [Xen-users] DomU PV network problems

[Sauro Saltini <saltini@xxxxxx>]

Hello, some news about my problem:

1) I've removed the wrong options from my config as suggested, without 
any result.
2) Then I've decided to try with the new xen 4.0.1 tarball... 
downloaded, and recompiled everything
3) at this point I've had a lot of problems to boot 2.32.21-dom0 
(compiled directly from tarball, without changing any kernel option), 
xen started but hanged with unhandled page fault as soon as kernel 
booting begun.
4) I've downloaded the example config file suggested on xen.org from :
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.32.21-pvops-dom0-xen-stable-x86_64
5) built the new kernel with this config, and finally booted into dom0
6) rebuilt the same kernel disabling the debug options under Kernel 
Hacking and still can boot Dom0.
Now I've a functional 4.0.1 system with 2.4.32.21 dom0.

The good news are that the networking problem has gone ... now I can 
reach the external LAN from a DomU via the "firewall" PV DomU.
Looking at the sources of netback.ko (the supposed guilty part) I've 
found in fact many changes (quite a rewrite).
Now I'm facing a completely different problem... with migration (even 
save / restore) of PV guests.
While I can save / restore / migrate HVM domUs without any problems, the 
same operations on PV guests (using the same 2.6.32.21 dom0 kernel with 
front drivers added) very often (but not alwas) result in an crashed 
domU after resuming.
Sometimes I can see a kernel panic connecting to the resumed domU 
console, but most of the times simply the console is stuck (can connect 
and disconnect from console but no output).
The only thing I can do when this happens is xm destroy the domU.

The whole point of my intended setup is HA, so migrating domU's is a 
fundamental part !
My questions are :
1) how can I debug this problem ?
2) said that the suggested config for 2.4.32.21 kernel from 
pasik.reactio.net "contains some debug options" and cannot be used in 
production due to performance reasons, it's correct to turn off the 
kernel debugging options under "kernel hacking" or there are some other 
options to set for production use.
3) where can I find a working "production" config for 2.4.32.21 ?
4) Is xen-4.0.1 / 2.4.32.21 really suitable for production use ? Or I'd 
be better using 3.4.1 with 2.6.18 ?
Many thanks in advance to all.

Sauro.

SHC snc
via Cadore 26, 20135 Milano, Italia
Tel: +39 02 54123888
Mobile: +39 335 1364759
Fax: +39 02 54011111
Email:saltini@xxxxxx


On 08/09/2010 22:44, Fajar A. Nugraha wrote:
> On Wed, Sep 8, 2010 at 7:25 PM, Sauro Saltini<saltini@xxxxxx>  wrote:
>    
> > vif=[ 'type=paravirtual, bridge=br0, mac=00:16:3e:00:00:02',
> >       'type=paravirtual, bridge=br1, mac=00:16:3e:00:00:20' ]
> >      
> you don't need "type=paravirtual", just remove it. Where did you find
> "type=paravirtual" anyway? I've never seen it on any of the examples.
>
>    
> > boot='c'
> >      
> you don't need this as well. It's not used on PV domU.
>
>    
> > sdl=0
> > vnc=0
> >      
> I'm pretty sure you don't need those two lines, since PV domUs use "vfb=..."
>
>    
> > Pinging 192.168.99.202 from testing domU (10.0.0.102) doesn't work, and
> > tcpdump -nvvi on dom0 (both listening on vifx.y or bridge) gives (every 5 to
> > 10  seconds):
> > ....
> > 14:17:29.922210 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> > 192.168.99.202 tell 192.168.99.88, length 28
> > 14:17:29.922304 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.99.202
> > is-at 00:09:6b:89:d0:8a, length 46
> > ....
> >
> > but no icmp traffic at all !
> >      
> At this point I'd start with using known-good setup first, since it
> can save a lot of time. Try using 2.6.34 + the patch I mentioned
> earlier for both dom0 and PV domU.
>
>    
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users