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
|
--- openvswitch-2.12.0/debian/openvswitch-switch.README.Debian
+++ openvswitch-2.12.0/debian/openvswitch-switch.README.Debian.new
@@ -1,48 +1,8 @@
-README.Debian for openvswitch-switch
----------------------------------
-
-To use the Linux kernel-based switch implementation, you will need an
-Open vSwitch kernel module. There are multiple ways to obtain one.
-In order of increasing manual effort, these are:
-
- * Use a Linux kernel 3.3 or later, which has an integrated Open
- vSwitch kernel module.
-
- The upstream Linux kernel module lacks a few features that
- are in the third-party module. For details, please see the
- FAQ, "What features are not available in the Open vSwitch
- kernel datapath that ships as part of the upstream Linux
- kernel?".
-
- * Install the "openvswitch-datapath-dkms" Debian package that
- you built earlier. This should automatically build and
- install the Open vSwitch kernel module for your running
- kernel.
-
- This option requires that you have a compiler and toolchain
- installed on the machine where you run Open vSwitch, which
- may be unacceptable in some production server environments.
-
- * Install the "openvswitch-datapath-source" Debian package, use
- "module-assistant" to build a Debian package of the Open
- vSwitch kernel module for your kernel, and then install that
- Debian package.
-
- You can install the kernel module Debian packages that you
- build this way on the same machine where you built it or on
- another machine or machines, which means that you don't
- necessarily have to have any build infrastructure on the
- machines where you use the kernel module.
-
- /usr/share/doc/openvswitch-datapath-source/README.Debian has
- details on the build process.
-
- * Build and install the kernel module by hand.
-
-
-Debian network scripts (ifupdown) integration
-------------------------------------------------
-This package lets a user to optionally configure Open vSwitch bridges
+README.Alpine for Openvswitch
+-----------------------------
+network scripts integration
+-----------------------------
+This package enables a user to optionally configure Open vSwitch bridges
and ports from /etc/network/interfaces. Please refer to the interfaces(5)
manpage for more details regarding /etc/network/interfaces.
@@ -202,115 +162,30 @@
ex 8: Create and destroy bridges.
-ifup --allow=ovs $list_of_bridges
-ifdown --allow=ovs $list_of_bridges
+ifup $list_of_bridges
+ifdown $list_of_bridges
-Open vSwitch integration with systemd-networkd
------------------------------------------------
+Notes on LXC integration:
+-------------------------
-There is no native integration of OVS with systemd-networkd. That is,
-you cannot create OVS bridges, ports and bonds by simply writing configuration
-files in /etc/systemd/network. But, you can create OVS devices using ovs-vsctl
-and then write configuration files to provide them IP addresses.
+To prevent containers failing to start after hard reboots create:
+-----------------------------------------------------------------
-As soon as a OVS device is visible, systemd-networkd will provide that device
-an IP address. Since OVS database is persistent across reboots, the OVS
-devices will get re-created after a reboot as soon as OVS startup script is
-invoked. And systemd-networkd will immediately assign the configuration defined
-in /etc/systemd/network.
+/etc/lxc/ovsup:
-Example:
+#!/bin/sh
+ovs-vsctl --if-exists del-port $5
+-----------------------------------------------------------------
-If you have a physical ethernet device "ens160" which has been configured with
-DHCP, your systemd-networkd's .network config file will look something like
-this:
+/etc/lxc/ovsdown:
-```
-[Match]
-Name=ens160
+#!/bin/sh
+ovs-vsctl --if-exists del-port veth.$LXC_NAME
+-----------------------------------------------------------------
-[Network]
-DHCP=ipv4
+& add to the container config file:
-[DHCP]
-ClientIdentifier=mac
-```
+lxc.hook.pre-start = /etc/lxc/ovsup
+lxc.hook.post-stop = /etc/lxc/ovsdown
-Please note how the DHCP ClientIdentifier above has been configured with the
-mac address.
-To create a OVS bridge "br-ens160" and add "ens160" as a port of that
-bridge, you can change the .network configuration for "ens160" to look like:
-
-```
-[Match]
-Name=ens160
-```
-
-Now create a new .network configuration file for "br-ens160". Something like:
-
-```
-[Match]
-Name=br-ens160
-
-[Network]
-DHCP=ipv4
-
-[DHCP]
-ClientIdentifier=mac
-```
-
-Now, use ovs-vsctl to create br-ens160 and add ens160 as a port of it. You
-will also have to flush the IP address of ens160 and restart systemd-networkd
-in the same line. It is important to let br-ens160 have the same mac address as
-ens160 to get the same IP address to br-ens160 from the DHCP server. In the
-below command, "$mac_of_ens160" holds the mac address of ens160. For e.g:
-
-```
-mac_of_ens160='"00:0c:29:77:27:7a"'
-ovs-vsctl --may-exist add-br br-ens160 -- \
- --may-exist add-port br-ens160 ens160 -- \
- set interface br-ens160 mac="$mac_of_ens160"; ip addr flush dev ens160; \
- systemctl restart systemd-networkd
-```
-
-br-ens160 should now have the same DHCP IP. It should also have the correct
-DNS resolution servers configured.
-
-Notes on dependencies:
----------------------
-
-openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
-This creates some startup dependency issues.
-
-* Since openvswitch utilities are placed in /usr and /usr can be mounted
-through NFS, openvswitch has to start after it. But if a user uses openvswitch
-for all his networking needs and hence to mount NFS, there will be a deadlock.
-So, if /usr is mounted through NFS and openvswitch is used for all networking,
-the administrator should figure out a way to mount NFS before starting OVS.
-One way to do this is in initramfs.
-
-* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
-script that depends on openvswitch but starts before it, needs to be changed
-to depend on openvswitch-switch too.
-
-* Ideally, an admin should not add openvswitch bridges in the 'auto'
-section of the 'interfaces' file (i.e., if "br0" is a OVS bridge, you should
-not have a line "auto br0"). This is because, when ifupdown starts
-working on bridges listed in 'auto', openvswitch has not yet started.
-
-But, if the admin wants to go down this route and adds openvswitch bridges
-in the 'auto' section, openvswitch-switch will forcefully be started when
-ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
-has already been mounted and that a remote $syslog (if used) is ready to
-receive openvswitch logs.
-
-* With systemd, adding openvswitch bridges in the 'auto' section of the
-'interfaces' file can cause race conditions (i.e., if "br0" is a OVS bridge,
-you should not have a line "auto br0"). Debian systems have added a
-systemd ifup@.service file. This file will call ifdown and ifup on interfaces
-in "auto" section automatically when the interfaces disappear and appear
-respectively. This will cause race conditions if you delete and add the same
-bridges using tools like "ovs-vsctl" or "ovs-dpctl". This is also a problem
-when you upgrade your openvswitch kernel module using commands like
-'force-reload-kmod'.
|
