ovs-ctl - OVS startup helper script
] [ --dport=dport
program starts, stops, and checks the status of Open vSwitch
daemons. It is not meant to be invoked directly by system administrators but
to be called internally by system startup scripts.
Each of ovs-ctl
's commands is described separately below.
command starts Open vSwitch. It performs the following tasks:
- Loads the Open vSwitch kernel module. If this fails, and
the Linux bridge module is loaded but no bridges exist, it tries to unload
the bridge module and tries loading the Open vSwitch kernel module again.
(This is because the Open vSwitch kernel module cannot coexist with the
Linux bridge module before 2.6.37.)
command skips the following steps if ovsdb-server
- If the Open vSwitch database file does not exist, it
creates it. If the database does exist, but it has an obsolete version, it
upgrades it to the latest schema.
- Starts ovsdb-server, unless the
--no-ovsdb-server command option is given.
- Initializes a few values inside the database.
- If the --delete-bridges option was used, deletes all
of the bridges from the database.
- If the --delete-transient-ports option was used,
deletes all ports that have other_config:transient set to
command skips the following step if ovs-vswitchd
already running, or if the --no-ovs-vswitchd
command option is given:
- Starts ovs-vswitchd.
Several command-line options influence the start
command's behavior. Some
form of the following option should ordinarily be specified:
- This specifies a unique system identifier to store into
external-ids:system-id in the database's Open_vSwitch table.
Remote managers that talk to the Open vSwitch database server over network
protocols use this value to identify and distinguish Open vSwitch
instances, so it should be unique (at least) within OVS instances that
will connect to a single controller.
- When random is specified, ovs-ctl will
generate a random ID that persists from one run to another (stored in a
file). When another string is specified ovs-ctl uses it
The following options should be specified if the defaults are not suitable:
- Sets the value to store in the system-type and
system-version columns, respectively, in the database's
Open_vSwitch table. Remote managers may use these values to
determine the kind of system to which they are connected (primarily for
display to human administrators).
- When not specified, ovs-ctl uses values from the
optional system-type.conf and system-version.conf files(see
section FILES) or it uses the lsb_release program, if
present, to provide reasonable defaults.
The following options are also likely to be useful:
- Sets external-ids:name to value in the
database's Open_vSwitch table. Specifying this option multiple
times adds multiple key-value pairs.
- Ordinarily Open vSwitch bridges persist from one system
boot to the next, as long as the database is preserved. Some environments
instead expect to re-create all of the bridges and other configuration
state on every boot. This option supports that, by deleting all Open
vSwitch bridges after starting ovsdb-server but before starting
- Deletes all ports that have the other_config:transient
value set to true. This is important on certain environments where some
ports are going to be recreated after reboot, but other ports need to be
persisted in the database.
- Ordinarily Open vSwitch daemons are started as the user
invoking the ovs-ctl command. Some system administrators would prefer to
have the various daemons spawn as different users in their environments.
This option allows passing the --user option to the
ovsdb-server and ovs-vswitchd daemons, allowing them to
change their privilege levels.
The following options are less important:
- By default ovs-ctl passes --monitor to
ovs-vswitchd and ovsdb-server, requesting that it spawn a
process monitor which will restart the daemon if it crashes. This option
suppresses that behavior.
- Specifies the current working directory that the OVS
daemons should run from. The default is / (the root directory) if
this option is not specified. (This option is useful because most systems
create core files in a process's current working directory and because a
file system that is in use as a process's current working directory cannot
- By default, ovs-ctl enables core dumps for the OVS
daemons. This option disables that behavior.
- By default ovs-ctl passes --mlockall to
ovs-vswitchd, requesting that it lock all of its virtual memory,
preventing it from being paged to disk. This option suppresses that
- Disable self-confinement for ovs-vswitchd and
ovsdb-server daemons. This flag may be used when, for example,
OpenFlow controller creates its Unix Domain Socket outside OVS run
directory and OVS needs to connect to it. It is better to stick with the
default behavior and not to use this flag, unless:
- You have Open vSwitch running under SELinux or AppArmor
Mandatory Access Control that would prevent OVS from messing with sockets
outside ordinary OVS directories.
- You believe that relying on protocol handshakes (e.g.
OpenFlow) is enough to prevent OVS to adversely interact with other
daemons running on your system.
- You don't have much worries of remote OVSDB exploits in the
first place, because, perhaps, OVSDB manager is running on the same host
as OVS and share similar attack vectors.
- Sets the nice(1) level used for each daemon. All of
them default to -10.
- Configures the specified daemon to run under
wrapper, which is one of the following:
- Run the daemon under valgrind(1), if it is
installed, logging to daemon.valgrind.log.pid in the
- Run the daemon under strace(1), if it is installed,
logging to daemon.strace.log.pid in the log
- Enable GNU C library features designed to find memory
- By default, no wrapper is used.
- Each of the wrappers can expose bugs in Open vSwitch that
lead to incorrect operation, including crashes. The valgrind and
strace wrappers greatly slow daemon operations so they should not
be used in production. They also produce voluminous logs that can quickly
fill small disk partitions. The glibc wrapper is less
resource-intensive but still somewhat slows the daemons.
The following options control file locations. They should only be used if the
default locations cannot be used. See FILES
, below, for more
- Overrides the file name for the OVS database.
- Overrides the file name for the Unix domain socket used to
connect to ovsdb-server.
- Overrides the file name for the OVS database schema.
- Adds file as an extra database for
ovsdb-server to serve out. Multiple space-separated file names may
also be specified. file should begin with /; if it does not,
then it will be taken as relative to dbdir.
command does not unload the Open vSwitch kernel modules. It can
take the same --no-ovsdb-server
that of the start
This command does nothing and finishes successfully if the OVS daemons aren't
command performs a stop
followed by a start
command. The command can take the same options as that of the start
command. In addition, it saves and restores OpenFlow flows for each individual
command checks whether the OVS daemons ovs-vswitchd
are running and prints messages with that information. It
exits with status 0 if the daemons are running, 1 otherwise.
command runs ovsdb-server --version
command allows upgrading the Open vSwitch kernel
module without rebooting. It performs the following tasks:
- Gets a list of OVS ``internal'' interfaces, that is,
network devices implemented by Open vSwitch. The most common examples of
these are bridge ``local ports''.
- Saves the OpenFlow flows of each bridge.
- Stops the Open vSwitch daemons, as if by a call to
- Saves the kernel configuration state of the OVS internal
interfaces listed in step 1, including IP and IPv6 addresses and routing
- Unloads the Open vSwitch kernel module (including the
bridge compatibility module if it is loaded).
- Starts OVS back up, as if by a call to ovs-ctl
start. This reloads the kernel module, restarts the OVS daemons and
finally restores the saved OpenFlow flows.
- Restores the kernel configuration state that was saved in
- Checks for daemons that may need to be restarted because
they have packet sockets that are listening on old instances of Open
vSwitch kernel interfaces and, if it finds any, prints a warning on
stdout. DHCP is a common example: if the ISC DHCP client is running on an
OVS internal interface, then it will have to be restarted after completing
the above procedure. (It would be nice if ovs-ctl could restart
daemons automatically, but the details are far too specific to a
particular distribution and installation.)
internally stops and starts OVS, so it accepts all of
the options accepted by the start
command except for the
command loads the openvswitch kernel modules if they are
not already loaded. This operation also occurs as part of the start
command. The motivation for providing the load-kmod
command is to allow
errors when loading modules to be handled separatetly from other errors that
may occur when running the start
By default the load-kmod
command attempts to load the openvswitch kernel
command checks for rules related to a specified
protocol in the system's iptables
(8) configuration. If there are no
rules specifically related to that protocol, then it inserts a rule to accept
the specified protocol.
- If iptables is not installed or not enabled, this
command does nothing, assuming that lack of filtering means that the
protocol is enabled.
- If the INPUT chain has a rule that matches the
specified protocol, then this command does nothing, assuming that whatever
rule is installed reflects the system administrator's decisions.
- Otherwise, this command installs a rule that accepts
traffic of the specified protocol.
This command normally completes successfully, even if it does nothing. Only the
failure of an attempt to insert a rule normally causes it to return an exit
code other than 0. The following options control the protocol to be enabled:
- The name of the IP protocol to be enabled, such as
gre or tcp. The default is gre.
- TCP or UDP source or destination port to match. These are
optional and allowed only with --protocol=tcp or
Prints a usage message and exits successfully.
In addition to the options listed for each command above, these options control
the behavior of several of ovs-ctl
By default, ovs-ctl
will control the ovsdb-server
, and the
daemons. The following options restrict that control to
exclude one or the other:
- Specifies that the ovs-ctl commands start,
stop, and restart should not modify the running status of
- Specifies that the ovs-ctl commands start,
stop, and restart should not modify the running status of
ovs-vswitchd. It is an error to include this option with the
exits with status 0 on success and nonzero on failure. The
command is considered to succeed if OVS is already started; the
command is considered to succeed if OVS is already stopped.
The following environment variables affect ovs-ctl
- ovs-ctl does not hardcode the location of any of the
programs that it runs. ovs-ctl will add the sbindir and
bindir that were specified at configure time to PATH,
if they are not already present.
- Setting one of these variables in the environment overrides
the respective configure option, both for ovs-ctl itself and
for the other Open vSwitch programs that it runs.
uses the following files:
- Shell function library used internally by ovs-ctl.
It must be installed in the same directory as ovs-ctl.
- Per-daemon logfiles.
- Per-daemon pidfiles to track whether a daemon is running
and with what process ID.
- The OVS database schema used to initialize the database
(use --db-schema to override this location).
- The OVS database (use --db-file to override this
- The Unix domain socket used for local communication with
ovsdb-server (use --db-sock to override this location).
- The persistent system UUID created and read by
- The system-type and system-version values
stored in the database's Open_vSwitch table when not specified as a
The files debian/openvswitch-switch.init
in the Open vSwitch source
distribution are good examples of how to use ovs-ctl