xenserver: Remove xenserver.

Remove the current xenserver implementation - it is obsolete and
since 3.0 we do not support kernel module builds [1].

1. https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/395789.html

[i.maximets]
Can be added back if people willing to maintain it will be found.

Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

13 files changed, 30 insertions, 286 deletions

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 185349c14..cdf3c9926 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -21,7 +21,6 @@ DOC_SOURCE = \
 	Documentation/intro/install/rhel.rst \
 	Documentation/intro/install/userspace.rst \
 	Documentation/intro/install/windows.rst \
-	Documentation/intro/install/xenserver.rst \
 	Documentation/tutorials/index.rst \
 	Documentation/tutorials/faucet.rst \
 	Documentation/tutorials/ovs-advanced.rst \
diff --git a/Documentation/faq/general.rst b/Documentation/faq/general.rst
index efbc213de..bd56363b7 100644
--- a/Documentation/faq/general.rst
+++ b/Documentation/faq/general.rst
@@ -44,11 +44,11 @@ Q: What is Open vSwitch?
 Q: What virtualization platforms can use Open vSwitch?
 
     A: Open vSwitch can currently run on any Linux-based virtualization
-    platform (kernel 3.10 and newer), including: KVM, VirtualBox, Xen, Xen
-    Cloud Platform, XenServer. As of Linux 3.3 it is part of the mainline
-    kernel.  The bulk of the code is written in platform- independent C and is
-    easily ported to other environments.  We welcome inquires about integrating
-    Open vSwitch with other virtualization platforms.
+    platform (kernel 3.10 and newer), including: KVM and VirtualBox.
+    As of Linux 3.3 it is part of the mainline kernel.  The bulk of the
+    code is written in platform- independent C and is easily ported to
+    other environments.  We welcome inquires about integrating Open
+    vSwitch with other virtualization platforms.
 
 Q: How can I try Open vSwitch?
 
@@ -58,8 +58,7 @@ Q: How can I try Open vSwitch?
     Debian, Ubuntu, Fedora.
 
     You may also download and run a virtualization platform that already has
-    Open vSwitch integrated.  For example, download a recent ISO for XenServer
-    or Xen Cloud Platform.  Be aware that the version integrated with a
+    Open vSwitch integrated.  Be aware that the version integrated with a
     particular platform may not be the most recent Open vSwitch release.
 
 Q: Does Open vSwitch only work on Linux?
diff --git a/Documentation/howto/qos.rst b/Documentation/howto/qos.rst
index 4462856ba..376ec2514 100644
--- a/Documentation/howto/qos.rst
+++ b/Documentation/howto/qos.rst
@@ -72,8 +72,7 @@ Both VMs (`vm1` and `vm2`) run on `host1`.
 Each VM has a single interface that appears as a Linux device (e.g., ``tap0``) on the physical host.
 
 .. note::
-  For Xen/XenServer, VM interfaces appears as Linux devices with names like
-  ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``,
+  VM interfaces may appear as Linux devices with names like ``vnet0``,
   ``vnet1``, etc.
 
 Configuration Steps
diff --git a/Documentation/howto/sflow.rst b/Documentation/howto/sflow.rst
index c6ab0764c..74d8b8e17 100644
--- a/Documentation/howto/sflow.rst
+++ b/Documentation/howto/sflow.rst
@@ -76,8 +76,7 @@ Two Virtual Machines
 This guide uses two virtual machines - `vm1` and `vm2`-  running on `host1`.
 
 .. note::
-  For Xen/XenServer, VM interfaces appears as Linux devices with names like
-  ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``,
+  VM interfaces may appear as Linux devices with names like ``vnet0``,
   ``vnet1``, etc.
 
 Configuration Steps
diff --git a/Documentation/howto/tunneling.rst b/Documentation/howto/tunneling.rst
index 2cbca977b..8b51267e0 100644
--- a/Documentation/howto/tunneling.rst
+++ b/Documentation/howto/tunneling.rst
@@ -83,8 +83,7 @@ Each VM has a single interface that appears as a Linux device (e.g., ``tap0``)
 on the physical host.
 
 .. note::
-  For Xen/XenServer, VM interfaces appears as Linux devices with names like
-  ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``,
+  VM interfaces may appear as Linux devices with names like ``vnet0``,
   ``vnet1``, etc.
 
 Configuration Steps
diff --git a/Documentation/howto/vlan.rst b/Documentation/howto/vlan.rst
index 86fcf9508..8f2ffa26c 100644
--- a/Documentation/howto/vlan.rst
+++ b/Documentation/howto/vlan.rst
@@ -75,8 +75,7 @@ Each VM has a single interface that appears as a Linux device (e.g., ``tap0``)
 on the physical host.
 
 .. note::
