/usr/src/redhat/SOURCES inside the VM. Then execute the following:
VERSION=<Open vSwitch version>
- XENKERNEL=<Xen kernel version>
+ KERNEL_NAME=<Xen Kernel name>
+ KERNEL_VERSION=<Xen Kernel version>
+ KERNEL_FLAVOR=<Xen Kernel flavor(suffix) >
cd /tmp
tar xfz /usr/src/redhat/SOURCES/openvswitch-$VERSION.tar.gz
rpmbuild \
-D "openvswitch_version $VERSION" \
- -D "xen_version $XENKERNEL" \
+ -D "kernel_name $KERNEL_NAME" \
+ -D "kernel_version $KERNEL_VERSION" \
+ -D "kernel_flavor $KERNEL_FLAVOR" \
-bb openvswitch-$VERSION/xenserver/openvswitch-xen.spec
where:
<openvswitch version> is the version number that appears in the
name of the Open vSwitch tarball, e.g. 0.90.0.
- <Xen kernel version> is the version number of the Xen kernel,
- e.g. 2.6.32.12-0.7.1.xs5.6.100.307.170586xen. This version number
- appears as the name of a directory in /lib/modules inside the VM.
- It always ends in "xen".
+ <Xen Kernel name> is the name of the XenServer kernel package,
+ e.g. kernel-xen or kernel-NAME-xen, without the "kernel-" prefix.
-Two RPMs will be output into /usr/src/redhat/RPMS/i386, whose names
-begin with "openvswitch" and "openvswitch-debuginfo".
+ <Xen Kernel version> is the output of:
+ rpm -q --queryformat "%{Version}-%{Release}" <kernel-devel-package>,
+ e.g. 2.6.32.12-0.7.1.xs5.6.100.323.170596, where <kernel-devel-package> is
+ the name of the -devel package corresponding to <Xen Kernel name>.
+
+ <Xen Kernel flavor (suffix) > is either "xen" or "kdump".
+ The "xen" flavor is the main running kernel flavor and the "kdump" flavor is
+ the crashdump kernel flavor. Commonly, one would specify "xen" here.
+
+Three RPMs will be output into /usr/src/redhat/RPMS/i386, whose names begin
+with "openvswitch", "openvswitch-modules-xen" (if building for kernel_flavor=xen),
+and "openvswitch-debuginfo".
Installing Open vSwitch for XenServer
-------------------------------------
-To install Open vSwitch on a XenServer host, or to upgrade to a newer
-version, copy the "openvswitch" RPM to that host with "scp", then install
-it with "rpm -U", e.g.:
+To install Open vSwitch on a XenServer host, or to upgrade to a newer version,
+copy the "openvswitch" and "openvswitch-modules-xen" RPMs to that host with
+"scp", then install them with "rpm -U", e.g.:
- scp openvswitch-$VERSION-1.i386.rpm root@<host>:
-(At this point you will have to enter <host>'s root password.)
+ scp openvswitch-$VERSION-1.i386.rpm \
+ openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm \
+ root@<host>:
+(At this point you will have to enter <host>'s root password.)
ssh root@<host>
-(At this point you will have to enter <host>'s root password again.)
- rpm -U openvswitch-$VERSION-1.i386.rpm
+(At this point you will have to enter <host>'s root password again.)
+ rpm -U openvswitch-$VERSION-1.i386.rpm \
+ openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm
-To uninstall Open vSwitch from a XenServer host, remove the package:
+To uninstall Open vSwitch from a XenServer host, remove the packages:
ssh root@<host>
-(At this point you will have to enter <host>'s root password again.)
- rpm -e openvswitch
+(At this point you will have to enter <host>'s root password again.)
+ rpm -e openvswitch openvswitch-modules-xen-$XEN_KERNEL_VERSION
After installing or uninstalling Open vSwitch, the XenServer should be
rebooted as soon as possible.
+Open vSwitch Boot Sequence on XenServer
+---------------------------------------
+
+When Open vSwitch is installed on XenServer, its startup script
+/etc/init.d/openvswitch runs early in boot. It does roughly the
+following:
+
+ * Loads the OVS kernel module, openvswitch_mod.
+
+ * Starts ovsdb-server, the OVS configuration database.
+
+ * XenServer expects there to be no bridges configured at
+ startup, but the OVS configuration database likely still has
+ bridges configured from before reboot. To match XenServer
+ expectations, the startup script deletes all configured
+ bridges from the database.
+
+ * Starts ovs-vswitchd, the OVS switching daemon.
+
+At this point in the boot process, then, there are no Open vSwitch
+bridges, even though all of the Open vSwitch daemons are running.
+Later on in boot, /etc/init.d/management-interface (part of XenServer,
+not Open vSwitch) creates the bridge for the XAPI management interface
+by invoking /opt/xensource/libexec/interface-reconfigure. Normally
+this program consults XAPI's database to obtain information about how
+to configure the bridge, but XAPI is not running yet[*] so it instead
+consults /var/xapi/network.dbcache, which is a cached copy of the most
+recent network configuration.
+
+[*] Even if XAPI were running, if this XenServer node is a pool slave
+ then the query would have to consult the master, which requires
+ network access, which begs the question of how to configure the
+ management interface.
+
+XAPI starts later on in the boot process. XAPI can then create other
+bridges on demand using /opt/xensource/libexec/interface-reconfigure.
+Now that XAPI is running, that program consults XAPI directly instead
+of reading the cache.
+
+As part of its own startup, XAPI invokes the Open vSwitch XAPI plugin
+script /etc/xapi.d/openvswitch-cfg-update passing the "update"
+command. The plugin script does roughly the following:
+
+ * Calls /opt/xensource/libexec/interface-reconfigure with the
+ "rewrite" command, to ensure that the network cache is
+ up-to-date.
+
+ * Queries the Open vSwitch manager setting (named
+ "vswitch_controller") from the XAPI database for the
+ XenServer pool.
+
+ * If XAPI and OVS are configured for different managers, or if
+ OVS is configured for a manager but XAPI is not, runs
+ "ovs-vsctl emer-reset" to bring the Open vSwitch
+ configuration to a known state. One effect of emer-reset is
+ to deconfigure any manager from the OVS database.
+
+ * If XAPI is configured for a manger, configures the OVS
+ manager to match with "ovs-vsctl set-manager".
+
+The Open vSwitch boot sequence only configures an OVS configuration
+database manager. There is no way to directly configure an OpenFlow
+controller on XenServer and, as a consequence of the step above that
+deletes all of the bridges at boot time, controller configuration only
+persists until XenServer reboot. The configuration database manager
+can, however, configure controllers for bridges. See the BUGS section
+of ovs-controller(8) for more information on this topic.
+
Reporting Bugs
--------------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff