How to Create and Add Citrix XenServer Storage Repositories – Part 4

In the fourth article of this XenServer series, storage solutions will be discussed. Much like networking, storage solutions in XenServer are often difficult to grasp at first. Before beginning any configuration, the new terminology and concepts involved in XenServer storage should be discussed.

Update: In May 2016, Citrix released the new version of the XenServer 7 platform. For installation follow: Fresh Installation of XenServer 7.

XenServer introduces several new terms to the traditional storage terminology list. While understanding the concepts are always important when working with any IT system, storage isn’t nearly as crucial as the prior article covering networking concepts. However, this article will still take the time to explain and attempt to clarify these storage concepts.

The first thing to remember with XenServer storage is that we have storage for the actual XenServer host and then we also have storage for the guest or virtual machines that will run on the XenServer host. Conceptually this is simple to grasp but managing it can be a daunting task if the administrator is unfamiliar with the purposes of each of the storage aspects.

The first term is known as ‘SR’ or Storage Repository. This is arguably the most important term in XenServer storage as it represents the physical medium to which virtual machine disks will be stored and retrieved. Storage repositories can be any of several different types of storage systems including, local storage attached physically to the XenServer host, iSCSI/Fibre Channel LUN, NFS Network File Shares, or storage on a Dell/NetApp storage appliance.

Storage repositories can be shared or dedicated and can support numerous useful features such as fast cloning, sparse allocation (storage provisioned as the virtual machine needs it), and re-sizable virtual disk images (more on these later).

Storage repositories, SR, are logically connected to a XenServer host with what is known as a Physical Block Device, more commonly referenced as ‘PBD’. The PBD is simply a reference to a storage location. These PBD objects can be “plugged” into a XenServer host to allow that host to read/write information to that storage repository.

The purpose of Storage repositories is primarily to store the virtual machine Virtual Disk Image (VDI) files. VDI files are spots on a SR that have been allocated to hold operating system and other files for virtual machine running on the XenServer host. VDI files can be any of several different types. The type is determine by the type of storage repository.

Common VDI types in XenServer are Logical Volumes (LV) managed by Logical Volume Manager, Virtual Hard Disk (VHD), or they can be Logical Unit Numbers (LUN) on a Dell or NetApp storage device. Note: This article will be using LUNs on a Dell storage device.

These VDI files are connected to virtual machines logically through an object known as a Virtual Block Device, commonly referenced as ‘VBD’. These VBD objects can be attached to virtual guests which then allows the guest machine to access the data stored in that particular VDI on a respective SR.

Much like networking in XenServer, reading about storage is one thing but being able to see the relationship amongst each of these items often solidifies the concepts. The common diagrams used to represent XenServer storage concepts often confuses newer people as the diagrams are often read in a linear fashion. Below is one such image borrowed from Citrix.

Many individuals read this linearly from left to right thinking that each part is a separate physical device. This isn’t the case and often leads to much confusion about how XenServer storage works. The graphic below attempts to explain the concepts in a less linear but more pragmatic manner.

Hopefully the above graphic doesn’t further confuse individuals about XenServer storage. The second image is an attempt to show the logical connections (PBD and VBD) that are used to connect XenServers and guests to remote storage over one actual network connection.

With the conceptualization out of the way; the configuration can begin. Recalling from the first article in this series, this guide is using a Dell PS5500E iSCSI storage device for the storage of the virtual machine (guests) disks. This guide will not be walking through configuration of the Dell iSCSI device.

System Configuration:

1. XenServer 6.5 installed and patched (Part 1 of series)
2. Dell PS5500E iSCSI device (other iSCSI devices can be used just substitute environment information where needed).
3. XenServer network interfaces configured (Part 3 of series).
4. iSCSI device and XenServer can logically see each other (via ping utility).
5. CIFS (SAMBA) Server running and hosting a share of CD ISO files (not required but very useful).

Citrix XenServer Storage Repository Creation

This first process will go through the steps to create a software iSCSI initiator from the XenServer host to the Dell PS5500E.

This particular LUN uses Challenge-Handshake Authentication Protocol (CHAP) to restrict access to the iSCSI volume to certain authorized parties.

To create the storage repository, a traditional ‘xe’ command will occur. The proper iSCSI information needs to be obtained before creating the Storage Repository.

Passing the ‘sr-probe’ parameter to the ‘xe’ utility will instruct the XenServer to query a storage device for the iSCSI IQN (iSCSI Qualified Name).

The first command will look intense at first but it’s not as bad as it looks.

# xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"

This first command is needed to gather the SCSI IQN for the Storage repository configuration. Before moving on, let’s take a look at all the parts of this command.

1. sr-probe – Used to query the iSCSI device for information about the volume created for this XenServer host.
2. type= Used to tell the XenServer the storage repository type. This will vary depending on what system is being used. Due to the usage of the Dell PS5500, lvm over iSCSI is used in this command. Be sure to modify to fit the storage device type.
3. device-config:target= Used to tell the XenServer what iSCSI device to query by IP address.
4. device-config:chapuser= This is used to authenticate to the iSCSI device. In this example an iSCSI volume has been created previously for the user “tecmint”. By sending the user-name and password in this command, the iSCSI device will respond back with the necessary information to finish creating the storage repository.
5. device-config:chappassword= This is the password for the above CHAP user-name.