-  For Xen/XenServer, VM interfaces appears as Linux devices with names like
-  ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``,
+  VM interfaces may appear as Linux devices with names like ``vnet0``,
   ``vnet1``, etc.
 
 Configuration Steps
diff --git a/Documentation/intro/install/general.rst b/Documentation/intro/install/general.rst
index 9ed3f6c78..42b5682fd 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -598,8 +598,8 @@ userspace flows using the ovs-ofctl utility and also uses the
 ``other_config:flow-restore-wait`` column to keep the traffic downtime to the
 minimum. The ovs-ctl utility's ``force-reload-kmod`` function does all of the
 above, but also replaces the old kernel module with the new one. Open vSwitch
-startup scripts for Debian, XenServer and RHEL use ovs-ctl's functions and it
-is recommended that these functions be used for other software platforms too.
+startup scripts for Debian and RHEL use ovs-ctl's functions and it is
+recommended that these functions be used for other software platforms too.
 
 Reporting Bugs
 --------------
diff --git a/Documentation/intro/install/index.rst b/Documentation/intro/install/index.rst
index 586ced95f..885a65d6e 100644
--- a/Documentation/intro/install/index.rst
+++ b/Documentation/intro/install/index.rst
@@ -42,7 +42,6 @@ Installation from Source
    general
    netbsd
    windows
-   xenserver
    userspace
    dpdk
    afxdp
diff --git a/Documentation/intro/install/xenserver.rst b/Documentation/intro/install/xenserver.rst
deleted file mode 100644
index 366e11ac2..000000000
--- a/Documentation/intro/install/xenserver.rst
+++ /dev/null
@@ -1,229 +0,0 @@
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-      Convention for heading levels in Open vSwitch documentation:
-
-      =======  Heading 0 (reserved for the title in a document)
-      -------  Heading 1
-      ~~~~~~~  Heading 2
-      +++++++  Heading 3
-      '''''''  Heading 4
-
-      Avoid deeper levels because they do not render well.
-
-================================
-Open vSwitch on Citrix XenServer
-================================
-
-This document describes how to build and install Open vSwitch on a Citrix
-XenServer host.  If you want to install Open vSwitch on a generic Linux or BSD
-host, refer to :doc:`general` instead.
-
-Open vSwitch should work with XenServer 5.6.100 and later.  However, Open
-vSwitch requires Python 3.4 or later, so using Open vSwitch with XenServer 6.5
-or earlier requires installing Python 3.x.
-
-Building
---------
-
-You may build from an Open vSwitch distribution tarball or from an Open vSwitch
-Git tree.  The recommended build environment to build RPMs for Citrix XenServer
-is the DDK VM available from Citrix.
-
-1. If you are building from an Open vSwitch Git tree, then you will need to
-   first create a distribution tarball by running::
-
-       $ ./boot.sh
-       $ ./configure
-       $ make dist
-
-   You cannot run this in the DDK VM, because it lacks tools that are necessary
-   to bootstrap the Open vSwitch distribution.  Instead, you must run this on a
-   machine that has the tools listed in :ref:`general-install-reqs` as
-   prerequisites for building from a Git tree.
-
-2. Copy the distribution tarball into ``/usr/src/redhat/SOURCES`` inside
-   the DDK VM.
-
-3. In the DDK VM, unpack the distribution tarball into a temporary directory
-   and "cd" into the root of the distribution tarball.
-
-4. To build Open vSwitch userspace, run::
-
-       $ rpmbuild -bb xenserver/openvswitch-xen.spec
-
-   This produces three RPMs in ``/usr/src/redhat/RPMS/i386``:
-
-   - ``openvswitch``
-   - ``openvswitch-modules-xen``
-   - ``openvswitch-debuginfo``
-
-   The above command automatically runs the Open vSwitch unit tests.  To
-   disable the unit tests, run::
-
-       $ rpmbuild -bb --without check xenserver/openvswitch-xen.spec
-
-Build Parameters
-----------------
-
-``openvswitch-xen.spec`` needs to know a number of pieces of information about
-the XenServer kernel.  Usually, it can figure these out for itself, but if it
-does not do it correctly then you can specify them yourself as parameters to
-the build.  Thus, the final ``rpmbuild`` step above can be elaborated as::
-
-    $ VERSION=<Open vSwitch version>
-    $ KERNEL_NAME=<Xen Kernel name>
-    $ KERNEL_VERSION=<Xen Kernel version>
-    $ KERNEL_FLAVOR=<Xen Kernel flavor(suffix)>
-    $ rpmbuild \
-         -D "openvswitch_version $VERSION" \
-         -D "kernel_name $KERNEL_NAME" \
-         -D "kernel_version $KERNEL_VERSION" \
-         -D "kernel_flavor $KERNEL_FLAVOR" \
-         -bb 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 name>``
-  is the name of the XenServer kernel package, e.g. ``kernel-xen`` or
-  ``kernel-NAME-xen``, without the ``kernel-`` prefix.
-
-``<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``, where ``xen`` flavor is the main running
-  kernel flavor and the ``kdump`` flavor is the crashdump kernel flavor.
-  Commonly, one would specify ``xen`` here.
-
-For XenServer 6.5 or above, the kernel version naming no longer contains
-KERNEL_FLAVOR.  In fact, only providing the ``uname -r`` output is enough.  So,
-the final ``rpmbuild`` step changes to::
-
-    $ KERNEL_UNAME=<`uname -r` output>
-    $ rpmbuild \
-        -D "kenel_uname $KERNEL_UNAME" \
-        -bb xenserver/openvswitch-xen.spec
-
-Installing Open vSwitch for XenServer
--------------------------------------
-
-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 \
-        openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm \
-        root@<host>:
-    # Enter <host>'s root password.
-    $ ssh root@<host>
-    # 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 packages::
-
-    $ ssh root@<host>
-    # 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.
-
-* 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 manager, configures the OVS manager to match with
-  ``ovs-vsctl set-manager``.
-
-Notes
------
-
-* 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-testcontroller(8) for
-  more information on this topic.
-
-* The Open vSwitch startup script automatically adds a firewall rule to allow
-  GRE traffic. This rule is needed for the XenServer feature called "Cross-Host
-  Internal Networks" (CHIN) that uses GRE. If a user configures tunnels other
-  than GRE (ex: Geneve, VXLAN, LISP), they will have to either manually add a
-  iptables firewall rule to allow the tunnel traffic or add it through a
-  startup script (Please refer to the "enable-protocol" command in the
-  ovs-ctl(8) manpage).
-
-Reporting Bugs
---------------
-
-Please report problems to bugs@openvswitch.org.
diff --git a/Documentation/ref/ovs-ctl.8.rst b/Documentation/ref/ovs-ctl.8.rst
index 7cfc41322..9f077a122 100644
--- a/Documentation/ref/ovs-ctl.8.rst
+++ b/Documentation/ref/ovs-ctl.8.rst
@@ -481,9 +481,8 @@ Files
 Example
 =======
 
