Use this to detect and report up-front in vif-bridge script whether
the bridge device exists or not.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Hotplug scripts include certain bash-isms that are not supported under
some distros' default shell (eg. Ubuntu 6.10's use of dash)
Signed-off-by: Alastair Tse <atse@xensource.com>
external-device-migrate script in its handling of parameters.
Patch from Roland Illig <roland.illig@gmx.de>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
interface from the bridge when going offline -- the comment stating that
interfaces are auto-removed does not seem to be true, at least some of the
time. Log failure of brctl delif and ifconfig down only at debug level, as
this script may be called more than once, depending upon the hotplug
configuration.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
emerged as a problem in the field, AFAIK, but it seems that distro scripts
could have brought the device down already by this point (Debian stable's
net.agent does ifdown vifX.Y, and it wouldn't surprise me if someone decided
to do ifconfig vifX.Y down if this failed, for example).
Logging but ignoring the failure seems sensible.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the remove event, the script environment variable has disappeared, so we must
hook on the offline event instead. This fix was put into xen-backend.rules,
but not the vif scripts, so they were out of sync, and the interfaces were not
being properly closed down.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
and udev. Pass all commands through from xen-backend.agent or
xen-backend.rules rather than second-guessing the individual scripts. This
should make it easier to tear down devices cleanly, especially the dangling
vifs we are seeing at the moment.
Cope with a missing type node inside the block script, as we don't want to
resurrect a removed node by writing a hotplug error message.
Log failure of iptables command.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
The problem is: There is no mechanism to detect block device setup failure
Network devices have the same problem, and are fixed with this too.
I handling this problem in the way suggested by aliguori:
- hotplug scripts write a "hotplug-status" node on store
- Xend DevController.createDevice() check verify this node and return success
or throw an exception on failure.
- If no changes in "hotplug-status" node after DEVICE_CREATE_TIMEOUT seconds
Xend throw an exception showing the problem with hotplug scripts.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
hotplug ones. Added evalVariables and findCommand functions to that, which we
use to clarify the handling of variables being passed in as command line
variables.
Make vif-bridge able to find the bridge for itself if only one bridge is in
use. This means that it is not necessary to specify a bridge in many
configurations. Allow the bridge to be specified on the command line, meaning
that a default may be provided in the xend-config.sxp if desired.
Added xenstore_read_default to xen-hotplug-common.sh, which reads from the
store but uses a given default if the path in the store is not present. This
is used by vif-bridge to allow the store details (i.e. those given to xm create)
to override the default value given in the xend-config.sxp.
Remove vif-bridge setting -- the value can be specified on the vif-script
command line if necessary.
Added examples for network-nat/vif-nat.
Added lots of big comments.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
code into vif-common.sh.
Fix the antispoofing in network-bridge to allow forwarding from physical
device to bridge, and vif0.0 to eth0.
Change the interface between netback driver and vif hotplugging scripts. The
mac address and bridge details are read from the store directly by the script,
so that the kernel driver does not need to get involved.
Remove an awful lot of cruft from vif-bridge. Move the iptables handling into
vif-common.sh, and fix it so that the new vif can get past the antispoofing
entries. Merge vif-nat and vif-route into this structure too.
Use ip instead of ifconfig to get necessary details.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
This is Kurt Garloff's reworked network-bridge script:
* we got rid of ifconfig
* it works for netdev != eth0
* arp on and off are symmetric as are ifdown and ifup
* ifup will be passed the ifcfg config file name if needed
(the ifup may otherwise figure that the veth0 hardware is
NOT the same as the original ${netdev} and not use the same
config -- this happens on SUSE. Charles Coffing tracked this
one down.)
Plus Kurt's avoid-dash patch:
the network setup scripts on SUSE have trouble with the bridge
name xen-br0; they don't expect the '-'.
Arguably this should be fixed.
But I assume there's more scripts out there which may not like it,
so I suggest the following patch to rename xen-br0 to xenbr0.
Plus Charles Duffy's patch to support multiple bridges:
The attached patch allows the network-bridge script to be used to
generate multiple bridges corresponding to different physical
interfaces. It adds a new parameter, "vifnum", used to refer both to
the loopback interface to be used and to set defaults regarding the
physical interface and bridge name.
Thus, if one wishes to start xenbr0 on eth0 and xenbr1 on eth1, one
need only call:
network-bridge start ## vifnum is 0 by default
network-bridge start vifnum=1
...well, that and set loopback.nloopbacks=2 in the Dom0 kernel
parameters.
Plus renaming of virtnum to vifnum in Charles' patch, as requested by Ian Pratt.
Plus a fix to DevController to allocate vif IDs starting from 0 (i.e. vif2.0
is now domain 2's first vif, as opposed to vif2.1 in the recent past).
Plus tidying up inside network-bridge using some helper variables.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
- make xen-hotplug-common.sh (un)set locales.
- use xen-hotplug-common.sh in vif-bridge.
From Gerd Knorr <kraxel@suse.de>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
2. Update scripts/vif-bridge to not call 'brctl delif'
When a domU is shutdown/destroyed and the netif is destroyed, the
notify_call_chain triggered from unregister_netdevice() will trigger the
bridge event handler and which will call the proper code to remove the
device from the bridge.
I can't see any reason why brtcl delif should be called when taking out
a domain if the call chain will delete the interface from the bridge
when the vif is destroyed automatically.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Many files:
Make interface to network/block scripts consistent:
- output on stdout is returned to the script caller
- output on stderr is logged at the error level, messages with a '-' prefix
are logged at the debug level and messages with a '*' prefix are logged
at the info level.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
