On Wed, Jun 09, 2010 at 05:47:42AM -0700, Boris Derzhavets wrote:
> I was able to virt-install F13 PV DomU in nographics mode under Xen
> 4.0.1-rc2-pre (2.6.32.15 pvops c2cb3df04eb3ff68d0de102b2acacc9b8616e659)
> at the point of extracting data from Apache mirror at Dom0 on top of
> Ubuntu 10.04 ( text console mode message)
> -------------------------------------------------
> 2 extracting cpio errors. Bad Magic
> -------------------------------------------------
> However, virt-install proceeds further to promt "set up VNC at DomU"
> and completed successfully.
> VNC mode cannot pass through this extractions. It just hangs.
>
Yeah, there's something weird going on..
During the weekend I *think* I was successfully able to install guests
when they didn't have vfb set up at all.. but when I set up vfb (ie. used
virt-manager)
the VM's started acting weird.. network problems, and problems in general,
VM's freezing..
I haven't had time to confirm that yet..
-- Pasi
> Boris.
>
> --- On Mon, 6/7/10, Pasi Kärkkäinen <pasik@xxxxxx> wrote:
>
> From: Pasi Kärkkäinen <pasik@xxxxxx>
> Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with
> pvops kernel 2.6.32.15
> To: "Boris Derzhavets" <bderzhavets@xxxxxxxxx>
> Cc: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>,
> xen-devel@xxxxxxxxxxxxxxxxxxx, luis.silva@xxxxxxxxxxxxx,
> xen-users@xxxxxxxxxxxxxxxxxxx
> Date: Monday, June 7, 2010, 3:55 AM
>
> On Sun, Jun 06, 2010 at 11:54:11AM -0700, Boris Derzhavets wrote:
> > Virt-install hangs attempting to retrieve updates.img from Apache
> Mirror
> > setup at Dom0
> > with kernel 2.6.32.15
> > It doesn't happen with 2.6.32.10 (12,14 final).
> > Environment Xen 4.0 Dom0 on top Ubuntu 10.04 Server. Libvirt is
> 0.8.0 .
> > Attempting to virt-install F13 PV DomU in vnc mode.
> >
> > I believe that builds are consistent.
> > Runtime behavior is the same for .10, .14, .15. Seems to be
> communicating
> > problem between DomU and Dom0 during HTTP download.
> >
>
> I'm seeing PV domU network issues aswell.. when running Xen 4.0.0 on
> Fedora 13.
> I'll have to dig more into it..
>
> -- Pasi
>
> > Boris.
> >
> > --- On Sun, 6/6/10, Jeremy Fitzhardinge <[1]jeremy@xxxxxxxx> wrote:
> >
> > From: Jeremy Fitzhardinge <[2]jeremy@xxxxxxxx>
> > Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen
> 4.0 with
> > pvops kernel 2.6.32.15
> > To: "Boris Derzhavets" <[3]bderzhavets@xxxxxxxxx>
> > Cc: [4]luis.silva@xxxxxxxxxxxxx,
> [5]xen-devel@xxxxxxxxxxxxxxxxxxx,
> > [6]xen-users@xxxxxxxxxxxxxxxxxxx
> > Date: Sunday, June 6, 2010, 12:43 PM
> >
> > On 06/06/2010 03:19 AM, Boris Derzhavets wrote:
> > > Network issues when working with DomUs in 2.6.32.14 and finally
> been
> > > fixed,
> > > seem to appear again in 2.6.32.15. Reverting to back to
> xen/stable -
> > > 2.6.32.10
> > > works as a fix again.
> > >
> >
> > There are no substantial differences between 2.6.32.14 and .15.
> If
> > there are any differences in behaviour between them, then I'd
> suspect
> > some inconsistency from boot to boot, or in your kernel build
> process.
> >
> > J
> >
> > >
> > > Boris
> > >
> > > --- On *Thu, 6/3/10, Luís Silva
> /<[1][7]luis.silva@xxxxxxxxxxxxx>/*
> > wrote:
> > >
> > >
> > > From: Luís Silva <[2][8]luis.silva@xxxxxxxxxxxxx>
> > > Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with
> xen 4.0
> > > with pvops kernel
> > > To: "Boris Derzhavets" <[3][9]bderzhavets@xxxxxxxxx>
> > > Cc: "Jeremy Fitzhardinge" <[4][10]jeremy@xxxxxxxx>,
> > > [5][11]xen-devel@xxxxxxxxxxxxxxxxxxx,
> [6][12]xen-users@xxxxxxxxxxxxxxxxxxx
> > > Date: Thursday, June 3, 2010, 6:20 AM
> > >
> > > Hello,
> > >
> > > Thanks for the suggestion, xen/stable works ok for me. Only
> > > problem is that I have to disable offload do get dhcp to
> work on
> > > domU, but the problem I described before doesn't exist in
> this
> > > kernel. Later today I'm going to try a previous build I
> have based
> > > on stable-2.6.32.x (2.6.32.13) to check if it already had
> this
> > > problem or not and I'll post the results.
> > >
> > > Luís
> > >
> > > On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:
> > >> Could you,please, build and try 2.6.32.10 ( xen/stable) ?
> > >>
> > >> Boris.
> > >>
> > >> --- On *Wed, 6/2/10, Luís Silva
> > **/<[7][13]luis.silva@xxxxxxxxxxxxx>/*
> > >> wrote:
> > >>
> > >>
> > >> From: Luís Silva <[8][14]luis.silva@xxxxxxxxxxxxx>
> > >> Subject: [Xen-users] Re: [Xen-devel] ARP problems with
> xen
> > >> 4.0 with pvops kernel
> > >> To: "Jeremy Fitzhardinge" <[9][15]jeremy@xxxxxxxx>
> > >> Cc: [10][16]xen-devel@xxxxxxxxxxxxxxxxxxx,
> > [11][17]xen-users@xxxxxxxxxxxxxxxxxxx
> > >> Date: Wednesday, June 2, 2010, 2:53 PM
> > >>
> > >> Hello,
> > >>
> > >> On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge
> wrote:
> > >>> On 06/02/2010 01:47 AM, Luís Silva wrote:
> > >>> > Hello,
> > >>> >
> > >>> > I'm using the latest stable-2.6.32.x. I already
> tried
> > "ethtool -K
> > >>> > <bridge> tx off", but that didn't make any
> difference.
> > Also, this only
> > >>> > happen with pv, in hvm mode all works ok and the
> domU sees
> > the arp
> > >>> > messages...
> > >>>
> > >>> Yes, ARP is a new twist on network problems. I'm
> guessing
> > you're using
> > >>> hvm without stubdoms, which means that its networking
> > originates from
> > >>> qemu within dom0, whereas PV and HVM+stubdom comes
> via
> > netback.
> > >>>
> > >>>
> > >> Yes, when I mentioned hvm I was talking about hvm
> without
> > >> stubdoms. I haven't tried those yet.
> > >>> But aside from that, I'm stumped. Are you running
> any
> > firewalls on
> > >>> either side? Can you try disabling all the offloads
> (tx,
> > rx, gso, tso)
> > >>> on all the relevent interfaces (bridge, netback,
> within the
> > guest) and
> > >>> see if that changes anything?
> > >>>
> > >>> J
> > >>>
> > >>>
> > >>
> > >> Ok, this is the bridge interface:
> > >>
> > >> brctl show
> > >> bridge name bridge id STP enabled
> interfaces
> > >> virbr0 8000.feffffffffff no vif1.0
> > >>
> > >> ifconfig virbr0
> > >> virbr0 Link encap:Ethernet HWaddr
> c2:ef:67:2b:a4:23
> > >> inet addr:192.168.120.254
> Bcast:192.168.120.255
> > Mask:255.255.255.0
> > >> inet6 addr: fe80::c0ef:67ff:fe2b:a423/64
> Scope:Link
> > >> UP BROADCAST RUNNING MULTICAST MTU:1500
> Metric:1
> > >> RX packets:0 errors:0 dropped:0 overruns:0
> frame:0
> > >> TX packets:25 errors:0 dropped:0 overruns:0
> > carrier:0
> > >> collisions:0 txqueuelen:0
> > >> RX bytes:0 (0.0
> > >> B)
> > >> TX bytes:4662 (4.6 KB)
> > >>
> > >>
> > >>
> > >> I'm not using firewall other than the rules defined by
> > >> libvirt. DomU has no firewall and the rules in dom0
> are only
> > >> these (virbr0 is natted to the outside, virbr1 is
> routed. The
> > >> result is the same in either one of them):
> > >>
> > >> sudo iptables -L -n -v
> > >> Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
> > >> pkts bytes target prot opt in out source
> > destination
> > >> 0 0 ACCEPT udp -- virbr1 *
> 0.0.0.0/0
> > 0.0.0.0/0 udp dpt:53
> > >> 0 0 ACCEPT tcp -- virbr1 *
> 0.0.0.0/0
> > 0.0.0.0/0 tcp dpt:53
> > >>
> > >>
> > >> 0 0 ACCEPT udp -- virbr1 *
> 0.0.0.0/0
> > 0.0.0.0/0 udp dpt:67
> > >> 0 0 ACCEPT tcp -- virbr1 *
> 0.0.0.0/0
> > 0.0.0.0/0 tcp dpt:67
> > >> 8 515 ACCEPT udp -- virbr0 *
> 0.0.0.0/0
> > 0.0.0.0/0 udp dpt:53
> > >> 0 0
> > >>
> > >> ACCEPT tcp -- virbr0 * 0.0.0.0/0
> > 0.0.0.0/0 tcp dpt:53
> > >> 0 0 ACCEPT udp -- virbr0 *
> 0.0.0.0/0
> > 0.0.0.0/0 udp dpt:67
> > >> 0 0 ACCEPT tcp -- virbr0 *
> 0.0.0.0/0
> > 0.0.0.0/0 tcp dpt:67
> > >>
> > >> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > >> pkts bytes target
> > >> prot
> > >> opt in out source destination
> > >> 0 0 ACCEPT all -- * virbr1
> 0.0.0.0/0
> > 192.168.121.0/24
> > >> 0 0 ACCEPT all -- virbr1 *
> > 192.168.121.0/24 0.0.0.0/0
> > >> 0 0 ACCEPT all -- virbr1 virbr1
> 0.0.0.0/0
> >
> > >>
> > >> 0.0.0.0/0
> > >> 0 0 REJECT all -- * virbr1
> 0.0.0.0/0
> > 0.0.0.0/0 reject-with icmp-port-unreachable
> > >> 0 0 REJECT all -- virbr1 *
> 0.0.0.0/0
> > 0.0.0.0/0 reject-with icmp-port-unreachable
> > >> 13 3448 ACCEPT all -- * virbr0
> 0.0.0.0/0
> > 192.168.120.0/24
> > >> state
> > >> RELATED,ESTABLISHED
> > >> 16 1374 ACCEPT all -- virbr0 *
> > 192.168.120.0/24 0.0.0.0/0
> > >> 0 0 ACCEPT all -- virbr0 virbr0
> 0.0.0.0/0
> > 0.0.0.0/0
> > >> 0 0 REJECT all -- * virbr0
> 0.0.0.0/0
> > 0.0.0.0/0 reject-with icmp-port-unreachable
> > >> 0 0 REJECT all --
> > >> virbr0
> > >> * 0.0.0.0/0 0.0.0.0/0
> reject-with
> > icmp-port-unreachable
> > >>
> > >> Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
> > >> pkts bytes target prot opt in out source
> > destination
> > >>
> > >>
> > >>
> > >>
> > >> And these are the various offload parameters as set at
> boot:
> > >>
> > >> Offload parameters for virbr0:
> > >> rx-checksumming: on
> > >> tx-checksumming: on
> > >> scatter-gather: on
> > >> tcp-segmentation-offload: on
> > >> udp-fragmentation-offload: on
> > >> generic-segmentation-offload: on
> > >> generic-receive-offload: off
> > >> large-receive-offload: off
> > >>
> > >> Offload parameters for vif1.0:
> > >> rx-checksumming: on
> > >> tx-checksumming: on
> > >> scatter-gather: on
> > >> tcp-segmentation-offload: on
> > >> udp-fragmentation-offload: off
> > >> generic-segmentation-offload: on
> > >> generic-receive-offload: off
> > >> large-receive-offload: off
> > >>
> > >> Offload parameters for eth0:
> > >> rx-checksumming: on
> > >> tx-checksumming: on
> > >> scatter-gather: on
> > >> tcp-segmentation-offload: on
> > >> udp-fragmentation-offload: off
> > >> generic-segmentation-offload: off
> > >> generic-receive-offload: off
> > >> large-receive-offload: off
> > >>
> > >>
> > >>
> > >> To disable all checksuming I run the following
> commands:
> > >> dom0:
> > >>
> > >> sudo ethtool -K virbr0 tx off sg off tso off gso off
> gro off
> > >> sudo ethtool -K vif1.0 tx off sg off tso off gso off
> gro off
> > >>
> > >>
> > >> domU
> > >>
> > >> sudo ethtool -K eth0 tx off sg off tso off gso off gro
> off
> > >>
> > >>
> > >>
> > >> This managed to get all parameter to off in the
> mentioned
> > >> interfaces, but unfortunately the result is the same.
> The arp
> > >> requests get to vif1.0, but not to eth0 on the domU.
> > >>
> > >> sudo tcpdump -i vif1.0 -n -vv arp
> > >> tcpdump: WARNING: vif1.0: no IPv4 address assigned
> > >> tcpdump: listening on vif1.0, link-type EN10MB
> (Ethernet),
> > capture size 96 bytes
> > >> 19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >> 19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >> 19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >> 19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >> 19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >> 19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4),
> Request
> > who-has 192.168.120.1 tell 192.168.120.254, length 28
> > >>
> > >>
> > >>
> > >> I hope this information is enough. If I can provide
> anything
> > >> else to help debug or test, please just ask! ;)
> > >>
> > >> Thanks in advance,
> > >> Luís
> > >>
> > >>> >
> > >>> > Thanks,
> > >>> > Luís
> > >>> >
> > >>> > On Tue, 2010-06-01 at 18:20 -0700, Jeremy
> Fitzhardinge
> > wrote:
> > >>> >> On 06/01/2010 05:38 PM, Luís Silva wrote:
> > >>> >> > 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...
> > >>> >>
> > >>> >> What version of kernel are you using in dom0 and
> domU?
> > There was a
> > >>> >> netback bug which caused problems with dom0<->domU
> > communication, but it
> > >>> >> has been fixed for a while in 2.6.32 (but only
> recently
> > in .31). The
> > >>> >> workaround is to disable tx checksum offload on
> your
> > bridge (ethtool -K
> > >>> >> <bridge> tx off).
> > >>> >>
> > >>> >> J
> > >>> >>
> > >>> >> >
> > >>> >> > 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
> > >>> >> >
> > >>> >> >
> > >>> >> > _______________________________________________
> > >>> >> > Xen-devel mailing list
> > >>> >> > [12][18]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > <mailto:[13][19]Xen-devel@xxxxxxxxxxxxxxxxxxx>
> > <mailto:[14][20]Xen-devel@xxxxxxxxxxxxxxxxxxx>
> > >>> >> > [15][21]http://lists.xensource.com/xen-devel
> > >>> >> >
> > >>> >>
> > >>> >>
> > >>> >> _______________________________________________
> > >>> >> Xen-devel mailing list
> > >>> >> [16][22]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > <mailto:[17][23]Xen-devel@xxxxxxxxxxxxxxxxxxx>
> > <mailto:[18][24]Xen-devel@xxxxxxxxxxxxxxxxxxx>
> > >>> >> [19][25]http://lists.xensource.com/xen-devel
> > >>> >>
> > >>> >>
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> -----Inline Attachment Follows-----
> > >>
> > >> _______________________________________________
> > >> Xen-users mailing list
> > >> [20][26]Xen-users@xxxxxxxxxxxxxxxxxxx
> > >> [21][27]http://lists.xensource.com/xen-users
> > >>
> > >>
> > >
> > >
> > > -----Inline Attachment Follows-----
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > [22][28]Xen-users@xxxxxxxxxxxxxxxxxxx
> > > </mc/compose?to=[23][29]Xen-users@xxxxxxxxxxxxxxxxxxx>
> > > [24][30]http://lists.xensource.com/xen-users
> > >
> > >
> >
> > References
> >
> > Visible links
> > 1. file:///mc/compose?to=[31]luis.silva@xxxxxxxxxxxxx
> > 2. file:///mc/compose?to=[32]luis.silva@xxxxxxxxxxxxx
> > 3. file:///mc/compose?to=[33]bderzhavets@xxxxxxxxx
> > 4. file:///mc/compose?to=[34]jeremy@xxxxxxxx
> > 5. file:///mc/compose?to=[35]xen-devel@xxxxxxxxxxxxxxxxxxx
> > 6. file:///mc/compose?to=[36]xen-users@xxxxxxxxxxxxxxxxxxx
> > 7. file:///mc/compose?to=[37]luis.silva@xxxxxxxxxxxxx
> > 8. file:///mc/compose?to=[38]luis.silva@xxxxxxxxxxxxx
> > 9. file:///mc/compose?to=[39]jeremy@xxxxxxxx
> > 10. file:///mc/compose?to=[40]xen-devel@xxxxxxxxxxxxxxxxxxx
> > 11. file:///mc/compose?to=[41]xen-users@xxxxxxxxxxxxxxxxxxx
> > 12. file:///mc/compose?to=[42]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 13. file:///mc/compose?to=[43]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 14. file:///mc/compose?to=[44]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 15. [45]http://lists.xensource.com/xen-devel
> > 16. file:///mc/compose?to=[46]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 17. file:///mc/compose?to=[47]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 18. file:///mc/compose?to=[48]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > 19. [49]http://lists.xensource.com/xen-devel
> > 20. file:///mc/compose?to=[50]Xen-users@xxxxxxxxxxxxxxxxxxx
> > 21. [51]http://lists.xensource.com/xen-users
> > 22. file:///mc/compose?to=[52]Xen-users@xxxxxxxxxxxxxxxxxxx
> > 23. file:///mc/compose?to=[53]Xen-users@xxxxxxxxxxxxxxxxxxx
> > 24. [54]http://lists.xensource.com/xen-users
>
> > _______________________________________________
> > Xen-devel mailing list
> > [55]Xen-devel@xxxxxxxxxxxxxxxxxxx
> > [56]http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> [57]Xen-devel@xxxxxxxxxxxxxxxxxxx
> [58]http://lists.xensource.com/xen-devel
>
> References
>
> Visible links
> 1. file:///mc/compose?to=jeremy@xxxxxxxx
> 2. file:///mc/compose?to=jeremy@xxxxxxxx
> 3. file:///mc/compose?to=bderzhavets@xxxxxxxxx
> 4. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 5. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx
> 6. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx
> 7. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 8. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 9. file:///mc/compose?to=bderzhavets@xxxxxxxxx
> 10. file:///mc/compose?to=jeremy@xxxxxxxx
> 11. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx
> 12. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx
> 13. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 14. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 15. file:///mc/compose?to=jeremy@xxxxxxxx
> 16. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx
> 17. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx
> 18. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 19. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 20. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 21. http://lists.xensource.com/xen-devel
> 22. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 23. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 24. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 25. http://lists.xensource.com/xen-devel
> 26. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 27. http://lists.xensource.com/xen-users
> 28. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 29. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 30. http://lists.xensource.com/xen-users
> 31. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 32. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 33. file:///mc/compose?to=bderzhavets@xxxxxxxxx
> 34. file:///mc/compose?to=jeremy@xxxxxxxx
> 35. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx
> 36. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx
> 37. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 38. file:///mc/compose?to=luis.silva@xxxxxxxxxxxxx
> 39. file:///mc/compose?to=jeremy@xxxxxxxx
> 40. file:///mc/compose?to=xen-devel@xxxxxxxxxxxxxxxxxxx
> 41. file:///mc/compose?to=xen-users@xxxxxxxxxxxxxxxxxxx
> 42. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 43. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 44. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 45. http://lists.xensource.com/xen-devel
> 46. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 47. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 48. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 49. http://lists.xensource.com/xen-devel
> 50. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 51. http://lists.xensource.com/xen-users
> 52. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 53. file:///mc/compose?to=Xen-users@xxxxxxxxxxxxxxxxxxx
> 54. http://lists.xensource.com/xen-users
> 55. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 56. http://lists.xensource.com/xen-devel
> 57. file:///mc/compose?to=Xen-devel@xxxxxxxxxxxxxxxxxxx
> 58. http://lists.xensource.com/xen-devel
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home