XAPI doesn't provide a way to look up a VIF entry based on the name, so
we have to locate it by other methods. Previously, we were breaking up
the name into the domid and device number. Unfortunately, it can take
XAPI a few seconds to update the domid of the VM, when resuming from a
suspend. Since we have the VIF UUID, we can just look up the needed
information directly based on that.
Bug #3930
ovs-external-ids was crashing on startup because it was brought up
before /dev/log exists. The simplest solution to this problem is
to have it log to /var/log/openvswitch/ovs-external-ids.log . This
is consistent with vswitchd and ovsdb-server.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
The init script starts monitor-external-ids with --monitor when
configured to do so. Also made changes to guarantee that --monitor
actually restarts ovs-external-ids.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Renamed the monitor-external-ids script ovs-external-ids.
Hopefully this will make it clearer who owns it when someone does
ps xa.
Also removed trailing whitespace from ovs-external-ids.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This patch defensively guarantees that the first id in
xs-network-uuids will belong to the primary network (as opposed to
a vlan). Given that the primary network id comes first, it parses
xs-network-ids and only copies the primary id to bridge-id when
monitor-external-ids is run.
Feature #3647
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Reviewed-by: Ben Pfaff <blp@nicira.com>
I had assumed that a trivial one-line shell script didn't need an explicit
license, but it seems that I was wrong.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This file was under a proprietary license because it was derived from
proprietary XenServer code. That upstream code is now under GPLv2, so
change the downstream code to GPLv2 also.
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
xsconsole is being relicensed under GPLv2 so we need to include the text.
It would be more usual to name this file COPYING and to name the LGPLv2.1
that is already named LICENSE as COPYING.LIB, but some of the files pulled
in from XenServer say that their license is in a file named LICENSE. I
don't expect that Citrix would be willing to change that, so it seems
better to keep LGPLv2.1 named LICENSE.
Signed-off-by: Ben Pfaff <blp@nicira.com>
I had forgotten that I had added this header. Let's keep all the
information about licensing in individual files instead.
Signed-off-by: Ben Pfaff <blp@nicira.com>
When the init script's reload function is called it will send a
SIGHUP to monitor-external-ids. This will cause
monitor-external-ids to re-generate everything.
Feature #3668.
The number of ovs-vsctl calls required to add a new vif in
monitor-external-ids grew linearly with the number of vifs in the
system. Changed to only do O(1) ovs-vsctl calls per vif addition.
On overloaded XenServers the current default timeout of 5 seconds can
occasionally be reached, which causes VM startup to fail. This commit
fixes the problem by removing the default timeout and changing each
invocation of ovs-vsctl within the tree to specify its own timeout,
if appropriate.
Bug #3573.
It's not necessary to explicitly delete the pidfile when stopping
monitor-external-ids through the init script, since the daemon will take
care of that.
monitor-external-ids can't complete all its tasks until XAPI is up. The
daemon is usually started before XAPI, so it can miss events. This
commit causes the daemon to block until XAPI is finished initializing.
This can be useful on systems other than XenServer so there is no reason
to make it looks XenServer-specific.
CC: Jeremy Stribling <strib@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
vswitch.xml was updated to describe system-id and xs-system-uuid but the
implementation of this update was incomplete.
CC: Justin Pettit <jpettit@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The monitor-external-ids daemon monitors the external_ids columns of the
Bridge and Interface OVSDB tables. Its primary responsibility is to
set the "bridge-id" and "iface-id" keys in the Bridge and Interface
tables, respectively. It also looks for the use of "network-uuids" in
the Bridge table and duplicates its value to the preferred
"xs-network-uuids".
Signed-off-by: Justin Pettit <jpettit@nicira.com>
The configuration schema defines the system-type and system-version
external-ids for the Open_vSwitch table. This commit adds support for
reporting them on XenServer.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
These initial bindings pass a few hundred of the corresponding tests
for C implementations of various bits of the Open vSwitch library API.
The poorest part of them is actually the Python IDL interface in
ovs.db.idl, which has not received enough attention yet. It appears
to work, but it doesn't yet support writes (transactions) and it is
difficult to use. I hope to improve it as it becomes clear what
semantics Python applications actually want from an IDL.
We used ovs-wdt at Nicira for a while when we were working on building
hardware switches. We don't use it anymore, so remove it from the tree.
CC: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The ovs-monitor script is now more than adequately replaced by the
--monitor option to the various daemons.
CC: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
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>
