]>
Commit | Line | Data |
---|---|---|
1 | How to Install Open vSwitch on Citrix XenServer | |
2 | =============================================== | |
3 | ||
4 | This document describes how to build and install Open vSwitch on a | |
5 | Citrix XenServer host. If you want to install Open vSwitch on a | |
6 | generic Linux or BSD host, see INSTALL instead. | |
7 | ||
8 | These instructions have been tested with XenServer 5.6 FP1. | |
9 | ||
10 | Building Open vSwitch for XenServer | |
11 | ----------------------------------- | |
12 | ||
13 | You may build from an Open vSwitch distribution tarball or from an | |
14 | Open vSwitch Git tree. The recommended build environment to build | |
15 | RPMs for Citrix XenServer is the DDK VM available from Citrix. | |
16 | ||
17 | 1. If you are building from an Open vSwitch Git tree, then you will | |
18 | need to first create a distribution tarball by running "./boot.sh; | |
19 | ./configure; make dist" in the Git tree. You cannot run this in | |
20 | the DDK VM, because it lacks tools that are necessary to bootstrap | |
21 | the Open vSwitch distribution. Instead, you must run this on a | |
22 | machine that has the tools listed in INSTALL as prerequisites for | |
23 | building from a Git tree. | |
24 | ||
25 | 2. Copy the distribution tarball into /usr/src/redhat/SOURCES inside | |
26 | the DDK VM. | |
27 | ||
28 | 3. In the DDK VM, unpack the distribution tarball into a temporary | |
29 | directory and "cd" into the root of the distribution tarball. | |
30 | ||
31 | 4. To build Open vSwitch userspace, run: | |
32 | ||
33 | rpmbuild -bb xenserver/openvswitch-xen.spec | |
34 | ||
35 | This produces three RPMs in /usr/src/redhat/RPMS/i386: | |
36 | "openvswitch", "openvswitch-modules-xen", and | |
37 | "openvswitch-debuginfo". | |
38 | ||
39 | The above command automatically runs the Open vSwitch unit tests. | |
40 | To disable the unit tests, run: | |
41 | ||
42 | rpmbuild -bb --without check xenserver/openvswitch-xen.spec | |
43 | ||
44 | Build Parameters | |
45 | ---------------- | |
46 | ||
47 | openvswitch-xen.spec needs to know a number of pieces of information | |
48 | about the XenServer kernel. Usually, it can figure these out for | |
49 | itself, but if it does not do it correctly then you can specify them | |
50 | yourself as parameters to the build. Thus, the final "rpmbuild" step | |
51 | above can be elaborated as: | |
52 | ||
53 | VERSION=<Open vSwitch version> | |
54 | KERNEL_NAME=<Xen Kernel name> | |
55 | KERNEL_VERSION=<Xen Kernel version> | |
56 | KERNEL_FLAVOR=<Xen Kernel flavor(suffix) > | |
57 | rpmbuild \ | |
58 | -D "openvswitch_version $VERSION" \ | |
59 | -D "kernel_name $KERNEL_NAME" \ | |
60 | -D "kernel_version $KERNEL_VERSION" \ | |
61 | -D "kernel_flavor $KERNEL_FLAVOR" \ | |
62 | -bb xenserver/openvswitch-xen.spec | |
63 | ||
64 | where: | |
65 | ||
66 | <openvswitch version> is the version number that appears in the | |
67 | name of the Open vSwitch tarball, e.g. 0.90.0. | |
68 | ||
69 | <Xen Kernel name> is the name of the XenServer kernel package, | |
70 | e.g. kernel-xen or kernel-NAME-xen, without the "kernel-" prefix. | |
71 | ||
72 | <Xen Kernel version> is the output of: | |
73 | rpm -q --queryformat "%{Version}-%{Release}" <kernel-devel-package>, | |
74 | e.g. 2.6.32.12-0.7.1.xs5.6.100.323.170596, where <kernel-devel-package> is | |
75 | the name of the -devel package corresponding to <Xen Kernel name>. | |
76 | ||
77 | <Xen Kernel flavor (suffix) > is either "xen" or "kdump". | |
78 | The "xen" flavor is the main running kernel flavor and the "kdump" flavor is | |
79 | the crashdump kernel flavor. Commonly, one would specify "xen" here. | |
80 | ||
81 | Installing Open vSwitch for XenServer | |
82 | ------------------------------------- | |
83 | ||
84 | To install Open vSwitch on a XenServer host, or to upgrade to a newer version, | |
85 | copy the "openvswitch" and "openvswitch-modules-xen" RPMs to that host with | |
86 | "scp", then install them with "rpm -U", e.g.: | |
87 | ||
88 | scp openvswitch-$VERSION-1.i386.rpm \ | |
89 | openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm \ | |
90 | root@<host>: | |
91 | (At this point you will have to enter <host>'s root password.) | |
92 | ssh root@<host> | |
93 | (At this point you will have to enter <host>'s root password again.) | |
94 | rpm -U openvswitch-$VERSION-1.i386.rpm \ | |
95 | openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm | |
96 | ||
97 | To uninstall Open vSwitch from a XenServer host, remove the packages: | |
98 | ||
99 | ssh root@<host> | |
100 | (At this point you will have to enter <host>'s root password again.) | |
101 | rpm -e openvswitch openvswitch-modules-xen-$XEN_KERNEL_VERSION | |
102 | ||
103 | After installing or uninstalling Open vSwitch, the XenServer should be | |
104 | rebooted as soon as possible. | |
105 | ||
106 | Open vSwitch Boot Sequence on XenServer | |
107 | --------------------------------------- | |
108 | ||
109 | When Open vSwitch is installed on XenServer, its startup script | |
110 | /etc/init.d/openvswitch runs early in boot. It does roughly the | |
111 | following: | |
112 | ||
113 | * Loads the OVS kernel module, openvswitch. | |
114 | ||
115 | * Starts ovsdb-server, the OVS configuration database. | |
116 | ||
117 | * XenServer expects there to be no bridges configured at | |
118 | startup, but the OVS configuration database likely still has | |
119 | bridges configured from before reboot. To match XenServer | |
120 | expectations, the startup script deletes all configured | |
121 | bridges from the database. | |
122 | ||
123 | * Starts ovs-vswitchd, the OVS switching daemon. | |
124 | ||
125 | At this point in the boot process, then, there are no Open vSwitch | |
126 | bridges, even though all of the Open vSwitch daemons are running. | |
127 | Later on in boot, /etc/init.d/management-interface (part of XenServer, | |
128 | not Open vSwitch) creates the bridge for the XAPI management interface | |
129 | by invoking /opt/xensource/libexec/interface-reconfigure. Normally | |
130 | this program consults XAPI's database to obtain information about how | |
131 | to configure the bridge, but XAPI is not running yet[*] so it instead | |
132 | consults /var/xapi/network.dbcache, which is a cached copy of the most | |
133 | recent network configuration. | |
134 | ||
135 | [*] Even if XAPI were running, if this XenServer node is a pool slave | |
136 | then the query would have to consult the master, which requires | |
137 | network access, which begs the question of how to configure the | |
138 | management interface. | |
139 | ||
140 | XAPI starts later on in the boot process. XAPI can then create other | |
141 | bridges on demand using /opt/xensource/libexec/interface-reconfigure. | |
142 | Now that XAPI is running, that program consults XAPI directly instead | |
143 | of reading the cache. | |
144 | ||
145 | As part of its own startup, XAPI invokes the Open vSwitch XAPI plugin | |
146 | script /etc/xapi.d/openvswitch-cfg-update passing the "update" | |
147 | command. The plugin script does roughly the following: | |
148 | ||
149 | * Calls /opt/xensource/libexec/interface-reconfigure with the | |
150 | "rewrite" command, to ensure that the network cache is | |
151 | up-to-date. | |
152 | ||
153 | * Queries the Open vSwitch manager setting (named | |
154 | "vswitch_controller") from the XAPI database for the | |
155 | XenServer pool. | |
156 | ||
157 | * If XAPI and OVS are configured for different managers, or if | |
158 | OVS is configured for a manager but XAPI is not, runs | |
159 | "ovs-vsctl emer-reset" to bring the Open vSwitch | |
160 | configuration to a known state. One effect of emer-reset is | |
161 | to deconfigure any manager from the OVS database. | |
162 | ||
163 | * If XAPI is configured for a manager, configures the OVS | |
164 | manager to match with "ovs-vsctl set-manager". | |
165 | ||
166 | Notes | |
167 | ----- | |
168 | ||
169 | * The Open vSwitch boot sequence only configures an OVS configuration | |
170 | database manager. There is no way to directly configure an OpenFlow | |
171 | controller on XenServer and, as a consequence of the step above that | |
172 | deletes all of the bridges at boot time, controller configuration only | |
173 | persists until XenServer reboot. The configuration database manager | |
174 | can, however, configure controllers for bridges. See the BUGS section | |
175 | of ovs-testcontroller(8) for more information on this topic. | |
176 | ||
177 | * The Open vSwitch startup script automatically adds a firewall rule | |
178 | to allow GRE traffic. This rule is needed for the XenServer feature | |
179 | called "Cross-Host Internal Networks" (CHIN) that uses GRE. If a user | |
180 | configures tunnels other than GRE (ex: Geneve, VXLAN, LISP), they will have | |
181 | to either manually add a iptables firewall rule to allow the tunnel traffic | |
182 | or add it through a startup script (Please refer to the "enable-protocol" | |
183 | command in the ovs-ctl(8) manpage). | |
184 | ||
185 | Reporting Bugs | |
186 | -------------- | |
187 | ||
188 | Please report problems to bugs@openvswitch.org. |