Too many users have incorrectly assumed that ovs-controller is a necessary
or desirable part of an Open vSwitch deployment. This commit should fix
the problem by renaming it test-controller and removing it from the
default install and from packaging.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This python script summarizes ovs-dpctl dump-flows content by aggregating
the number of packets, total bytes and occurrence of the following fields:
- Datapath in_port
- Ethernet type
- Source and destination MAC addresses
- IP protocol
- Source and destination IPv4 addresses
- Source and destination IPv6 addresses
- UDP and TCP destination port
- Tunnel source and destination addresses
Testing included confirming both mega-flows and non-megaflows are
properly parsed. Bit masks are applied in the case of mega-flows
prior to aggregation. Test --script parameter which runs in
non-interactive mode. Tested syntax against python 2.4.3, 2.6 and 2.7.
Confirmed script passes pep8 and pylint run as:
pylint --disable=I0011 --include-id=y --reports=n
This tool has been added to these distribution:
- add ovs-dpctl-top to debian distribution
- add ovs-dpctl-top to rpm distribution.
- add ovs-dpctl-top to XenServer RPM.
Signed-off-by: Mark Hamilton <mhamilton@nicira.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
This change includes the output of ovs-appctl bfd/show to
ovs-bugtool output.
Signed-off-by: Pavithra Ramesh <paramesh@vmware.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
During installation create the /var/log/openvswitch directory
so that openvswitch startup script is able to write the ovs-ctl.log
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The previous code had many subtleties that were easy to miss. This code
is intended to be more obviously correct.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Tested-by: Gurucharan Shetty <shettyg@nicira.com>
Currently we connect to xapi in case there are multiple
external_ids:xs-network-uuids to get the single bridge id everytime
we have a change in the database for all the interested columns in
ovs-xapi-sync. The xs-network-uuids value can also change whenever
new VLANs are added or deleted, which is a common use case. The
disadvantage with this approach is that we query XAPI more often
and set the bridge-id as "" if we don't get a valid response for
our query. This can take down the logical connectivity for all the
VMs on that xenserver.
Instead of looking at the PIF records for all the xs-network-uuids,
we can instead just look at the xapi record which has the same bridge
name as the OVS bridge name and then cache its uuid. This value will
hold true till the OVS bridge is recreated in which case we will re-read
the value.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
The underlying glibc interface is deprecated because the interface itself
is not thread-safe. That means that there's no way for a layer on top of
it to be thread-safe.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
When there are multiple xs-network-uuids set for a bridge,
we query xapi to get the record that does not have a VLAN
associated with it. For cases when xapi does not respond,
retry again after a second.
During the times when xapi does not respond, set the value
as external_ids:bridge_id "".
Bug #17877.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
There are possibilities when records disappear underneath ovs-xapi-sync.
In this particular case, when VLAN network was deleted, the corresponding
record in bridge's external_ids:xs_network_ids column was not deleted by
xenserver. In situations like that handle the exceptions cleanly.
Bug #17390.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
For xenservers with version less than 6.1, interface reconfiguration
happened through interface-reconfigure scripts in this repo. In cases
where there were multiple xs-network-uuids for a single bridge,
interface-reconfigure script would add the network uuid associated
with the non-VLAN network as the first record. ovs-xapi-sync would
just blindly use the first record to create the bridge-id
But it looks like for xenserver 6.1, interface-reconfigure script
is no longer used and xenserver natively writes the xs-network-uuids.
So, in ovs-xapi-sync we no longer can copy the first value in
xs-network-uuids as bridge-id. This commit fetches the PIF record
for each xs-network-uuids and the network that does not have a VLAN
associated with it is copied over to bridge-id.
Bug #17090.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
This reverts commit 5902b4ed6.
For end users that do not plan to use tunnels or use only selected
tunnels, it probably is a bad idea to punch firewall holes by default.
Opening holes like this may surprise the user.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
The README file in xenserver directory currently misses information
about a few bugtool scripts. Add them.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
With single datapath, 'ovs-dpctl dump-flows ' dumps datapath flows for
all the userspace bridges in a system. It can get a little harder
to figure out the datapath flows belonging to a particular userspace
bridge.
This patch adds the 'ovs-appctl dpif/show' and 'ovs-appctl dpif/dump-flows'
output for each userspace bridge. This gives us a summary of configured
datapaths and all datapath flow entries for each bridge separately.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
This patch adds two new scripts that run "ovs-ofctl show" and
"ovs-ofctl dump-flows" on each bridge.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
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>
We use ovs-ctl from startup scripts to start, stop, restart,
force-reload-kmod OVS daemons. ovs-ctl gives quite a descriptive
o/p while running the above commands. But the o/p goes to stdout.
Sometimes, this output is quite useful to debug issues.
With this patch, we store the o/p of ovs-ctl when called from
startup scripts in /var/log/openvswitch/ovs-ctl.log
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Currently we do not include ovs-bugtool in xenserver rpms.
This is because xen-bugtool provides the information required
to debug openvswitch. But xen-bugtool also provides a lot more
data that is not required for openvswitch debugging. This makes
the debug bundle quite huge.
Also, xen-bugtool takes a lot of time to collect the required
information. For example, in my xenserver6.0.2 with 100 OVS
interfaces, 'xen-bugtool -y -s' takes 180 seconds to finish
creating a debug bundle with a size of 124M.
On the other hand, if we run a ovs-bugtool command of the form
'ovs-bugtool -y -s --log-days=10 --outfile bundle.tar.gz', it
takes 5 seconds to finish with a debug bundle size of 28M.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
The default values can be different and usually comes from /etc/logrotate.conf.
For xenserver6.0.2, the values in /etc/logrotate.conf is daily and compress.
So this patch does not make any difference. But it does future proof against
any changes in xenserver in the future.
For rhel6.1, the values are weekly and un-compress.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Currently brcompat does not work on master due to recent
datapath changes. We have decided to remove it as it is
not used very widely.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
ovs-ctl has a new command called "restart" which
saves and restores the openflow flows on bridges.
Use that command from the init scripts when doing
a "restart --save-flows=yes".
Also, the debian package postinst script can
set the variable OVS_RESTART_SAVE_FLOWS to "yes"
to ask for save and restore of flows.
Feature #13555.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
The new ovs-parse-backtrace utility makes the output of ovs-appctl
backtrace more human readable by removing duplicate traces and
converting addresses to function names.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
ovs-l3ping is similar to ovs-test, but the main difference
is that it does not require administrator to open firewall
holes for the XML/RPC control connection. This is achieved
by encapsulating the Control Connection over the L3 tunnel
itself.
This tool is not intended as a replacement for ovs-test,
because ovs-test covers much broader set of test cases.
Sample usage:
Node1: ovs-l3ping -s 192.168.122.236,10.1.1.1 -t gre
Node2: ovs-l3ping -c 192.168.122.220,10.1.1.2,10.1.1.1 -t gre
Issue#11791
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Replace the get_record() for network references which caused as many
slave-to-master calls as there are Network records plus one.
The get_all_records_where() call gets exactly what is needed with a single
call.
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Dominic Curran <dominic.curran@citrix.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The OVS Python daemons weren't reopening their log files after rotation, so
all the log information after the second rotation was lost.
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>
I wish to add some unixctl commands to the Python vlog module. However,
importing ovs.unixctl in ovs.vlog creates a circular dependency, because
ovs.unixctl imports ovs.vlog already. The solution, in this commit, is to
break the unixctl module into three parts: a register (ovs.unixctl) that
does not depend on ovs.vlog, and client (ovs.unixctl.client) and server
(ovs.unixctl.server) modules that do. This breaks the circular dependency.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is an enhancement in bugtool archive output to determine the bond
state information. It is implemented as a plugin which internally calls
"ovs-appctl bond/show" command to get bond state.
Feature #11283.
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
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>
This should make it more obvious when the admin needs to restart a DHCP
client (or other daemon). Without this, unless the admin carefully reads
the documentation, the first notice he gets about a need to restart the
DHCP client can easily be when the lease expires and the machine drops off
the network.
Bug #5391.
Tested-by: Gurucharan Shetty <gshetty@nicira.com>
Suggested-by: Duffie Cooley <dcooley@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Currently, when we upgrade the userspace rpm for XenServer,
we print a message asking users to reboot the hypervisor.
This is not needed. The reboot of hypervisor is needed when
we upgrade the rpm containing the kernel module. This
reboot can sometimes be avoided by running a
"service openvswitch force-reload-kmod".
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
This is an improvement in python script ovs-xapi-sync to call add_comment()
method while updating database. This will help developer to debug binaries
and database from ovsdb-tool show-log command output and understand which
python binary is updating db.
Feature #10543
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is an improvement in {ovs|xen}-bugtool archive output to determine the
version which was running for all the OVS daemons. It is implemented as a
plugin which internally calls "ovs-appctl -t <daemon> version" command for
daemons whose pid file is present in /var/run/openvswitch directory.
Feature #10383
Signed-off-by: Arun Sharma <arun.sharma@calsoftinc.com>
[blp@nicira.com updated debian/copyright.in]
Signed-off-by: Ben Pfaff <blp@nicira.com>
Somehow we forgot to put the md5sums for 5.6-SP2 so users were getting
scary error messages.
Bug #10210.
Reported-by: Ronald Lee <rlee@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
From early days, Nicira used the --with-build-number option to configure to
stamp our internal builds. We've since switched to another scheme, so
this option is obsolete.
Good riddance.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The recently added SchemaHelper class significantly simplifies IDL
instantiation in Python. This commit converts all users of the old
method to the new method, and removes support for the old method.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Typically Open vSwitch communicates with running processes using
unixctl. This patch converts ovs-xapi-sync to the strategy for
consistency.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Communicating with xapi from Python can be quite expensive so it
makes sense to cache this data if convenient.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
This renames the datapath modules:
openvswitch_mod -> openvswitch
brcompat_mod -> brcompat
The first makes the module name consistent with upstream, and the latter
is just for internal consistency. This makes tools, and documentation
refer to a common module name regardless if it's coming from upstream
linux or built from datapath/ as part of a local build.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Jesse Gross <jesse@nicira.com>
The logic in ovs-xapi-sync didn't handle the case where ovsdb-server sends
a database update before it replies to a transaction that ovs-xapi-sync
sent, like this:
ovs-xapi-sync ovsdb-server
------------- ------------
.
.
.
transaction request --->
<--- database contents update
<--- transaction reply
.
.
.
The update was not lost but ovs-xapi-sync would not process it until the
database changed again.
Bug #10082.
Reported-by: Krishna Miriyala <krishna@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The vm-id external id in the interface table will uniquely identify a VM
that is connected to a bridge through that interface.
In xenserver, this will have the same value as the external id - xs-vm-uuid
and can be overridden by setting the nicira-vm-id key in the other_config
field of VM record of XAPI.
Bug #10020.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
