[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] bridge renaming issue with Xen
From:       jesse () nicira ! com (Jesse Gross)
Date:       2010-05-03 21:51:01
Message-ID: AANLkTikWDbLBTZ0VoLpiOrYrjXQrBb1qz5ttmJmDJ6NS () mail ! gmail ! com
[Download RAW message or body]

On Fri, Apr 30, 2010 at 5:57 PM, Lee, Jeongkeun <jklee at hp.com> wrote:

> Hi,
>
> I'm coming back to this problem.
>
> To handle the renaming issue of Xen networking scripts, I tried 'ovs-vsctl
> set' commands as follows: renaming interface, port and then bridge, as the
> order seems matter.
>
> Where bridge name is renamed,
> >     ip link set ${tdev} name ${bridge}
> >     # usually tdev=tmpbridge, bridge=eth0
> >     /usr/local/bin/ovs-vsctl set Interface ${tdev} name=${bridge}
> >     /usr/local/bin/ovs-vsctl set Port ${tdev} name=${bridge}
> >     /usr/local/bin/ovs-vsctl set Bridge ${tdev} name=${bridge}
>
> Similarly, I put
>        `ovs-vsctl set Interface'
>        `ovs-vsctl set Port'
> in the places where interfaces are renamed in the xen scripts.
>
>
I would recommend doing all of these operations in single transaction.  This
is essentially equivalent to what you were doing before with the config file
because vswitchd would only read it when told to.  With the database the
config will be updated after each command, which will confuse things as it
is expected that the is a local port with the same name as the bridge.

You can do that by separating the commands with dashes:

 /usr/local/bin/ovs-vsctl set Bridge ${tdev} name=${bridge} -- set Port
${tdev} name=${bridge} -- set Interface ${tdev} name=${bridge}


> Then, after rebooting, all the networking at dom0 works fine and IP-based
> communications from/to domU work fine too. For example, 'ping x.x.x.x' and
> 'wget' x.x.x.x' from domU are okay.
>
> However, any actions involves DNS (e.g., ping www.google.com) from domU
> cause the entire system (dom0) crash and reboot.
>

Regardless of any configuration inconsistencies, this is concerning.  We
don't do anything special with DNS, so maybe this is UDP issue - can you try
some different UDP traffic?

I also pushed a change last week to fix a crash with checksum offloading.
 This shouldn't have anything do with renaming but it does vary by protocol
and potentially could have been triggered by something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20100503/431fad0c/attachment.htm>

[prev in list] [next in list] [prev in thread] [next in thread]