-The files ``debian/openvswitch-switch.init`` and
-``xenserver/etc_init.d_openvswitch`` in the Open vSwitch source
-distribution are good examples of how to use ``ovs-ctl``.
+The file ``debian/openvswitch-switch.init`` in the Open vSwitch source
+distribution is a good example of how to use ``ovs-ctl``.
 
 See Also
 ========
diff --git a/Documentation/topics/bonding.rst b/Documentation/topics/bonding.rst
index 01bd5dfc2..b8ef0dab5 100644
--- a/Documentation/topics/bonding.rst
+++ b/Documentation/topics/bonding.rst
@@ -152,11 +152,11 @@ special handling of received packets.
 
 Several of the physical switches that support LACP block all traffic for ports
 that are configured to use LACP, until LACP is negotiated with the host. When
-configuring a LACP bond on a OVS host (eg: XenServer), this means that there
-will be an interruption of the network connectivity between the time the ports
-on the physical switch and the bond on the OVS host are configured. The
-interruption may be relatively long, if different people are responsible for
-managing the switches and the OVS host.
+configuring a LACP bond on a OVS host, this means that there will be an
+interruption of the network connectivity between the time the ports on the
+physical switch and the bond on the OVS host are configured. The interruption
+may be relatively long, if different people are responsible for managing the
+switches and the OVS host.
 
 Such network connectivity failure can be avoided if LACP can be configured on
 the OVS host before configuring the physical switch, and having the OVS host
diff --git a/Documentation/topics/integration.rst b/Documentation/topics/integration.rst
index 060e1bd87..58c4389ab 100644
--- a/Documentation/topics/integration.rst
+++ b/Documentation/topics/integration.rst
@@ -29,9 +29,7 @@ This document describes how to integrate Open vSwitch onto a new platform to
 expose the state of the switch and attached devices for centralized control.
 (If you are looking to port the switching components of Open vSwitch to a new
 platform, refer to :doc:`porting`)  The focus of this guide is on hypervisors,
-but many of the interfaces are useful for hardware switches, as well.  The
-XenServer integration is the most mature implementation, so most of the
-examples are drawn from it.
+but many of the interfaces are useful for hardware switches, as well.
 
 The externally visible interface to this integration is platform-agnostic.  We
 encourage anyone who integrates Open vSwitch to use the same interface, because
@@ -48,18 +46,15 @@ ensure that these values are correctly populated and maintained.
 
 An integrator sets the columns in the database by talking to the ovsdb-server
 daemon.  A few of the columns can be set during startup by calling the ovs-ctl
