[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] DomU PV network problems

  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Sauro Saltini <saltini@xxxxxx>
  • Date: Fri, 10 Sep 2010 13:35:16 +0200
  • Delivery-date: Fri, 10 Sep 2010 04:35:01 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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 :
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 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 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 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 ?
4) Is xen-4.0.1 / really suitable for production use ? Or I'd be better using 3.4.1 with 2.6.18 ?

Many thanks in advance to all.


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

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.

you don't need this as well. It's not used on PV domU.

I'm pretty sure you don't need those two lines, since PV domUs use "vfb=..."

Pinging from testing domU ( 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 tell, length 28
14:17:29.922304 ARP, Ethernet (len 6), IPv4 (len 4), Reply
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.