X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=vswitchd%2Fvswitch.xml;h=141c5fe53e56fcf262fdd059e70502786f7ee579;hb=2b8e39ae83c28509accc56597da0fae1032aaaf1;hp=3b500151133182670fcffbf3f70ce50fe2e1198d;hpb=68eb03912212f272fbff8a358827ee4996f18b64;p=openvswitch
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 3b500151..141c5fe5 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -1,3 +1,4 @@
+
A database with this schema holds the configuration for one Open
vSwitch daemon. The root of the configuration for the daemon is
@@ -32,11 +33,20 @@
choose key names that are likely to be unique. The currently
defined common key-value pairs are:
- Key-value pairs that report statistics about a running Open_vSwitch
- daemon. The current implementation updates these counters
- periodically. In the future, we plan to, instead, update them only
- when they are queried (e.g. using an OVSDB
- The currently defined key-value pairs are listed below. Some Open
- vSwitch implementations may not support some statistics, in which
- case those key-value pairs are omitted.
-
@@ -65,21 +75,133 @@
system-uuid
xe host-list
.system-type
XenServer
or KVM
.system-version
5.6.0
on XenServer.system-id
xs-system-uuid
.xs-system-uuid
xe host-list
.select
- operation) and perhaps at other times, but not on any regular
- periodic basis.
load-average
cpu
+ Number of CPU processors, threads, or cores currently online and + available to the operating system on which Open vSwitch is + running, as an integer. This may be less than the number + installed, if some are not online or if they are not available to + the operating system. +
++ Open vSwitch userspace processes are not multithreaded, but the + Linux kernel-based datapath is. +
+ + +load_average
+ A comma-separated list of three floating-point numbers, + representing the system load average over the last 1, 5, and 15 + minutes, respectively. +
+memory
+ A comma-separated list of integers, each of which represents a + quantity of memory in kilobytes that describes the operating + system on which Open vSwitch is running. In respective order, + these values are: +
+ ++ On Linux, all five values can be determined and are included. On + other operating systems, only the first two values can be + determined, so the list will only have two values. +
+process_
name
+ One such key-value pair will exist for each running Open vSwitch
+ daemon process, with name replaced by the daemon's
+ name (e.g. process_ovs-vswitchd
). The value is a
+ comma-separated list of integers. The integers represent the
+ following, with memory measured in kilobytes and durations in
+ milliseconds:
+
+ The interpretation of some of these values depends on whether the + process was started with the . If it + was not, then the crash count will always be 0 and the two + durations will always be the same. If + was given, then the crash count may be positive; if it is, the + latter duration is the amount of time since the most recent crash + and restart. +
+ +
+ There will be one key-value pair for each file in Open vSwitch's
+ ``run directory'' (usually /var/run/openvswitch
)
+ whose name ends in .pid
, whose contents are a
+ process ID, and which is locked by a running process. The
+ name is taken from the pidfile's name.
+
+ Currently Open vSwitch is only able to obtain all of the above + detail on Linux systems. On other systems, the same key-value + pairs will be present but the values will always be the empty + string. +
+file_systems
+ A space-separated list of information on local, writable file + systems. Each item in the list describes one file system and + consists in turn of a comma-separated list of the following: +
+ +/
or /var/log
.
+ Any spaces or commas in the mount point are replaced by
+ underscores.+ This key-value pair is omitted if there are no local, writable + file systems or if Open vSwitch cannot obtain the needed + information. +
+network-uuids
bridge-id
xs-network-uuids
.xs-network-uuids
xe network-list
.fake-bridge-
,
- e.g. fake-bridge-network-uuids
.
+ e.g. fake-bridge-xs-network-uuids
.
@@ -442,7 +566,7 @@
tap
gre
remote_ip
, local_ip
, and
in_key
. Note that if two ports are defined that are
@@ -505,9 +629,14 @@
csum
false
to disable.true
to enable.pmtud
false
to disable.header_cache
false
to disable.capwap
remote_ip
and
+ local_ip
. If two ports are defined that are the same
+ except one includes local_ip
and the other does not,
+ the more specific one is matched first. CAPWAP support is not
+ available on all platforms. Currently it is only supported in the
+ Linux kernel module with kernel versions >= 2.6.25. The following
+ options may be specified in the column:
+ remote_ip
local_ip
tos
inherit
, in which case the ToS will be copied from
+ the inner packet if it is IPv4 or IPv6 (otherwise it will be
+ 0). Note that the ECN fields are always inherited. Default is
+ 0.ttl
inherit
, in which case the
+ TTL will be copied from the inner packet if it is IPv4 or IPv6
+ (otherwise it will be the system default, typically 64).
+ Default is the system default TTL.pmtud
false
to disable.header_cache
false
to disable.patch
+ Key-value pairs that report port status. Supported status
+ values are type
-dependent.
+
The only currently defined key-value pair is:
+source_ip
gre
or capwap
. Not
+ supported by all implementations.+ These settings control ingress policing for packets received on this + interface. On a physical interface, this limits the rate at which + traffic is allowed into the system from the outside; on a virtual + interface (one connected to a virtual machine), this limits the rate at + which the VM is able to transmit. +
++ Policing is a simple form of quality-of-service that simply drops + packets received in excess of the configured rate. Due to its + simplicity, policing is usually less accurate and less effective than + egress QoS (which is configured using the and tables). +
++ Policing is currently implemented only on Linux. The Linux + implementation uses a simple ``token bucket'' approach: +
++ Policing interacts badly with some network protocols, and especially + with fragmented IP packets. Suppose that there is enough network + activity to keep the bucket nearly empty all the time. Then this token + bucket algorithm will forward a single packet every so often, with the + period depending on packet size and on the configured rate. All of the + fragments of an IP packets are normally transmitted back-to-back, as a + group. In such a situation, therefore, only one of these fragments + will be forwarded and the rest will be dropped. IP does not provide + any way for the intended recipient to ask for only the remaining + fragments. In such a case there are two likely possibilities for what + will happen next: either all of the fragments will eventually be + retransmitted (as TCP will do), in which case the same problem will + recur, or the sender will not realize that its packet has been dropped + and data will simply be lost (as some UDP-based protocols will do). + Either way, it is possible that no forward progress will ever occur. +
+
+ Maximum rate for data received on this interface, in kbps. Data
+ received faster than this rate is dropped. Set to 0
+ (the default) to disable policing.
+
Maximum burst size for data received on this interface, in kb. The
default burst size if set to 0
is 1000 kb. This value
has no effect if
is 0
.
The burst size should be at least the size of the interface's - MTU.
-Maximum rate for data received on this interface, in kbps. Data
- received faster than this rate is dropped. Set to 0
to
- disable policing.
The meaning of ``ingress'' is from Open vSwitch's perspective. If - configured on a physical interface, then it limits the rate at which - traffic is allowed into the system from the outside. If configured - on a virtual interface that is connected to a virtual machine, then - it limits the rate at which the guest is able to transmit.
++ Specifying a larger burst size lets the algorithm be more forgiving, + which is important for protocols like TCP that react severely to + dropped packets. The burst size should be at least the size of the + interface's MTU. Specifying a value that is numerically at least as + large as 10% of helps TCP come + closer to achieving the full rate. +
attached-mac
MAC
+ field in the VIF record for this interface.iface-id
xs-vif-uuid
.- Key-value pairs for use by external frameworks that integrate - with Open vSwitch, rather than by Open vSwitch itself. System - integrators should either use the Open vSwitch development - mailing list to coordinate on common key-value definitions, or - choose key names that are likely to be unique. -
-- All of the currently defined key-value pairs specifically + Additionally the following key-value pairs specifically apply to an interface that represents a virtual Ethernet interface connected to a virtual machine. These key-value pairs should not be present for other types of interfaces. Keys whose names end @@ -592,20 +877,35 @@ UUIDs in RFC 4122 format. Other hypervisors may use other formats.
-The currently defined key-value pairs are:
+The currently defined key-value pairs for XenServer are:
vif-uuid
xs-vif-uuid
network-uuid
xs-network-uuid
vm-uuid
xs-vm-uuid
vif-mac
MAC
- field in the VIF record for this interface.openvswitch-ipsec
package for
+ Debian. The currently defined key-value pairs are:
+ ipsec_local_ip
gre
and the
+ ipsec_psk
key must
+ be set. The in_key
, out_key
, and
+ key
must not be
+ set.ipsec_psk
ipsec_local_ip
key must also be set.linux-htb
http://linux.die.net/man/8/tc-htb
) and the HTB manual
+ (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
)
+ for information on how this classifier works and how to configure it.
+