|Status||released (5.6 FP1)|
|Review||create new issue|
To isolate network traffic between VMs (e.g. for security reasons) one can use VLANs. The number of possible VLANs on a network, however, is limited, and setting up a VLAN requires configuring the physical switches in the network. GRE tunnels provide a similar, though more flexible solution. This document proposes a design that integrates the use of tunnelling in the XenAPI. The design relies on the recent introduction of the Open vSwitch, and requires an Open vSwitch (OpenFlow) controller (further referred to as the controller) to set up and maintain the actual GRE tunnels.
We suggest following the way VLANs are modelled in the datamodel. Introducing a
VLAN involves creating a Network object for the VLAN, that VIFs can connect to.
VLAN.create API call takes references to a PIF and Network to use and a
VLAN tag, and creates a VLAN object and a PIF object. We propose something
similar for tunnels; the resulting objects and relations for two hosts would
look like this:
PIF (transport) -- Tunnel -- PIF (access) \ / VIF Network -- VIF PIF (transport) -- Tunnel -- PIF (access) / \ VIF
PIF ref access_PIF(read-only)
PIF ref transport_PIF(read-only)
(string -> string) map status(read/write); owned by the controller, containing at least the key
errorwhen appropriate (see below)
(string -> string) map other_config(read/write)
New fields in PIF class (automatically linked to the corresponding
PIF ref set tunnel_access_PIF_of(read-only)
PIF ref set tunnel_transport_PIF_of(read-only)
tunnel ref create (PIF ref, network ref)
void destroy (tunnel ref)
For clients to determine which network backend is in use (to decide whether
tunnelling functionality is enabled) a key
network_backend is added to the
Host.software_version map on each host. The value of this key can be:
bridge: the Linux bridging backend is in use;
openvswitch: the [Open vSwitch] backend is in use.
The user is responsible for creating tunnel and network objects, associating VIFs with the right networks, and configuring the physical PIFs, all using the XenAPI/CLI/XC.
tunnel.status field is owned by the controller. It
may be possible to define an RBAC role for the controller, such that only the
controller is able to write to it.
tunnel.create message does not take
a tunnel identifier (GRE key). The controller is responsible for assigning
the right keys transparently. When a tunnel has been set up, the controller
will write its key to
tunnel.status:key, and it will set
"true" in the same field.
In case a tunnel could
not be set up, an error code (to be defined) will be written to
tunnel.status:active will be
OPENVSWITCH_NOT_ACTIVEif the Open vSwitch networking sub-system is not active (the host uses linux bridging).
IS_TUNNEL_ACCESS_PIFif the specified transport PIF is a tunnel access PIF.
tunnel.status:activefield is initialised to
"false", indicating that no actual tunnelling infrastructure has been set up yet.
PIF.plugon the new tunnel access PIF.
PIF.unplugon the tunnel access PIF. Destroys the
tunneland tunnel access PIF objects.
TRANSPORT_PIF_NOT_CONFIGUREDif the underlying transport PIF has
PIF.ip_configuration_mode = None, as this interface needs to be configured for the tunnelling to work. Otherwise, the transport PIF will be plugged.
interface-reconfigureto “bring up” the tunnel access PIF, which causes it to create a local bridge.
interface-reconfigure. The controller is responsible for setting up these links. If the controller is not available, no links can be created, and the tunnel network degrades to an internal network (only intra-host connectivity).
PIF.currently_attachedis set to
interface-reconfigureto “bring down” the tunnel PIF, which causes it to destroy the local bridge.
PIF.currently_attachedis set to
PIF.unplugon the associated tunnel access PIF(s).
IS_TUNNEL_ACCESS_PIFif given an underlying PIF that is a tunnel access PIF.
tunnelclass to determine which bridges/networks require GRE tunnelling.
tunnel.get_allto obtain the information about all tunnels.
tunnelclass to stay up-to-date.
"true"for all tunnel links that have been set up, and
"false"if links are broken.
tunnel.status:errorin case something went wrong.
tunnel.status:keyon the associated tunnel object (at the same time
tunnel.status:activewill be set to
tunnel.status:key(optional; the key should anyway be disregarded if
xe commands (analogous to