-tool from inside the startup scripts.  The ``xenserver/etc_init.d_openvswitch``
+tool from inside the startup scripts.  The ``rhel/etc_init.d_openvswitch``
 script provides examples of its use, and the ovs-ctl(8) manpage contains
 complete documentation.  At runtime, ovs-vsctl can be used to set columns in
-the database.  The script ``xenserver/etc_xensource_scripts_vif`` contains
-examples of its use, and ovs-vsctl(8) manpage contains complete documentation.
+the database.
 
 Python and C bindings to the database are provided if deeper integration with a
-program are needed.  The XenServer ovs-xapi-sync daemon
-(``xenserver/usr_share_openvswitch_scripts_ovs-xapi-sync``) provides an example
-of using the Python bindings.  More information on the python bindings is
-available at ``python/ovs/db/idl.py``.  Information on the C bindings is
-available at ``lib/ovsdb-idl.h``.
+program are needed.  More information on the python bindings is available at
+``python/ovs/db/idl.py``.  Information on the C bindings is available at
+``lib/ovsdb-idl.h``.
 
 The following diagram shows how integration scripts fit into the Open vSwitch
 architecture:
@@ -83,7 +78,6 @@ architecture:
     |             |                              |             |
     |  +---------------------+                   |             |
     |  | Integration scripts |                   |             |
-    |  | (ex: ovs-xapi-sync) |                   |             |
     |  +---------------------+                   |             |
     |                                            |   Userspace |
     |----------------------------------------------------------|
@@ -105,8 +99,7 @@ individual column, please refer to the ovs-vswitchd.conf.db(5) manpage.
 The ``Open_vSwitch`` table describes the switch as a whole.  The
 ``system_type`` and ``system_version`` columns identify the platform to the
 controller.  The ``external_ids:system-id`` key uniquely identifies the
-physical host.  In XenServer, the system-id will likely be the same as the UUID
-returned by ``xe host-list``. This key allows controllers to distinguish
+physical host.  This key allows controllers to distinguish
 between multiple hypervisors.
 
 Most of this configuration can be done with the ovs-ctl command at startup.
@@ -114,7 +107,7 @@ For example:
 
 ::
 
-    $ ovs-ctl --system-type="XenServer" --system-version="6.0.0-50762p" \
+    $ ovs-ctl --system-type="KVM" --system-version="4.18.el8_6" \
         --system-id="${UUID}" "${other_options}" start
 
 Alternatively, the ovs-vsctl command may be used to set a particular value at
@@ -132,9 +125,7 @@ Bridge table
 ------------
 
 The Bridge table describes individual bridges within an Open vSwitch instance.
-The ``external-ids:bridge-id`` key uniquely identifies a particular bridge.  In
-XenServer, this will likely be the same as the UUID returned by ``xe
-network-list`` for that particular bridge.
+The ``external-ids:bridge-id`` key uniquely identifies a particular bridge.
 
 For example, to set the identifier for bridge "br0", the following command can
 be used:
@@ -161,18 +152,14 @@ attached-mac
 
   This field contains the MAC address of the device attached to the interface.
   On a hypervisor, this is the MAC address of the interface as seen inside a
-  VM.  It does not necessarily correlate to the host-side MAC address.  For
-  example, on XenServer, the MAC address on a VIF in the hypervisor is always
-  FE:FF:FF:FF:FF:FF, but inside the VM a normal MAC address is seen.
+  VM.  It does not necessarily correlate to the host-side MAC address.
 
 iface-id
 
   This field uniquely identifies the interface.  In hypervisors, this allows
   the controller to follow VM network interfaces as VMs migrate.  A well-chosen
   identifier should also allow an administrator or a controller to associate
-  the interface with the corresponding object in the VM management system.  For
-  example, the Open vSwitch integration with XenServer by default uses the
-  XenServer assigned UUID for a VIF record as the iface-id.
+  the interface with the corresponding object in the VM management system.
 
 iface-status
 
diff --git a/Documentation/tutorials/index.rst b/Documentation/tutorials/index.rst
index 5ec62beab..e73ee75ce 100644
--- a/Documentation/tutorials/index.rst
+++ b/Documentation/tutorials/index.rst
@@ -29,12 +29,6 @@ Tutorials
 
 Getting started with Open vSwitch (OVS).
 
-.. TODO(stephenfin): We could really do with a few basic tutorials, along with
-   some more specialized ones (DPDK, XenServer, Windows). The latter could
-   probably be formed from the install guides, but the former will need to be
-   produced from scratch or reproduced from blogs (with permission of the
-   author)
-
 .. toctree::
    :maxdepth: 2