This fixes the converse of the problem addressed by commit fe19e820
"xenserver: Kill bond master's dhclient when bringing up bond slave". In
that commit's log message, I claimed that the converse was not a problem,
but I was wrong. I must have screwed up in testing, because it really is
a problem. This commit fixes it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: Dominic Curran <dominic.curran@citrix.com>
Reported-by: Michael Mao <mmao@nicira.com>
Bug #2668.
Commit 823c5699 "interface-reconfigure: callout to datapath backend class
method on rewrite" changed "interface-reconfigure rewrite" to update
bridge external-ids in the vswitch database. But this had the side effect
of causing errors at system shutdown, since ovsdb-server gets shut down
before the rewrite action is called. This commit fixes the problem by
skipping the update if the database socket does not exist. (It's just
fine to skip the update, since the external-ids will be re-set the next
time the system boots anyhow.)
This commit fixed the problem on 5.6.810-34773p for me. I don't see the
problem at all on 5.5.0. Presumably system shutdown order has changed.
NIC-136.
CC: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
interface-reconfigure is never explicitly called to down a bond master.
However, when it is called to up a slave it is implicit that we are
destroying the master. The "bridge" version of interface-reconfigure
always "ifdown"s the bond master in such a case, but until now the
"vswitch" version has not done so. Usually, it doesn't matter, because
the bond master network device disappears when the slave is brought up,
but one case was missed: for a bond master with an IP address obtained
via DHCP, the dhclient process needs to be killed, and we were not doing
it. This commit starts doing it (by invoking ifdown on the bond master).
The dhclient process that hangs around doesn't cause problems until the
bond master is brought back up, at which point "ifup" fails because it
refuses to start another dhclient for the same interface.
The converse behavior is also important; that is, when a bond PIF is
brought up, interface-reconfigure is expected to implicitly take down its
slave PIFs. My testing (on 5.5.0) shows that this behavior is already
correct. At any rate, this commit does not change that behavior.
Bug #2668.
Bug #2734.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Use this mechanism to allow the vswitch backend to update the vswitch
configuration's mapping from datapath to XenAPI datamodel Network
UUIDs. The vswitch needs a mechanism to update these when they change
(i.e. on pool join and eject).
Refactor the DatapathFactory method to return the class which the
caller can instantiate or not as the require.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Otherwise bridges can end up with a generated MAC address using Nicira OID
which has an impact when using DHCP on that devices.
tests/interface-reconfigure.at updated by Ben Pfaff.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now the names of the external_ids keys used for Bridge records have
implied that they are specific to XenServer, because they begin with "xs-".
They are more generic in intent, however, so this commit removes the "xs-"
prefix and explains them more generically.
This finishes the renaming process started in commit c0f9490 "vswitchd:
Make names of Interface external_ids generic."
CC: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
These settings are supported by the bridge, and they were supported
earlier by the vswitch, but support regressed when OVSDB was initially
introduced because at first ovs-vsctl did not support these settings.
This commit restores support.
Related to bug #2430, #2442.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This should be done when bringing down the last PIF which uses a
datapath in order to account for VLAN PIFs sharing a datapath.
The logic in bring_down() already acounts for this requirement by
clearing the dp variable if the datapath is still required so if we
get as far as deconfiguring that datapath then it is also correct to
bring down the physical devices.
With unit test suite update by Ben Pfaff.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
With override via other-config:mtu field on specific objects in the datamodel.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1267008538 0
# Node ID a91df72fd4bf6329831d3efcae45a5ff55e3ba2e
# Parent 219104a041786d7274b15800de5c3efccf0c4f42
Before, interface-reconfigure would only bring remove a VLAN's bridge
incidentally as part of removing its datapath's bridge. This commit fixes
it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
It makes sense to set xs-network-uuids for every bridge, so this commit
does so. It also makes the code a bit more readable by factoring logic
out into a new function.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The datapath_modify_config() call here was at the wrong level of
indentation, so it was only getting called if 'dp' was to be deleted.
Signed-off-by: Ben Pfaff <blp@nicira.com>
In configure_datapath(), bringing up a VLAN PIF's datapath is no different
from bringing up a non-VLAN PIF's datapath, but the code was making
unnecessary distinctions. Also, the test
if parent and datapath:
did not work at all, because there was no variable named 'datapath' in
scope and no obvious source of one.
In preconfigure(), it then becomes necessary to create a VLAN bridge for a
VLAN PIF, in a straightforward way.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The previous commit made pif_bridge_name() in the bridge and vswitch
versions of interface-reconfigure functionally identical, so this commit
hoists them into a single common implementation in InterfaceReconfigure.py.
pif_is_bridged() also comes along for the ride because it is also generic
and because it is logically related. Only the bridge code uses it at the
moment.
Suggested-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
pif_bridge_name() was written when the vswitch interface-reconfigure was
working with the raw Open vSwitch configuration via ovs-cfg-mod. Then,
it made no sense to ask for the "bridge name" of a VLAN PIF, because a
VLAN PIF didn't have a bridge.
Now, however, the vSwitch interface-reconfigure works with ovs-vsctl, which
provides a thin layer over the OVS configuration that makes VLAN bridges
appear to exist. So now it makes sense to ask for the bridge of a VLAN
PIF, and this commit enables that.
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-vsctl command "--if-exists del-port eth0" does nothing if eth0 is on
a bridge as part of a bond, because the bond's port name is not eth0 but
something else. But interface-reconfigure needs to do that, so this commit
adds that ability to ovs-vsctl and modifies interface-reconfigure to use it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
When a secondary management interface is configured on a XenServer,
interface-reconfigure would fail to bring it up because it would attempt
to add a bridge that already exists. This commit makes it tolerate that
situation.
This is because PIF.MAC for a VLAN is FE:FF:FF:FF:FF:FF. In bridge
mode the VLAN and the bridge naturally pick up the underlying MAC
address from the physical device but under vswitch we must explicitly
specify it and we are currently specifying
FE:FF:FF:FF:FF. interface-reconfigure needs to use the MAC address of
the tagged PIF not the untagged PIF.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1265020755 0
# Node ID d7fc59d6a274334377fdbb09dcaf80a76431bcdb
# Parent a6f27b5a3096ce627b5003c7be19ca59f7dd9606
This patch updates the versions of the host integration scripts to
what is present in the recent XCP update and the next release of
XenServer (5.6). I think it probably works on 5.5 as well but I
haven't verified that.
These new versions support runtime selection of the Linux bridging vs
vswitch through the toolstack. The patch includes the necessary
reconfiguration (rewriting /etc/xensource/network.conf) to enable
vswitch in the RPM %post stage.
The RPM spec file integration is only lightly tested, seems to work
for me.
This commit is as provided by Ian Campbell, with a few minor tweaks:
- Updated xenserver/automake.mk to distribute the added files.
- Updated RPM spec file not to complain if the added files do
not already exist (since they do not exist on XenServer 5.5.0).
- Change location of dbcache back to /var/lib/openvswitch/dbcache
so that this can coexist with our other internal builds.
(Undoubtedly we will have to adopt the new location chosen by Ian
eventually, however.)
