Hello,
Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops kernel and libvirt. However I am having some problems with networking... after initial installation with netinstall image in hvm mode, when I transform the vm in xen pv (via pygrub with the current ubuntu kernel), networking startEd to act weird...
Basically I'm not using a network script from xen. I define a bridge (manually or via libvirt, the result is the same) and I use vif-bridge to connect the vif to it. But now the weird part comes: I can communicate from domU to dom0, but not the other way around, unless I keep a ping running from domU to dom0... That's right, weird... while trying the ping from dom0 to domU, I used tcpdump both on the bridge, on the vif and on the eth0 in the domU. The arp packets never get to domU, but they appear both in the bridge and the vif sniff's...
Here is the bridge:
ifconfig virbr0
virbr0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff
inet addr:192.168.120.254 Bcast:192.168.120.255 Mask:255.255.255.0
inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:226 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:952 (952.0 B) TX bytes:13953 (13.9 KB)
brctl show
bridge name bridge id STP enabled
interfaces
virbr0 8000.feffffffffff no vif5.0
tcpdump -i virbr0 -vv -n
tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size 96 bytes
01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 1, length 64
01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 2, length 64
01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 3, length 64
01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 4, length
64
01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 5, length 64
01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 6, length 64
01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 7, length 64
01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length
28
01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 8, length 64
01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
tcpdump -i vif5.0 -vv -n
tcpdump: WARNING: vif5.0: no IPv4 address assigned
tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture size 96 bytes
01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:27.958360 ARP,
Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
Forwarding and iptables don't seem to be the problem, because if I initiate a ping from domU (at the same time as the failing one from dom0), the ping in dom0 starts to work. As soon as I stop the ping in domU, the one in dom0 starts failing again...
Is anyone having the same problem? Is this a bug in the kernel? In dom0 or domU?
Thanks in advance,
Luís
