Scenario #2, Tutorial #2, Part #1

In the previous tutorial, we…

1. joined two XenServer (XS) hosts together to form a XenServer resource pool;
2. configured an NFS shared storage repository (SR) for XS hosts to store guests’ virtual hard disk drives (VHD);
3. created a dedicated storage network for the XenServer hosts to use when communicating with the SR, and;
4. configured that NFS shared SR as the default SR for the resource pool.

In this tutorial, we are going to improve the resiliency and the performance of networking within XenServer (XS). But first: Let’s begin with a brief discussion of Networking and XS!

Our objective in this tutorial will be to improve the resiliency and the performance of networking within XenServer but we will not be concerned with isolation in this tutorial.

The Two Alternative Network Stacks of XenServer

For all intents and purposes: XenServer (XS) is a virtualization appliance. It is built using two major components: The Xen Project Hypervisor and a highly-customized version of CentOS Enterprise Linux:

• The Xen Project Hypervisor provides the virtualization component.
• CentOS Enterprise Linux provides the control domain (i.e., Dom0) in the form of a virtual machine (VM).

Because XenServer utilizes CentOS to provide the control domain, and; because CentOS is a Linux distribution: It should not be surprising to XS administrators that the XS network stack is built upon the Linux network stack. It should also not be surprising that, because Linux is an open source operating system, the Linux network stack is modular and extensible.

In XenServer two alternative components are used to extend the network functionality provided by Linux: Linux Bridge* and Open vSwitch. The two network stacks are mutually-exclusive. XS Administrators are able to easily select the network stack used in their XS environments using tools that have been provided with XAPI.

XenServer and Linux Bridge

Linux Bridge was the original network stack of XenServer. Linux Bridge is still available in XS but has been deprecated since Version 6.5 of XS.

What is Linux Bridge?

Linux Bridge was introduced into the Linux Kernel in Version 2.2 of the Linux Kernel. It was later re-written for Version 2.4 and Version 2.6 of the Linux Kernel and continues to be present in the current version of the Kernel.

Why use Linux Bridge?

The Linux Bridge is quite stable, widely-used, and very well-understood because it’s been around for so long and is used so widely. Linux administrators may interact with Linux Bridge using standard command-line tools (e.g., the brctl) command. (However, in XenServer, all network configuration is performed using the XAPI command: xe.)

XenServer and Open vSwitch

Open vSwitch is the next generation network stack for XenServer. Open vSwitch was introduced into XS in Version 5.6, Feature Pack 1, and, as of XenServer Version 6.0, has become the default network stack in XS.

What is Open vSwitch?

From the Open vSwitch Web site:

Why use Open vSwitch?

Using Open vSwitch is required for many of the advanced network features of XS:

1. Cross-server private networks
2. NIC Bonds that contain more than two NIC’s
3. NIC Bonds that operate in LACP bonding mode
4. Jumbo Frames
5. OpenFlow®

The Future of Networking in XenServer

Open vSwitch has been available in XS since Version 5.6, Feature Pack 1 and has been the default network stack for XS since Version 6.0 and will continue to be the default network stack in future version XenServer:

In this tutorial we will use the default network stack in Version 6.5 of XenServer: Open vSwitch.

Identifying and Changing the Network Stack in XenServer

XS Administrators almost never change the network stack in their infrastructure but identifying and changing the network stack can all be easily performed from the CLI. (Remember that, in this Scenario, we’ll be making use of the default network stack in Version 6.5 of XenServer [Open vSwitch] so we will not be using any of the commands illustrated throughout this section of the tutorial.)

Identifying the Current Network Stack in XenServer

Two different commands can be used to identify the network stack that is currently configured on a XS host:

Obviously, the first command is the most convenient and the least prone to human error – So we recommend using the xe-get-network-backend command to identify the network stack currently in use on the XS host.

Changing the Current Network Stack in XenServer

The xe-get-network-backend command has a compliment: The xe-switch-network-backend command!

The xe-switch-network-backend command can be used, along with the openvswitch command-line argument or the bridge command-line argument, to select which network stack the XS host will use. The Citrix whitepaper “XenServer Design: Designing XenServer Network Configurations” outlines the process this way:

Bridges and Switches and Networks – Oh, my!

In the XS vernacular a bridge is really the same thing as a [virtual] switch. Adding to the peculiarity of XS terminology is the fact that a bridge is called a network:

To reiterate: In XenServer…

• A bridge is the same thing as a switch.
• Both are called a network.

Got it?

Network Bonding

In order to improve the resiliency and the performance of the networking in XS, we’ll use a common technique that goes by many names: Network Bonding.

Though NIC Bonding has many different names, it always describes the same concept: The joining of multiple, physical NIC’s into a single, logical NIC. The resulting, logical NIC behaves as a single NIC that offers increased resiliency and, in some configurations, increased throughput.

Though it’s recommended to configure bonds prior to creating the resource pool…

…we’ll be configuring the bonds after the hosts have been joined into a resource pool. Also, because we’re not using XenCenter (XC), we’ll be configuring bonds on each member of the pool, individually:

Network Bonding Modes

XenServer 6.5, Service Pack 1 supports 3 modes of network bonding:

• Active-Active,
• Active-Passive, and
• LACP

The three modes have very different use-cases and some modes and configurations are only available when using the Open vSwitch network stack:

The technical details of NIC bonding can be very complex but Wikipedia provides a good explanation of the different bonding modes using slightly different names for the bonding modes:

Different Bond Modes for Different Use-Cases

Citrix makes the following recommendations regarding the creation and configuration of different types of interfaces:

To be direct: Citrix recommends…

• active-passive bonds for primary and secondary interfaces, and
• active-active bonds for guest [external] interfaces.

Each of the XS hosts in the PXS Lab have six NIC’s. In our Scenario: These NIC’s will be combined into three bonds:

TABLE #1

Conclusion

In the previous Tutorial, we had configured the IP address of two interfaces on the host xs-1:

• The Primary Management Interface (172.16.0.10/28), and
• The Storage Interface (172.16.0.35/28).

In Part 2 of this Tutorial, we’ll see how the IP addresses that we’ve already configured are inherited by the bonds that we create.

* Technically speaking: Linux Bridge has been integrated into the Linux network stack since Kernel Version 2.2 and, as such, Linux Bridge does not extend the functionality of the Linux network stack as much as it forms an important piece of the Linux network stack. However – for the purposes of this discussion – we’re going to consider it to still be separate from the Linux Kernel.