/
vswitch.xml
5609 lines (4973 loc) · 231 KB
/
vswitch.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<database name="ovs-vswitchd.conf.db" title="Open vSwitch Configuration Database">
<p>
A database with this schema holds the configuration for one Open
vSwitch daemon. The top-level configuration for the daemon is the
<ref table="Open_vSwitch"/> table, which must have exactly one
record. Records in other tables are significant only when they
can be reached directly or indirectly from the <ref
table="Open_vSwitch"/> table. Records that are not reachable from
the <ref table="Open_vSwitch"/> table are automatically deleted
from the database, except for records in a few distinguished
``root set'' tables.
</p>
<h2>Common Columns</h2>
<p>
Most tables contain two special columns, named <code>other_config</code>
and <code>external_ids</code>. These columns have the same form and
purpose each place that they appear, so we describe them here to save space
later.
</p>
<dl>
<dt><code>other_config</code>: map of string-string pairs</dt>
<dd>
<p>
Key-value pairs for configuring rarely used features. Supported keys,
along with the forms taken by their values, are documented individually
for each table.
</p>
<p>
A few tables do not have <code>other_config</code> columns because no
key-value pairs have yet been defined for them.
</p>
</dd>
<dt><code>external_ids</code>: map of string-string pairs</dt>
<dd>
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. In some cases, where key-value pairs have been defined that are
likely to be widely useful, they are documented individually for each
table.
</dd>
</dl>
<table name="Open_vSwitch" title="Open vSwitch configuration.">
Configuration for an Open vSwitch daemon. There must be exactly
one record in the <ref table="Open_vSwitch"/> table.
<group title="Configuration">
<column name="bridges">
Set of bridges managed by the daemon.
</column>
<column name="ssl">
SSL used globally by the daemon.
</column>
<column name="external_ids" key="system-id">
A unique identifier for the Open vSwitch's physical host.
The form of the identifier depends on the type of the host.
On a Citrix XenServer, this will likely be the same as
<ref column="external_ids" key="xs-system-uuid"/>.
</column>
<column name="external_ids" key="xs-system-uuid">
The Citrix XenServer universally unique identifier for the physical
host as displayed by <code>xe host-list</code>.
</column>
<column name="external_ids" key="hostname">
The hostname for the host running Open vSwitch. This is a fully
qualified domain name since version 2.6.2.
</column>
<column name="external_ids" key="rundir">
In Open vSwitch 2.8 and later, the run directory of the running Open
vSwitch daemon. This directory is used for runtime state such as
control and management sockets. The value of <ref
column="other_config" key="vhost-sock-dir"/> is relative to this
directory.
</column>
<column name="other_config" key="stats-update-interval"
type='{"type": "integer", "minInteger": 5000}'>
<p>
Interval for updating statistics to the database, in milliseconds.
This option will affect the update of the <code>statistics</code>
column in the following tables: <code>Port</code>, <code>Interface
</code>, <code>Mirror</code>.
</p>
<p>
Default value is 5000 ms.
</p>
<p>
Getting statistics more frequently can be achieved via OpenFlow.
</p>
</column>
<column name="other_config" key="flow-restore-wait"
type='{"type": "boolean"}'>
<p>
When <code>ovs-vswitchd</code> starts up, it has an empty flow table
and therefore it handles all arriving packets in its default fashion
according to its configuration, by dropping them or sending them to
an OpenFlow controller or switching them as a standalone switch.
This behavior is ordinarily desirable. However, if
<code>ovs-vswitchd</code> is restarting as part of a ``hot-upgrade,''
then this leads to a relatively long period during which packets are
mishandled.
</p>
<p>
This option allows for improvement. When <code>ovs-vswitchd</code>
starts with this value set as <code>true</code>, it will neither
flush or expire previously set datapath flows nor will it send and
receive any packets to or from the datapath. When this value is
later set to <code>false</code>, <code>ovs-vswitchd</code> will
start receiving packets from the datapath and re-setup the flows.
</p>
<p>
Thus, with this option, the procedure for a hot-upgrade of
<code>ovs-vswitchd</code> becomes roughly the following:
</p>
<ol>
<li>
Stop <code>ovs-vswitchd</code>.
</li>
<li>
Set <ref column="other_config" key="flow-restore-wait"/>
to <code>true</code>.
</li>
<li>
Start <code>ovs-vswitchd</code>.
</li>
<li>
Use <code>ovs-ofctl</code> (or some other program, such as an
OpenFlow controller) to restore the OpenFlow flow table
to the desired state.
</li>
<li>
Set <ref column="other_config" key="flow-restore-wait"/>
to <code>false</code> (or remove it entirely from the database).
</li>
</ol>
<p>
The <code>ovs-ctl</code>'s ``restart'' and ``force-reload-kmod''
functions use the above config option during hot upgrades.
</p>
</column>
<column name="other_config" key="flow-limit"
type='{"type": "integer", "minInteger": 0}'>
<p>
The maximum
number of flows allowed in the datapath flow table. Internally OVS
will choose a flow limit which will likely be lower than this number,
based on real time network conditions. Tweaking this value is
discouraged unless you know exactly what you're doing.
</p>
<p>
The default is 200000.
</p>
</column>
<column name="other_config" key="max-idle"
type='{"type": "integer", "minInteger": 500}'>
<p>
The maximum time (in ms) that idle flows will remain cached in the
datapath. Internally OVS will check the validity and activity for
datapath flows regularly and may expire flows quicker than this
number, based on real time network conditions. Tweaking this
value is discouraged unless you know exactly what you're doing.
</p>
<p>
The default is 10000.
</p>
</column>
<column name="other_config" key="hw-offload"
type='{"type": "boolean"}'>
<p>
Set this value to <code>true</code> to enable netdev flow offload.
</p>
<p>
The default value is <code>false</code>. Changing this value requires
restarting the daemon
</p>
<p>
Currently Open vSwitch supports hardware offloading on
Linux systems. On other systems, this value is ignored.
This functionality is considered 'experimental'. Depending
on which OpenFlow matches and actions are configured,
which kernel version is used, and what hardware is
available, Open vSwitch may not be able to offload
functionality to hardware.
</p>
</column>
<column name="other_config" key="tc-policy"
type='{"type": "string"}'>
<p>
Specified the policy used with HW offloading.
Options:
<code>none</code> - Add software rule and offload rule to HW.
<code>skip_sw</code> - Offload rule to HW only.
<code>skip_hw</code> - Add software rule without offloading rule to HW.
</p>
<p>
This is only relevant if HW offloading is enabled (hw-offload).
</p>
<p>
The default value is <code>none</code>.
</p>
</column>
<column name="other_config" key="dpdk-init"
type='{"type": "string"}'>
<p>
Set this value to <code>true</code> or <code>try</code> to enable
runtime support for DPDK ports. The vswitch must have compile-time
support for DPDK as well.
</p>
<p>
A value of <code>true</code> will cause the ovs-vswitchd process to
abort if DPDK cannot be initialized. A value of <code>try</code>
will allow the ovs-vswitchd process to continue running even if DPDK
cannot be initialized.
</p>
<p>
The default value is <code>false</code>. Changing this value requires
restarting the daemon
</p>
<p>
If this value is <code>false</code> at startup, any dpdk ports which
are configured in the bridge will fail due to memory errors.
</p>
</column>
<column name="other_config" key="dpdk-lcore-mask"
type='{"type": "integer", "minInteger": 1}'>
<p>
Specifies the CPU cores where dpdk lcore threads should be spawned.
The DPDK lcore threads are used for DPDK library tasks, such as
library internal message processing, logging, etc. Value should be in
the form of a hex string (so '0x123') similar to the 'taskset' mask
input.
</p>
<p>
The lowest order bit corresponds to the first CPU core. A set bit
means the corresponding core is available and an lcore thread will be
created and pinned to it. If the input does not cover all cores,
those uncovered cores are considered not set.
</p>
<p>
For performance reasons, it is best to set this to a single core on
the system, rather than allow lcore threads to float.
</p>
<p>
If not specified, the value will be determined by choosing the lowest
CPU core from initial cpu affinity list. Otherwise, the value will be
passed directly to the DPDK library.
</p>
</column>
<column name="other_config" key="pmd-cpu-mask">
<p>
Specifies CPU mask for setting the cpu affinity of PMD (Poll
Mode Driver) threads. Value should be in the form of hex string,
similar to the dpdk EAL '-c COREMASK' option input or the 'taskset'
mask input.
</p>
<p>
The lowest order bit corresponds to the first CPU core. A set bit
means the corresponding core is available and a pmd thread will be
created and pinned to it. If the input does not cover all cores,
those uncovered cores are considered not set.
</p>
<p>
If not specified, one pmd thread will be created for each numa node
and pinned to any available core on the numa node by default.
</p>
</column>
<column name="other_config" key="dpdk-alloc-mem"
type='{"type": "integer", "minInteger": 0}'>
<p>
Specifies the amount of memory to preallocate from the hugepage pool,
regardless of socket. It is recommended that dpdk-socket-mem is used
instead.
</p>
</column>
<column name="other_config" key="dpdk-socket-mem"
type='{"type": "string"}'>
<p>
Specifies the amount of memory to preallocate from the hugepage pool,
on a per-socket basis.
</p>
<p>
The specifier is a comma-separated string, in ascending order of CPU
socket. E.g. On a four socket system 1024,0,2048 would set socket 0
to preallocate 1024MB, socket 1 to preallocate 0MB, socket 2 to
preallocate 2048MB and socket 3 (no value given) to preallocate 0MB.
</p>
<p>
If dpdk-socket-mem and dpdk-alloc-mem are not specified, dpdk-socket-mem
will be used and the default value is 1024 for each numa node. If
dpdk-socket-mem and dpdk-alloc-mem are specified at same time,
dpdk-socket-mem will be used as default. Changing this value
requires restarting the daemon.
</p>
</column>
<column name="other_config" key="dpdk-hugepage-dir"
type='{"type": "string"}'>
<p>
Specifies the path to the hugetlbfs mount point.
</p>
<p>
If not specified, this will be guessed by the DPDK library (default
is /dev/hugepages). Changing this value requires restarting the
daemon.
</p>
</column>
<column name="other_config" key="dpdk-extra"
type='{"type": "string"}'>
<p>
Specifies additional eal command line arguments for DPDK.
</p>
<p>
The default is empty. Changing this value requires restarting the
daemon
</p>
</column>
<column name="other_config" key="vhost-sock-dir"
type='{"type": "string"}'>
<p>
Specifies a relative path from <ref column="external_ids"
key="rundir"/> to the vhost-user unix domain socket files. If this
value is unset, the sockets are put directly in <ref
column="external_ids" key="rundir"/>.
</p>
<p>
Changing this value requires restarting the daemon.
</p>
</column>
<column name="other_config" key="vhost-iommu-support"
type='{"type": "boolean"}'>
<p>
vHost IOMMU is a security feature, which restricts the vhost memory
that a virtio device may access. vHost IOMMU support is disabled by
default, due to a bug in QEMU implementations of the vhost REPLY_ACK
protocol, (on which vHost IOMMU relies) prior to v2.9.1. Setting this
value to <code>true</code> enables vHost IOMMU support for vHost User
Client ports in OvS-DPDK, starting from DPDK v17.11.
</p>
<p>
Changing this value requires restarting the daemon.
</p>
</column>
<column name="other_config" key="per-port-memory"
type='{"type": "boolean"}'>
<p>
By default OVS DPDK uses a shared memory model wherein devices
that have the same MTU and socket values can share the same
mempool. Setting this value to <code>true</code> changes this
behaviour. Per port memory allow DPDK devices to use private
memory per device. This can provide greater transparency as
regards memory usage but potentially at the cost of greater memory
requirements.
</p>
<p>
Changing this value requires restarting the daemon if dpdk-init has
already been set to true.
</p>
</column>
<column name="other_config" key="tx-flush-interval"
type='{"type": "integer",
"minInteger": 0, "maxInteger": 1000000}'>
<p>
Specifies the time in microseconds that a packet can wait in output
batch for sending i.e. amount of time that packet can spend in an
intermediate output queue before sending to netdev.
This option can be used to configure balance between throughput
and latency. Lower values decreases latency while higher values
may be useful to achieve higher performance.
</p>
<p>
Defaults to 0 i.e. instant packet sending (latency optimized).
</p>
</column>
<column name="other_config" key="pmd-perf-metrics"
type='{"type": "boolean"}'>
<p>
Enables recording of detailed PMD performance metrics for analysis
and trouble-shooting. This can have a performance impact in the
order of 1%.
</p>
<p>
Defaults to false but can be changed at any time.
</p>
</column>
<column name="other_config" key="smc-enable"
type='{"type": "boolean"}'>
<p>
Signature match cache or SMC is a cache between EMC and megaflow
cache. It does not store the full key of the flow, so it is more
memory efficient comparing to EMC cache. SMC is especially useful
when flow count is larger than EMC capacity.
</p>
<p>
Defaults to false but can be changed at any time.
</p>
</column>
<column name="other_config" key="n-handler-threads"
type='{"type": "integer", "minInteger": 1}'>
<p>
Specifies the number of threads for software datapaths to use for
handling new flows. The default the number of online CPU cores minus
the number of revalidators.
</p>
<p>
This configuration is per datapath. If you have more than one
software datapath (e.g. some <code>system</code> bridges and some
<code>netdev</code> bridges), then the total number of threads is
<code>n-handler-threads</code> times the number of software
datapaths.
</p>
</column>
<column name="other_config" key="n-revalidator-threads"
type='{"type": "integer", "minInteger": 1}'>
<p>
Specifies the number of threads for software datapaths to use for
revalidating flows in the datapath. Typically, there is a direct
correlation between the number of revalidator threads, and the number
of flows allowed in the datapath. The default is the number of cpu
cores divided by four plus one. If <code>n-handler-threads</code> is
set, the default changes to the number of cpu cores minus the number
of handler threads.
</p>
<p>
This configuration is per datapath. If you have more than one
software datapath (e.g. some <code>system</code> bridges and some
<code>netdev</code> bridges), then the total number of threads is
<code>n-handler-threads</code> times the number of software
datapaths.
</p>
</column>
<column name="other_config" key="emc-insert-inv-prob"
type='{"type": "integer", "minInteger": 0, "maxInteger": 4294967295}'>
<p>
Specifies the inverse probability (1/emc-insert-inv-prob) of a flow
being inserted into the Exact Match Cache (EMC). On average one in
every <code>emc-insert-inv-prob</code> packets that generate a unique
flow will cause an insertion into the EMC.
A value of 1 will result in an insertion for every flow (1/1 = 100%)
whereas a value of zero will result in no insertions and essentially
disable the EMC.
</p>
<p>
Defaults to 100 ie. there is (1/100 =) 1% chance of EMC insertion.
</p>
</column>
<column name="other_config" key="vlan-limit"
type='{"type": "integer", "minInteger": 0}'>
<p>
Limits the number of VLAN headers that can be matched to the
specified number. Further VLAN headers will be treated as payload,
e.g. a packet with more 802.1q headers will match Ethernet type
0x8100.
</p>
<p>
Value <code>0</code> means unlimited. The actual number of supported
VLAN headers is the smallest of <code>vlan-limit</code>, the number
of VLANs supported by Open vSwitch userspace (currently 2), and the
number supported by the datapath.
</p>
<p>
If this value is absent, the default is currently 1. This maintains
backward compatibility with controllers that were designed for use
with Open vSwitch versions earlier than 2.8, which only supported one
VLAN.
</p>
</column>
<column name="other_config" key="bundle-idle-timeout"
type='{"type": "integer", "minInteger": 1}'>
<p>
The maximum time (in seconds) that idle bundles will wait
to be expired since it was either opened, modified or closed.
</p>
<p>
OpenFlow specification mandates the timeout to be at least one
second. The default is 10 seconds.
</p>
</column>
</group>
<group title="Status">
<column name="next_cfg">
Sequence number for client to increment. When a client modifies
any part of the database configuration and wishes to wait for
Open vSwitch to finish applying the changes, it may increment
this sequence number.
</column>
<column name="cur_cfg">
Sequence number that Open vSwitch sets to the current value of
<ref column="next_cfg"/> after it finishes applying a set of
configuration changes.
</column>
<column name="dpdk_initialized">
True if <ref column="other_config" key="dpdk-init"/> is set to
true and the DPDK library is successfully initialized.
</column>
<group title="Statistics">
<p>
The <code>statistics</code> column contains key-value pairs that
report statistics about a system running an Open vSwitch. These are
updated periodically (currently, every 5 seconds). Key-value pairs
that cannot be determined or that do not apply to a platform are
omitted.
</p>
<column name="other_config" key="enable-statistics"
type='{"type": "boolean"}'>
Statistics are disabled by default to avoid overhead in the common
case when statistics gathering is not useful. Set this value to
<code>true</code> to enable populating the <ref column="statistics"/>
column or to <code>false</code> to explicitly disable it.
</column>
<column name="statistics" key="cpu"
type='{"type": "integer", "minInteger": 1}'>
<p>
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.
</p>
<p>
Open vSwitch userspace processes are not multithreaded, but the
Linux kernel-based datapath is.
</p>
</column>
<column name="statistics" key="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.
</column>
<column name="statistics" key="memory">
<p>
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:
</p>
<ol>
<li>Total amount of RAM allocated to the OS.</li>
<li>RAM allocated to the OS that is in use.</li>
<li>RAM that can be flushed out to disk or otherwise discarded
if that space is needed for another purpose. This number is
necessarily less than or equal to the previous value.</li>
<li>Total disk space allocated for swap.</li>
<li>Swap space currently in use.</li>
</ol>
<p>
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.
</p>
</column>
<column name="statistics" key="process_NAME">
<p>
One such key-value pair, with <code>NAME</code> replaced by
a process name, will exist for each running Open vSwitch
daemon process, with <var>name</var> replaced by the
daemon's name (e.g. <code>process_ovs-vswitchd</code>). The
value is a comma-separated list of integers. The integers
represent the following, with memory measured in kilobytes
and durations in milliseconds:
</p>
<ol>
<li>The process's virtual memory size.</li>
<li>The process's resident set size.</li>
<li>The amount of user and system CPU time consumed by the
process.</li>
<li>The number of times that the process has crashed and been
automatically restarted by the monitor.</li>
<li>The duration since the process was started.</li>
<li>The duration for which the process has been running.</li>
</ol>
<p>
The interpretation of some of these values depends on whether the
process was started with the <option>--monitor</option>. If it
was not, then the crash count will always be 0 and the two
durations will always be the same. If <option>--monitor</option>
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.
</p>
<p>
There will be one key-value pair for each file in Open vSwitch's
``run directory'' (usually <code>/var/run/openvswitch</code>)
whose name ends in <code>.pid</code>, whose contents are a
process ID, and which is locked by a running process. The
<var>name</var> is taken from the pidfile's name.
</p>
<p>
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.
</p>
</column>
<column name="statistics" key="file_systems">
<p>
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:
</p>
<ol>
<li>Mount point, e.g. <code>/</code> or <code>/var/log</code>.
Any spaces or commas in the mount point are replaced by
underscores.</li>
<li>Total size, in kilobytes, as an integer.</li>
<li>Amount of storage in use, in kilobytes, as an integer.</li>
</ol>
<p>
This key-value pair is omitted if there are no local, writable
file systems or if Open vSwitch cannot obtain the needed
information.
</p>
</column>
</group>
</group>
<group title="Version Reporting">
<p>
These columns report the types and versions of the hardware and
software running Open vSwitch. We recommend in general that software
should test whether specific features are supported instead of relying
on version number checks. These values are primarily intended for
reporting to human administrators.
</p>
<column name="ovs_version">
The Open vSwitch version number, e.g. <code>1.1.0</code>.
</column>
<column name="db_version">
<p>
The database schema version number, e.g. <code>1.2.3</code>. See
ovsdb-tool(1) for an explanation of the numbering scheme.
</p>
<p>
The schema version is part of the database schema, so it can also be
retrieved by fetching the schema using the Open vSwitch database
protocol.
</p>
</column>
<column name="system_type">
<p>
An identifier for the type of system on top of which Open vSwitch
runs, e.g. <code>XenServer</code> or <code>KVM</code>.
</p>
<p>
System integrators are responsible for choosing and setting an
appropriate value for this column.
</p>
</column>
<column name="system_version">
<p>
The version of the system identified by <ref column="system_type"/>,
e.g. <code>5.6.100-39265p</code> on XenServer 5.6.100 build 39265.
</p>
<p>
System integrators are responsible for choosing and setting an
appropriate value for this column.
</p>
</column>
<column name="dpdk_version">
<p>
The version of the linked DPDK library.
</p>
</column>
</group>
<group title="Capabilities">
<p>
These columns report capabilities of the Open vSwitch instance.
</p>
<column name="datapath_types">
<p>
This column reports the different dpifs registered with the system.
These are the values that this instance supports in the <ref
column="datapath_type" table="Bridge"/> column of the <ref
table="Bridge"/> table.
</p>
</column>
<column name="iface_types">
<p>
This column reports the different netdevs registered with the system.
These are the values that this instance supports in the <ref
column="type" table="Interface"/> column of the <ref
table="Interface"/> table.
</p>
</column>
</group>
<group title="Database Configuration">
<p>
These columns primarily configure the Open vSwitch database
(<code>ovsdb-server</code>), not the Open vSwitch switch
(<code>ovs-vswitchd</code>). The OVSDB database also uses the <ref
column="ssl"/> settings.
</p>
<p>
The Open vSwitch switch does read the database configuration to
determine remote IP addresses to which in-band control should apply.
</p>
<column name="manager_options">
<p>
Database clients to which the Open vSwitch database server should
connect or to which it should listen, along with options for how
these connections should be configured. See the <ref
table="Manager"/> table for more information.
</p>
<p>
For this column to serve its purpose, <code>ovsdb-server</code> must
be configured to honor it. The easiest way to do this is to invoke
<code>ovsdb-server</code> with the option
<option>--remote=db:Open_vSwitch,Open_vSwitch,manager_options</option>
The startup scripts that accompany Open vSwitch do this by default.
</p>
</column>
</group>
<group title="Common Columns">
The overall purpose of these columns is described under <code>Common
Columns</code> at the beginning of this document.
<column name="other_config"/>
<column name="external_ids"/>
</group>
</table>
<table name="Bridge">
<p>
Configuration for a bridge within an
<ref table="Open_vSwitch"/>.
</p>
<p>
A <ref table="Bridge"/> record represents an Ethernet switch with one or
more ``ports,'' which are the <ref table="Port"/> records pointed to by
the <ref table="Bridge"/>'s <ref column="ports"/> column.
</p>
<group title="Core Features">
<column name="name">
<p>
Bridge identifier. Must be unique among the names of ports,
interfaces, and bridges on a host.
</p>
<p>
The name must be alphanumeric and must not contain forward or
backward slashes. The name of a bridge is also the name of an <ref
table="Interface"/> (and a <ref table="Port"/>) within the bridge, so
the restrictions on the <ref table="Interface" column="name"/> column
in the <ref table="Interface"/> table, particularly on length, also
apply to bridge names. Refer to the documentation for <ref
table="Interface"/> names for details.
</p>
</column>
<column name="ports">
Ports included in the bridge.
</column>
<column name="mirrors">
Port mirroring configuration.
</column>
<column name="netflow">
NetFlow configuration.
</column>
<column name="sflow">
sFlow(R) configuration.
</column>
<column name="ipfix">
IPFIX configuration.
</column>
<column name="flood_vlans">
<p>
VLAN IDs of VLANs on which MAC address learning should be disabled,
so that packets are flooded instead of being sent to specific ports
that are believed to contain packets' destination MACs. This should
ordinarily be used to disable MAC learning on VLANs used for
mirroring (RSPAN VLANs). It may also be useful for debugging.
</p>
<p>
SLB bonding (see the <ref table="Port" column="bond_mode"/> column in
the <ref table="Port"/> table) is incompatible with
<code>flood_vlans</code>. Consider using another bonding mode or
a different type of mirror instead.
</p>
</column>
<column name="auto_attach">
Auto Attach configuration.
</column>
</group>
<group title="OpenFlow Configuration">
<column name="controller">
<p>
OpenFlow controller set. If unset, then no OpenFlow controllers
will be used.
</p>
<p>
If there are primary controllers, removing all of them clears the
OpenFlow flow tables, group table, and meter table. If there are no
primary controllers, adding one also clears these tables. Other
changes to the set of controllers, such as adding or removing a
service controller, adding another primary controller to supplement
an existing primary controller, or removing only one of two primary
controllers, have no effect on these tables.
</p>
</column>
<column name="flow_tables">
Configuration for OpenFlow tables. Each pair maps from an OpenFlow
table ID to configuration for that table.
</column>
<column name="fail_mode">
<p>When a controller is configured, it is, ordinarily, responsible
for setting up all flows on the switch. Thus, if the connection to
the controller fails, no new network connections can be set up.
If the connection to the controller stays down long enough,
no packets can pass through the switch at all. This setting
determines the switch's response to such a situation. It may be set
to one of the following:
<dl>
<dt><code>standalone</code></dt>
<dd>If no message is received from the controller for three
times the inactivity probe interval
(see <ref column="inactivity_probe"/>), then Open vSwitch
will take over responsibility for setting up flows. In
this mode, Open vSwitch causes the bridge to act like an
ordinary MAC-learning switch. Open vSwitch will continue
to retry connecting to the controller in the background
and, when the connection succeeds, it will discontinue its
standalone behavior.</dd>
<dt><code>secure</code></dt>
<dd>Open vSwitch will not set up flows on its own when the
controller connection fails or when no controllers are
defined. The bridge will continue to retry connecting to
any defined controllers forever.</dd>
</dl>
</p>
<p>
The default is <code>standalone</code> if the value is unset, but
future versions of Open vSwitch may change the default.
</p>
<p>
The <code>standalone</code> mode can create forwarding loops on a
bridge that has more than one uplink port unless STP is enabled. To
avoid loops on such a bridge, configure <code>secure</code> mode or
enable STP (see <ref column="stp_enable"/>).
</p>
<p>When more than one controller is configured,
<ref column="fail_mode"/> is considered only when none of the
configured controllers can be contacted.</p>
<p>
Changing <ref column="fail_mode"/> when no primary controllers are
configured clears the OpenFlow flow tables, group table, and meter
table.
</p>
</column>
<column name="datapath_id">
Reports the OpenFlow datapath ID in use. Exactly 16 hex digits.
(Setting this column has no useful effect. Set <ref
column="other-config" key="datapath-id"/> instead.)
</column>
<column name="datapath_version">
<p>
Reports the version number of the Open vSwitch datapath in use.
This allows management software to detect and report discrepancies
between Open vSwitch userspace and datapath versions. (The <ref
column="ovs_version" table="Open_vSwitch"/> column in the <ref
table="Open_vSwitch"/> reports the Open vSwitch userspace version.)
The version reported depends on the datapath in use:
</p>
<ul>
<li>
When the kernel module included in the Open vSwitch source tree is
used, this column reports the Open vSwitch version from which the
module was taken.
</li>
<li>
When the kernel module that is part of the upstream Linux kernel is
used, this column reports <code><unknown></code>.
</li>
<li>
When the datapath is built into the <code>ovs-vswitchd</code>
binary, this column reports <code><built-in></code>. A
built-in datapath is by definition the same version as the rest of
the Open VSwitch userspace.
</li>
<li>
Other datapaths (such as the Hyper-V kernel datapath) currently
report <code><unknown></code>.
</li>
</ul>
<p>
A version discrepancy between <code>ovs-vswitchd</code> and the
datapath in use is not normally cause for alarm. The Open vSwitch
kernel datapaths for Linux and Hyper-V, in particular, are designed
for maximum inter-version compatibility: any userspace version works
with with any kernel version. Some reasons do exist to insist on
particular user/kernel pairings. First, newer kernel versions add
new features, that can only be used by new-enough userspace, e.g.
VXLAN tunneling requires certain minimal userspace and kernel
versions. Second, as an extension to the first reason, some newer
kernel versions add new features for enhancing performance that only
new-enough userspace versions can take advantage of.
</p>
</column>
<column name="other_config" key="datapath-id">
Overrides the default OpenFlow datapath ID, setting it to the specified
value specified in hex. The value must either have a <code>0x</code>
prefix or be exactly 16 hex digits long. May not be all-zero.
</column>
<column name="other_config" key="dp-desc">
Human readable description of datapath. It is a maximum 256
byte-long free-form string to describe the datapath for
debugging purposes, e.g. <code>switch3 in room 3120</code>.
</column>
<column name="other_config" key="disable-in-band"
type='{"type": "boolean"}'>
If set to <code>true</code>, disable in-band control on the bridge
regardless of controller and manager settings.
</column>