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

Re: [Xen-devel] [PATCH] xend: Do not mess with bridge if admin has set one up already



On Mon, Jun 14, 2010 at 04:07:07PM +0100, Ian Jackson wrote:
> Previously, the default "network-script",
> /etc/xen/scripts/network-bridge, would attempt to do its horrid work
> even if you had already set everything up in /etc/network/interfaces.
> 

Instead of talking about "/etc/network/interfaces" you could write 
"distro-specific network scripts like /etc/network/interfaces or 
/etc/sysconfig/network-scripts/ifcfg-*" :)

-- Pasi

> Setting up your bridge in /etc/network/interfaces is:
>  * easy
>  * required for libxl since libxl never does it for you
>  * not a fragile piece of lunacy
>  * properly documented
>  * the way everyone would expect it to work
> 
> In this small patch we make it so that the default config for xend
> doesn't mess about on startup if you already have a bridge, and
> doesn't mess about on shutdown unless your first-named bridge (eth0 or
> xenbr0, normally) doesn't also have a physical interface named
> p<whatever> (peth0 or pxenbr0) enslaved to it.  The latter test is not
> ideal but will hopefully do from now until the time xend finally dies.
> 
> We also fix the "documentation" - ie, the comments in the default
> xend-config.sxp - to correspond to reality.
> 
> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> 
> diff -r 125b3493dac9 tools/examples/xend-config.sxp
> --- a/tools/examples/xend-config.sxp  Fri Jun 11 11:37:22 2010 +0100
> +++ b/tools/examples/xend-config.sxp  Mon Jun 14 16:07:02 2010 +0100
> @@ -147,8 +147,22 @@
>  #
>  # (network-script 'network-bridge netdev=eth1')
>  #
> -# The bridge is named xenbr0, by default.  To rename the bridge, use
> +# The bridge is named eth0, by default (yes, really!)
>  #
> +
> +# It is normally much better to create the bridge yourself in
> +# /etc/network/interfaces.  network-bridge start does nothing if you
> +# already have a bridge, and network-bridge stop does nothing if the
> +# default bridge name (normally eth0) is not a bridge.  See
> +# bridge-utils-interfaces(5) for full information on the syntax in
> +# /etc/network/interfaces, but you probably want something like this:
> +#    iface xenbr0 inet static
> +#        address [etc]
> +#        netmask [etc]
> +#        [etc]
> +#        bridge_ports eth0
> +#
> +# To have network-bridge create a differently-named bridge, use:
>  # (network-script 'network-bridge bridge=<name>')
>  #
>  # It is possible to use the network-bridge script in more complicated
> @@ -169,7 +183,8 @@
>  # configuring a new vif, but a value specified here would act as a default.
>  #
>  # If you are using only one bridge, the vif-bridge script will discover that,
> -# so there is no need to specify it explicitly.
> +# so there is no need to specify it explicitly.  The default is to use
> +# the bridge which is listed first in the output from brctl.
>  #
>  (vif-script vif-bridge)
>  
> diff -r 125b3493dac9 tools/hotplug/Linux/network-bridge
> --- a/tools/hotplug/Linux/network-bridge      Fri Jun 11 11:37:22 2010 +0100
> +++ b/tools/hotplug/Linux/network-bridge      Mon Jun 14 16:07:02 2010 +0100
> @@ -216,6 +216,10 @@
>       return
>      fi
>  
> +    if [ `brctl show | wc -l` != 1 ]; then
> +        return
> +    fi
> +
>      if link_exists "$pdev"; then
>          # The device is already up.
>          return
> @@ -263,6 +267,10 @@
>      fi
>      if ! link_exists "$bridge"; then
>       return
> +    fi
> +    if ! [ -e "/sys/class/net/${bridge}/brif/${pdev}" ]; then
> +        # $bridge is not a bridge to which pdev is enslaved
> +        return
>      fi
>  
>      claim_lock "network-bridge"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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


 


Rackspace

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