WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] domU loses incoming network after period of inactivity

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] domU loses incoming network after period of inactivity
From: "Matthew Law" <matt@xxxxxxxxxxxxxxxxxx>
Date: Tue, 16 Feb 2010 13:24:16 -0000
Delivery-date: Tue, 16 Feb 2010 05:25:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
Importance: Normal
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Reply-to: matt@xxxxxxxxxxxxxxxxxx
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: SquirrelMail/1.4.19
I have a domU which is losing incoming network connectivity after 'some
period of inactivity' - I assume overnight, since that is what appears to
be happening.

If I ping it from the dom0 it magically wakes up and is accessible again. 
Likewise, if I console onto it from the dom0 and then ping either the dom0
or an outside host it will wake up.

In both cases the initial ping response time is initially several seconds
and then settles down to sub-millisecond time (as I would expect).  There
are no firewall rules or cron jobs running on the domU.  The dom0 has
nothing running other than a regular NTP sync.

The dom0 has the following iptables and ebtables rules in place (ebtables
is there to try and prevent IP spoofing):

iptables:

ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED PHYSDEV match --physdev-out vif10.0
ACCEPT     udp  --  anywhere             anywhere            PHYSDEV match
--physdev-in vif10.0 udp spt:bootpc dpt:bootps
ACCEPT     all  --  anywhere             anywhere            state
RELATED,ESTABLISHED PHYSDEV match --physdev-out vif10.0
ACCEPT     all  --  domu.fqdn   anywhere            PHYSDEV match
--physdev-in vif10.0

ebtables:

Bridge chain: vif10.0, entries: 5, policy: DROP
-p ARP --arp-op Request -j ACCEPT
-p IPv4 --ip-src domu.ip.address -j ACCEPT
-p IPv4 --ip-dst domu.ip.address -j ACCEPT
-p ARP --arp-op Reply --arp-ip-src domu.ip.address -j ACCEPT
--log-level notice --log-prefix "arp-drop" --log-arp -j DROP

The domU is an Ubuntu Karmic image that I took from stacklet and other
than this, has no other obvious problems.  It has been halted and
restarted (from the domU) several times and comes up with no problems
whatsoever.  There are 8 other debian Lenny and Centos 5.4 domUs on this
host which have no problems afaik.  The dom0 uses bridging for all domUs
and the brctl show looks like this:

brctl show:
bridge name     bridge id               STP enabled     interfaces
eth0            8000.003048d9edf6       no              vif10.0
                                                        vif9.0
                                                        vif8.0
                                                        vif5.0
                                                        vif6.0
                                                        vif4.0
                                                        vif2.0
                                                        vif3.0
                                                        vif1.0
                                                        peth0

The vif names are assigned in the domU config, as are the mac addresses
and static IPs.  There is nothing immediately obvious in the xen logs and
no messages in the system logs that look suspect either.  iptables logging
is currently disabled, however.

What could this be? - is there any housekeeping that xen does which could
cause this or perhaps some misconfiguration on my part?


Thanks in advance,

Matt.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users