1.

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.)

2.

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.

3.

Starts ovsdb-server, unless the --no-ovsdb-server command option is given.

4.

Initializes a few values inside the database.

5.

If the --delete-bridges option was used, deletes all of the bridges from the database.

6.

If the --delete-transient-ports option was used, deletes all ports that have other_config:transient set to true.

7.

Starts ovs-vswitchd.

•

--system-id=<uuid> or --system-id=random

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 literally.

•

--system-type=<type> or --system-version=<version>

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 too 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 Files) or it uses the lsb_release program, if present, to provide reasonable defaults.

• --external-id="<name>=<value>"

  Sets external-ids:<name> to <value> in the database’s Open_vSwitch table. Specifying this option multiple times adds multiple key-value pairs.

• --delete-bridges

  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 ovs-vswitchd.

• --delete-transient-ports

  Deletes all ports that have other_config:transient 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.

• --ovs-user=user[:group]

  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.

• --no-monitor

  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.

• --daemon-cwd=<directory>

  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.)

• --no-force-corefiles

  By default, ovs-ctl enables core dumps for the OVS daemons. This option disables that behavior.

• --no-mlockall

  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 behavior.

• --no-self-confinement

  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:

• --ovsdb-server-priority=<niceness> or --ovs-vswitchd-priority=<niceness>

  Sets the nice(1) level used for each daemon. All of them default to -10.

• --ovsdb-server-wrapper=<wrapper> or --ovs-vswitchd-wrapper=<wrapper>

  Configures the specified daemon to run under <wrapper>, which is one of the following:

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.

• --db-file=<file>

  Overrides the file name for the OVS database.

• --db-sock=<socket>

  Overrides the file name for the Unix domain socket used to connect to ovsdb-server.

• --db-schema=<schema>

  Overrides the file name for the OVS database schema.

• --extra-dbs=<file>

  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>.

1.

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”.

2.

Saves the OpenFlow flows of each bridge.

3.

Stops the Open vSwitch daemons, as if by a call to ovs-ctl stop.

4.

Saves the kernel configuration state of the OVS internal interfaces listed in step 1, including IP and IPv6 addresses and routing table entries.

5.

Unloads the Open vSwitch kernel module (including the bridge compatibility module if it is loaded).

6.

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.

7.

Restores the kernel configuration state that was saved in step 4.

8.

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.)

• 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.

• --protocol=<protocol>

  The name of the IP protocol to be enabled, such as gre or tcp. The default is gre.

• --sport=<sport> or --dport=<dport>

  TCP or UDP source or destination port to match. These are optional and allowed only with --protocol=tcp or --protocol=udp.