ovs-ctl --system-id=random|<uuid> [<options>] start
ovs-ctl --system-id=random|<uuid> [<options>] restart
ovs-ctl [<options>] load-kmod
ovs-ctl --system-id=random|<uuid> [<options>] force-reload-kmod
ovs-ctl [--protocol=<protocol>] [--sport=<sport>] [--dport=<dport>]
ovs-ctl help | -h | --help
ovs-ctl 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
ovs-ctl command is described separately below.
start command starts Open vSwitch. It performs the
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.)
start command skips the following steps if
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.
ovsdb-server, unless the
--no-ovsdb-servercommand option is given.
Initializes a few values inside the database.
--delete-bridgesoption was used, deletes all of the bridges from the database.
--delete-transient-portsoption was used, deletes all ports that have
other_config:transientset to true.
start command skips the following step if
already running, or if the
--no-ovs-vswitchd command option is
Several command-line options influence the
behavior. Some form of the following option should ordinarily be
This specifies a unique system identifier to store into
external-ids:system-idin the database’s
Open_vSwitchtable. 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.
ovs-ctlwill generate a random ID that persists from one run to another (stored in a file). When another string is specified
ovs-ctluses it literally.
The following options should be specified if the defaults are not suitable:
Sets the value to store in the
system-versioncolumns, respectively, in the database’s
Open_vSwitchtable. Remote managers may use these values too determine the kind of system to which they are connected (primarily for display to human administrators).
When not specified,
ovs-ctluses values from the optional
system-version.conffiles (see Files) or it uses the
lsb_releaseprogram, if present, to provide reasonable defaults.
The following options are also likely to be useful:
external-ids:<name>to <value> in the database’s
Open_vSwitchtable. 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-serverbut before starting
Deletes all ports that have
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
--useroption to the
ovs-vswitchddaemons, allowing them to change their privilege levels.
The following options are less important:
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 be unmounted.)
ovs-ctlenables core dumps for the OVS daemons. This option disables that behavior.
ovs-vswitchd, requesting that it lock all of its virtual memory, preventing it from being paged to disk. This option suppresses that behavior.
Disable self-confinement for
ovsdb-serverdaemons. 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.
nice(1)level used for each daemon. All of them default to
Configures the specified daemon to run under <wrapper>, which is one of the following:
valgrind: Run the daemon under
valgrind(1), if it is installed, logging to
<daemon>.valgrind.log.<pid>in the log directory.
strace: Run the daemon under
strace(1), if it is installed, logging to
<daemon>.strace.log.<pid>in the log directory.
glibc: Enable GNU C library features designed to find memory errors.
By default, no wrapper is used.
Each of the wrappers can expose bugs in Open vSwitch that lead to incorrect operation, including crashes. The
stracewrappers 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
glibcwrapper 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
for more information.
Overrides the file name for the OVS database.
Overrides the file name for the Unix domain socket used to connect to
Overrides the file name for the OVS database schema.
Adds <file> as an extra database for
ovsdb-serverto 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>.
stop command stops the
daemons. It does not unload the Open vSwitch kernel modules. It can
take the same
as that of the
This command does nothing and finishes successfully if the OVS daemons aren’t running.
restart command performs a
stop followed by a
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 bridge.
status command checks whether the OVS daemons
ovsdb-server are running and prints
messages with that information. It exits with status 0 if
the daemons are running, 1 otherwise.
version command runs
ovsdb-server --version and
force-reload-kmod 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 table entries.
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 step 4.
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-ctlcould restart daemons automatically, but the details are far too specific to a particular distribution and installation.)
force-kmod-reload internally stops and starts OVS, so it accepts
all of the options accepted by the
start command except for the
load-kmod 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
command is to allow errors when loading modules to be handled
separately from other errors that may occur when running the
By default the
load-kmod command attempts to load the
openvswitch kernel module.
enable-protocol 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.
iptablesis not installed or not enabled, this command does nothing, assuming that lack of filtering means that the protocol is enabled.
INPUTchain 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
tcp. The default is
TCP or UDP source or destination port to match. These are optional and allowed only with
Deletes all ports that have the
other_config:transient value set to true.
Prints a usage message and exits successfully.
In addition to the options listed for each command above, these
options control the behavior of several
ovs-ctl controls the
ovs-vswitchd daemons. The following options restrict that control
to exclude one or the other:
Specifies that the
restartshould not modify the running status of
Specifies that the
restartshould not modify the running status of
ovs-vswitchd. It is an error to include this option with the
ovs-ctl exits with status 0 on success and nonzero on failure.
start command is considered to succeed if OVS is already
stop command is considered to succeed if OVS is
The following environment variables affect
ovs-ctldoes not hardcode the location of any of the programs that it runs.
ovs-ctlwill add the <sbindir> and <bindir> that were specified at
PATH, if they are not already present.
Setting one of these variables in the environment overrides the respective
configureoption, both for
ovs-ctlitself and for the other Open vSwitch programs that it runs.
ovs-ctl uses the following files:
Shell function library used internally by
ovs-ctl. It must be installed in the same directory as
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-schemato override this location).
The OVS database (use
--db-fileto override this location).
The Unix domain socket used for local communication with
--db-sockto override this location).
The persistent system UUID created and read by
system-versionvalues stored in the database’s
Open_vSwitchtable when not specified as a command-line option.
debian/openvswitch-switch.init in the Open vSwitch source
distribution is a good example of how to use