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.
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.)
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>
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.
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>
Commit 723a8c3ca "xenserver: Disable brcompatd" turned off brcompatd by
default but allowed it to be enabled using an option, but the option
didn't work. This commit fixes that problem.
The compat layer is now unused in the vswitch branch of XenServer.
Based on change originally by Ian Campbell, cherry-picked from
"xs5.7" branch. The original change was not conditional on the
XenServer version.
This command was returning success when vswitchd was not running.
Our automated test relies on this command to decide if the host uses
vswitch or not.
If vswitchd is not OK then brcompatd is not checked at all. Since the
return codes apparently have specific meanings I couldn't see a sensible
way to combine multiple failure results.
(Cherry-picked from xs5.7 branch by Ben Pfaff but merge conflicts meant
that the whole thing had to be redone.)
I don't think it makes sense to report brcompatd's status when it is
explicitly disabled. Doing so causes service status to return an error
when brcompatd is deliberately disabled.
Also fix up a tab vs. spaces whitespace snafu.
This commit cleans up the locations of a number of files and directories
used. These include:
- Config file lives in /etc/openvswitch/conf.db
- Logs go into /var/log/openvswitch
- ovsdb-server socket is /var/run/openvswitch/db.sock
- Schema goes into /usr/share/openvswitch/vswitch.ovsschema
- PID files go in /var/run/openvswitch
For XenServer, these additional changes are made:
- Cores go in /var/xen/openvswitch
- OVS binaries run in /var/xen/openvswitch
In addition, it attempts to cleanup the XenServer packaging. This
includes referring to the project as "openvswitch" as opposed to the
somewhat presumptuous "vswitch".
Note: Changes to the Debian packaging will be forthcoming.