Once the command is entered and submitted, the XenServer will attempt to log into the iSCSI device and will return some information needed in order to actually add this iSCSI device as a Storage Repository.

Below is what the test system returned from this command.

Error code: SR_BACKEND_FAILURE_96
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target-iqns>
        <TGT>
                 <Index>
                              0
                 </Index>
                 <IPAddress>
                 </IPAddress>
                 <TargetIQN>
                              iqn.2001-05.com.equallogic:0-8a096-0d9a4ab02-46600020343560ef-xenct-xen2
                 </TargetIQN>
        </TGT>
        <TGT>
                 <Index>
                 
                 </Index>
                 <IPAddress>

                 </IPAddress>
                 <TargetIQN>

                 </TargetIQN>
        </TGT>
</iscsi-target-iqns>

The highlighted piece here is known as the iSCSI IQN. This is very important and is needed to determine the SCSIid for the storage repository. With this new information, the prior command can be modified to obtain the SCSIid.

# xe sr-probe type=lvmoiscsi device-config:target=X.X.X.X device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap"

The only thing added to the command is the targetIQN stanza. By issuing this new command, the system will respond with the last piece of information needed to create an iSCSI Storage Repository. That last piece of information is the SCSI id.

Error code: SR_BACKEND_FAILURE_107
Error parameters: , The SCSIid parameter is missing or incorrect , <?xml version"1.0" ?>
<iscsi-target>
        <LUN>
                 <vendor>
                        EQLOGIC
                 </vendor>
                 <serial>
                 </serial>
                 <LUNid>
                         0
                 </LUNid>
                 <size>
                         107379425280
                 </size>
                 <SCSIid>
                         36090a028b04a9a0def60353420006046
                 </SCSIid>
        </LUN>
</iscsi-target>

From this point, all the necessary pieces to create an iSCSI Storage Repository are available and it is time to issue the command to add this SR to this particular XenServer. Creating the Storage Repository from the combined information is done as follows:

# xe sr-create name-label="Tecmint iSCSI Storage" type=lvmoiscsi content-type=user device-config:target=X.X.X.X device-config:port=3260 device-config:targetIQN=iqn.2001-05.com.equallogic:0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config:chapuser="tecmint" device-config:chappassword="tecmint_chap" device-config:SCSIid=36090a028b04a9a0def60353420006046

If all goes well the system will connect to the iSCSI device and then return the UUID of the newly added Storage Repository.

bea6caa4-ecab-8509-33a4-2cda2599fb75

The UUID output is a great sign! As with all system administration tasks, it is always a good idea to confirm that the command was successful. This can be accomplished with another ‘xe’ command.

# xe sr-list name-label="Tecmint iSCSI Storage"

Sample Output

uuid ( RO)                 : bea6caa4-ecab-8509-33a4-2cda2599fb75
          name-label ( RW) : Tecmint iSCSI Storage
    name-description ( RW) :
                host ( RO) : xenct-xen2
                type ( RO) : lvmoiscsi
        content-type ( RO) : user

From the CLI output this XenServer has successfully connected to the Dell iSCSI device and is ready to store guest VDI files.

ISO Storage Repository Creation

The next series of steps walks through the process of creating an ISO library. ISO files are typically images of compact disk (CD) installation media.

By having a special storage repository created for these ISO files, the installation of new guests can be done very quickly. When an administrator wishes to create a new guest, they can simply select one of the ISO files that exist in this ISO library rather than having to put a CD physically in a XenServer in the pool.

This part of the guide will assume that the user has a working SAMBA server. If a SAMBA server isn’t setup please feel free to read this article about how to complete this task in Red Hat/Fedora (I will have a Debian SAMBA server guide in the future):

1. Setup Samba Server for File Sharing

The first step is to gather the necessary credentials and configuration information for the SAMBA ISO library. Once the username, password, and connectivity information are available a simple ‘xe’ command variant can be used to connect the SAMBA library to the XenServer.

# xe-mount-iso-sr //<servername>/ISO -o username=<user>,password=<password>

This command won’t output anything to the screen unless it fails. To confirm that it did indeed mount the SAMBA ISO share, issue another ‘xe’ command:

# xe sr-list

Sample Output

uuid ( RO)                 : 1fd75a51-10ee-41b9-9614-263edb3f40d6
          name-label ( RW) : Remote ISO Library on: //                  /ISO
    name-description ( RW) :
                host ( RO) : xenct-xen2
                type ( RO) : iso
        content-type ( RO) : iso

This XenServer host is now configured with both an iSCSI Storage Repository as well as a CIFS ISO library to store installation media for virtual machines (guests).

The next steps will be the creation of virtual machines and connecting those systems to the proper networks from the earlier networking article.