Until now, ovs-vsctl has kept trying to the database server until it
succeeded or the timeout expired (if one was specified with --timeout).
This meant that if ovsdb-server wasn't running, then ovs-vsctl would hang.
The result was that almost every ovs-vsctl invocation in scripts specified
a timeout on the off-chance that the database server might not be running.
But it's difficult to choose a good timeout. A timeout that is too short
can cause spurious failures. A timeout that is too long causes long delays
if the server really isn't running.
This commit should alleviate this problem. It changes ovs-vsctl's behavior
so that, if it fails to connect to the server, it exits unsuccessfully.
This makes --timeout obsolete for the purpose of avoiding a hang if the
database server isn't running. (--timeout is still useful to avoid a hang
if ovsdb-server is running but ovs-vswitchd is not, for ovs-vsctl commands
that modify the database. --no-wait also avoids that issue.)
Bug #2393.
Bug #15594.
Reported-by: Jeff Merrick <jmerrick@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The vlog manpage implies that writing ANY explicitly is obsolete, but
examples elsewhere in the documentation and code still tend to add it.
This removes them.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, "emer" has effectively been "off" because no messages were ever
logged at "emer" level. Justin points out that it is useful to use "emer"
for messages that indicate a fatal error. This commit makes that change
and adds a new "off" level to really turn off all logging to a facility.
A pool configured for secure fail-mode can block dom0 traffic on hosts joining
the pool or if the host reboots while the controller is unavailable. This
commit sets default flows on a host under these conditions to allow management
traffic. Once the connection with the controller is re-established, these
default flows are replaced by the controller.
tests/interface-reconfigure.at updated by Ben Pfaff.
NIC-376.
Signed-off-by: David Tsai <dtsai@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The MTU of the fake bond interface and the slaves participating in
a bond should all agree. The correct long term solution to this
problem is to remove the fake bond interface altogether. Until
that's possible, we simply set the MTU of the slaves.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Some Linux network drivers support a feature called "VLAN acceleration",
associated with a data structure called a "vlan_group". A vlan_group is,
abstractly, a dictionary that maps from a VLAN ID (in the range 0...4095)
to a VLAN device, that is, a Linux network device associated with a
particular VLAN, e.g. "eth0.9" for VLAN 9 on eth0.
Some drivers that support VLAN acceleration have bugs that fall roughly
into the following categories:
* Some NICs strip VLAN tags on receive if no vlan_group is registered,
so that the tag is completely lost.
* Some drivers size their receive buffers based on whether a vlan_group
is enabled, meaning that a maximum size packet with a VLAN tag will
not fit if a vlan_group is not configured.
* On transmit some drivers expect that VLAN acceleration will be used
if it is available (which can only be done if a vlan_group is
configured). In these cases, the driver may fail to parse the packet
and correctly setup checksum offloading and/or TSO.
The correct long term solution is to fix these driver bugs. To cope until
then, we have prepared a patch to the Linux kernel network stack that works
around these problems. This commit adds support for the workaround
implemented by that patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Commit 34edeccfd8 removed a
workaround which still applies to XenServer versions older than
5.5. This could causes creation of vlans to fail in some cases.
CC: "David Tsai" <dtsai@nicira.com>
Bug #4877.
Allow users or applications to enable or disable in-band management of
individual bridges by setting the 'vswitch-disable-in-band' key in the
'other_config' attribute of the corresponding network to 'true' or
'false'.
Bug #4749.
Commit 404c169247 breaks compatibility with
XenServers older than 5.6 FP1. This commit removes the last vestiges of
support for those older XenServer versions.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Citrix have made modifications to the various interface configuration scripts
that OVS replaces, so at present those modifications are lost when OVS is
installed on e.g. XenServer 5.6.100. This commit applies those changes while
preserving OVS-specific modifications that have been made in the interim.
One major change introduced by these updates is the removal of support for
XenServer releases prior to 5.6.100.
This commit also updates the OVS-supplied xen-bugtool in similar fashion. We
will soon remove xen-bugtool from OVS altogether and move the added OVS
functionality to an XML extension as described in the Supplemental Pack DDK
guide.
Makes required changes to interface reconfigure to allow LACP
configuration from xapi. Conforms to XenServer style bonding
configuration which is slightly different from OVS.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Bug #4213.
This patch allows the Pool object's vswitch-controller-fail-mode
setting to be overridden on by Network object.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
InterfaceReconfigure assumes the pool is in the configuration
cache. This is always true except when upgrading from an older
version of openvswitch which does record the pool. This can cause
upgrades to lock up.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This commit allows xapi to set the fail mode through the
vswitch-controller-fail-mode other-config setting in the Pool
object.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This commit makes necessary changes to Interface Reconfigure to
allow miimon bond-detect-mode and bond-miimon-interval to be
changed using xapi.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This commit adds bond_mode configuration to Interface Reconfigure
so that it may be changed using standard XenServer commands.
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>
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.)
