Sometimes it takes a moment for the OVS daemons to die. When that happens,
the "start" half of "openvswitch restart" can fail when ovsdb-tool
runs, because ovsdb-server will still have the lock on the database if it
has not exited yet. So this commit just makes the "stop" half wait for
the daemons to really die.
Bug #3369.
I can't easily find anything that documents what commands Fedora init
scripts should support, but many of them support "reload" and
"force-reload". This commit adds support for them to the XenServer init
scripts. (The Debian init scripts already had support.)
Debian does document that reload and force-reload should be supported:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init
Reported-by: Reid Price <reid@nicira.com>
Bug #3266.
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>
The previous commit "xenserver: Create network.conf before running
interface-reconfigure" fixed a problem that was not noticed earlier only
because we had not tested very often on pristine XenServer 5.5.0 systems,
instead mostly on systems that had had Open vSwitch installed before and
thus already had a network.conf file. This commit should help to avoiding
future regressions in this area, by removing network.conf when the
openvswitch package is removed on XenServer 5.5.0.
XenServer 5.5.0 doesn't have /etc/xensource/network.conf, but the
interface-reconfigure that OVS installs issues an error and aborts if it
does not exist, so create network.conf before trying to run it.
CC: Paul Ingram <paul@nicira.com>
Just silently don't start OVS daemons if /etc/xensource/network.conf
contains a value of "bridge". This allows the init script to be called
regardless of whether OVS or bridge is configured.
The OVS processes would start as long as "/etc/xensource/network.conf"
didn't contain "bridge". The other OVS scripts, however, would complain
(and not run) if it wasn't "vswitch" or "openvswitch". This commit will
only start the OVS processes if a value of "vswitch" or "openvswitch" is
present, so some consistency is provided.
(If "/etc/xensource/network.conf" is not "bridge", "vswitch", or
"openvswitch", then XAPI will refuse to run anyway, so not much is going
to happen on the system.)
Examining the XAPI source code shows that at startup it invokes a script
named /opt/xensource/libexec/xapi-startup-script, if one exists. Testing
shows that this was also true in XenServer 5.5.0. No such script is
installed by default. Searching for "xapi-startup-script" on Google (with
the quotes) has only one hit, which is documentation on XAPI startup. So
it seems that we're pretty safe in taking advantage of this hook ourselves.
This commit changes the RPM scripts to install refresh-network-uuids as
the XAPI startup hook on XenServer 5.5.0.
CC: Rob Hoes <rob.hoes@citrix.com>
Commit 823c5699 "interface-reconfigure: callout to datapath backend class
method on rewrite" changed "interface-reconfigure write" to do what
refresh-network-uuids does. We can't entirely get rid of
refresh-network-uuids, so this commit rewrites it as a trivial wrapper
around interface-reconfigure.
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>
network_uuid_refresh_run() needs to update pool_conf_mtime as soon as it
notices a change. Otherwise it thinks that the mtime has changed every
time it is called and therefore never actually runs the refresh script.
Bug #2097.
XAPI calls the "update" method of the vswitch-cfg-update plugin whenever it
starts or restarts. Thus, this is a good place to trigger updating network
UUIDs. This commit implements that behavior. This should fix the problem
of network UUIDs not being updated on pool join, since XAPI restarts when
it joins a pool.
When XenServer 5.5 support is no longer interesting, we should integrate
the refresh-network-uuids script into the XAPI plugin.
Lightly tested, works for me on 5.6.810-31078p.
See-also: http://openvswitch.org/pipermail/dev_openvswitch.org/2010-June/002216.html
Suggested-by: Rob Hoes <rob.hoes@citrix.com>
Bug #2097.
In my testing with XenServer 5.6.810 without ovs-xenserverd the
vswitch bridge external-id network-uuid field was always kept up to
date over both pool join and pool eject. I believe this is because
xapi is restarted on both pool join and pool eject and on restart all
PIFs are plugged again. This causes the vswitch field to be updated,
either via a call to interface reconfigure or via an explicit
ovs-vsctl call in the case of internal networks.
I think the only reason this daemon would still be required with
XenServer 5.5 is that the explicit call to ovs-vsctl for internl
networks is not present there.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Now that we have a new patch implementation, remove the veth driver
and its userspace components. Then rename 'patchnew' to 'patch'.
The new implementation is a drop-in replacement for the old one.
When /etc/xensource/network.conf contains the word "bridge", the system
is supposed to use the Linux bridge, not Open vSwitch. This commit makes
OVS honor this setting, which until now it has mainly ignored.
Reported-by: Reid Price <reid@nicira.com>
XAPI updates the pool.conf file before it actually refreshes its database
from the new pool, so we need to wait for that to happen. Hard-coded
delays aren't a good idea, but in the long term XAPI will probably be
adding a hook script for us to use, so this may be an OK stopgap measure.
Bug #2756.
Add code to "emergency_reset" plug-in method to actually do its work.
Also, when the manager is changed, call the emergency reset command to
clear out any configuration that may have been done by a previous
controller.
The vswitch database is supposed to maintain an up-to-date UUID for the
system's networks in the Bridge table as external-ids:network-uuids. On
XenServer systems, /opt/xensource/libexec/interface-reconfigure updates
these fields as bridges are brought up and down. Most of the time, that is
sufficient. However, this is one exception: when a XenServer host enters
or leaves a pool, interface-reconfigure is not invoked, and neither is any
other script. So this commit introduces a new, XenServer-specific daemon
that monitors the XenServer's pool membership status and refreshes the
network UUIDs (by invoking the refresh-network-uuids script) if it changes.
Bug #2097.
Calling "interface-reconfigure up" can take a couple of seconds, but all
we have to do here, really, is fetch the network UUIDs and invoke
ovs-vsctl, which is much faster. So rewrite this script in Python and make
it do just that.
On XenServer 5.5, interface-reconfigure is not called when creating
internal bridges, so we jump through extra hoops to determine the
network UUIDs. The code that handled this was not properly retrieving
the UUIDs from XAPI, so the field would never be set. This commit
corrects that.
Bug #2666
The %post script fragment in the RPM spec was moving aside the original
InterfaceReconfigure{,Bridge,Vswitch}.py scripts, but the %postun was
not restoring them. This commit restores them in %postun.
Without this change, installing the openvswitch RPM on a stock XenServer
and then uninstalling it breaks XenServer networking.
Bug #2624.
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The new GRE implementation provides a complete drop in replacement
for the old Linux based implementation. Therefore, remove the
old implementation and rename "grenew" to "gre".
In a future commit, the "patch" netdev type will be introduced. The
initial implementation will be based on veth, for which we have a kernel
module on 2.6.18. A more general solution will be used in the future,
at which time, this loading of the veth module can be removed.
The OVS kernel modules were moved to kernel/extra/openvswitch, but the
init script wasn't updated to look for the ip_gre_mod kernel module
there. This commit fixes that.
CC: Paul Ingram <paul@nicira.com>
Starting in XenServer 5.6.0, a "vswitch_controller" key is available to
store the controller's IP address in the "pool" table of XAPI. Older
versions must still use the "vSwitchController" key in "other_config".
Based on commits 37fee7 and 0ebd737 from the xs5.7 branch written by
Ian Campbell.
The 5.6.0 XenServer release will include OVS but not have it enabled by
default. By only registering the xsconsole plugin on systems running OVS,
this plugin can be included in the main distribution.
Based on commit 0ebd737 from the xs5.7 branch written by Ian Campbell.
This change cleans up a couple of items. First, it makes sure that our
newly installed kernel modules are picked up instead of any ones that
shipped with XenServer. Second, it prevents having to do the install
with "--nodeps".
The OVS xsconsole plugin used to be installed in
/usr/share/openvswitch/scripts directory and then a symlink was created
to the /usr/lib/xsconsole/plugins-base directory. The Citrix packaging of
OVS just placed it directly into the xsconsole plugin directory. This
worked fine until we renamed our package "openvswitch", which is the
same as Citrix uses.
On an upgrade, the default package handler would attempt to clean up files
that were in the Cirix packaging, but not in the upgraded package. Since
it didn't know that we had replaced their plugin with our symlink, it would
destroy our symlink.
This commit just places the plugin directly into the
/usr/lib/xsconsole/plugins-base directory, which allows us to seamlessly
upgrade to newer Open vSwitch versions.
Bug #2608
