Scenario #2, Tutorial #2, Part #2

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;
4. configured an IP address on each of the storage interfaces on each of the members of the resource pool, and;
5. configured the 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).

Each of the XS hosts in the PXS Lab have six NIC’s. In this Scenario: We will be combining these six NIC’s into three bonds.

TABLE #1

First: We’ll begin by validating the default state of networking in the resource pool (e.g., identifying the pool master (PM); verifying that Open vSwitch [OVS] is configured as the network stack throughout the resource pool, and; verifying that the installation process successfully identified and configured all six of the NIC’s).

Then: We’ll finish with creating the bonds themselves along with some new, additional, virtual infrastructure that will form a part of the new bonds (e.g., creating a new virtual switch for each of the new bonds).

And then, finally: We’ll conclude this Tutorial by reviewing the final network configuration and discuss some of the changes that are visible in the configuration of the pool members.

Validation

We’ll begin by reviewing the default state of networking in the resource pool.

First: We’ll verify that Open vSwitch (OVS) is configured as the network stack on each of the hosts in the resource pool; that the OVS daemon is running on each of the hosts, and that there are not already any existing bonds configured on either of the two hosts.

1. Confirm that OVS is configured as the network stack on each of the hosts in the resource pool:

   
   

   Legend: GET | SEE | USE

   [root@xs-1 ~]# xe-get-network-backend
   openvswitch

   [root@xs-1 ~]# xe host-list params=software-version | cut -d ‘;’ -f 16
   network_backend: openvswitch
   network_backend: openvswitch

2. Confirm that the OVS daemon is running on each of the hosts:

   
   

   Legend: GET | SEE | USE

   [root@xs-1 ~]# hostname
   xs-1

   [root@xs-1 ~]# service openvswitch status
   ovsdb-server is running with pid 2378
   ovs-vswitchd is running with pid 2400
   ovs-xapi-sync is running with pid 2407

   
   

   Legend: GET | SEE | USE

   [root@xs-2 ~]# hostname
   xs-2

   [root@xs-2 ~]# service openvswitch status
   ovsdb-server is running with pid 2414
   ovs-vswitchd is running with pid 2436
   ovs-xapi-sync is running with pid 2443

3. Verify that that no other bonds exist on either of the two hosts:

   
   

   [root@xs-1 ~]# hostname
   xs-1

   [root@xs-1 ~]# xe bond-list

   [root@xs-1 ~]# ovs-appctl bond/list
   bond type slaves

   
   

   [root@xs-2 ~]# hostname
   xs-2

   [root@xs-2 ~]# xe bond-list

   [root@xs-2 ~]# ovs-appctl bond/list
   bond type slaves

   Notice that the xe bond-list command and the ovs-apptcl bond/list command both return a null list (i.e., an empty list) but the ovs-apptcl bond/list prepends the null list with column headers.

Then: We’ll review the initial state of the networking configuration on the PM. (Though this step isn’t completely necessary, it is a good opportunity to review the status of networking on the hosts before we make any changes.)

There are three important things to notice this example:

1. There has been a network created for every interface on each of the two hosts.
   
   During installation, XenServer also creates a separate network for each NIC it detects on the host.

   Chapter 2 of Citrix XenServer Design: Designing XenServer Network Configurations

2. The networks that have been created for every interface are present on all hosts in the pool and they are identical. i.e., The networks are named identically and given identical UUID’s.
3. The xe pif-list command allows the inspection of other hosts in the pool. But the xe network-list command does not (for the reason that we just mentioned, above). So we’ve had to perform these commands on each host, individually.

Creation

Bonds are created on the pool-master (PM) and then inherited by the other members of the pool.

Our first step will be to identify the PM:

After identifying the PM we’ll perform the configuration changes on the PM and then restart the XAPI service on each of the members of the pool.