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
|
Home