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.
- XenServer 6.5 installed and patched (Part 1 of series)
- Dell PS5500E iSCSI device (other iSCSI devices can be used just substitute environment information where needed).
- XenServer network interfaces configured (Part 3 of series).
- iSCSI device and XenServer can logically see each other (via ping utility).
- 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.
- sr-probe – Used to query the iSCSI device for information about the volume created for this XenServer host.
- 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.
- device-config:target= Used to tell the XenServer what iSCSI device to query by IP address.
- 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.
- 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.
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"
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):
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
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.
2 thoughts on “How to Create and Add Citrix XenServer Storage Repositories – Part 4”
Thanks for the response. Quite a few questions in the post but let’s try to get them answered for you.
Clonezilla is a fantastic bit-stream copy software. As such it should copy all information from the chosen disk device. Now the question about whether or not the UEFI system will be bootable on XenServer after restoring the image, I don’t have a definite answer for as I have never tried. A quick search through the Xen hypervisor site suggests that guest EFI support is there but limited. I will research this and see if I can get a working proof of concept though.
I may be misunderstanding your second paragraph but in order to install XenServer you’ll have to either cleverly partition the disk on your system to install XenServer/Windows side by side but the normal install process will overwrite anything on the disk to which is is being installed. So you’ll end up installing XenServer to your HP machine, building or importing your Windows machine’s disk image as a guest on the XenServer, and then you’ll either use VNC, Xencenter, Xen Orchestra, or OpenXenManager to connect to the console session of the running Windows virtual machine. To my knowledge, there isn’t a way to connect to the console session of a DomU guest from Dom0.
To make working in Dom0 easier, remember that the CLI has auto complete so if you start typing part of a UUID and hit the tab key, XenServer will automatically fill in the rest of the UUID for you. According to Citrix any modification to Dom0 is considered experimental and as such they typically won’t provide any assistance so I definitely wouldn’t install anything on production XenServer installs. Disclaimer out of the way, XenServer runs on CentOS so in theory, anything that can be done in CentOS can be done in XenServer. Even on my test systems though, I don’t modify anything in Dom0 simply for stability’s sake.
The SAMBA ISO share is a separate system it isn’t part of Dom0. Now the SAMBA share can be a guest/virtual machine running on the XenServer; I’ve done that many times.
Please let me know if there is anything else that needs clarified or if you have more questions as a result of this answer!
The Citrix XenConvert 2.4.1 Guide on page 3 under Known Limitations states: “Firmware Type – XenConvert can only convert from a host machine with BIOS firmware – not Extensible Firmware Interface (EFI).” Will imaging Clonezilla to P2V circumvent this issue? If not, would a fresh install from MS-Windows recovery disks under “legacy mode” instead of UEFI resolve the issue. That is something I can try as I have a new drive and I can mess around with it some. I am trying to us XenServer 6.5 on a HP h-1520t. Would I be better off using another p2v conversion method or different virtualiztion software?
I am trying to setup up Xenserver 6.5 on my desk top. I have assumed that after it is all set up, I will still be able to use windows and all my applications just as before from the same desk, keyboard, monitors and the same computer which will be my XenSeerverHost via VNC into a virtual machine. When I read about VNC it seems that people are using a different computer such as my Old_Goat that I am running OpenXenManager on to VNC into the VMs. Even after reading all your wonderfully through XenServer articles I still have not been able to reach a definite conclusion on this issue so I have to ask. Can I use a VNC viewer to work from my XenServerHost machine? In other words, can a person VNC from dom0 into a VM on the same machine?
There are so many commands/features not available in the XenServer console. I think of gpm’s mouse copy and paste when I am typing in the UUID’s. It has yum but not apt-get. Are there packages you like to install on dom0 to make life work better.
Are you thinking of Dom0 or a VM when you say to set up samba as an ISO library.
I had in interesting problem with XenServer 6.5 booting on a HP h-1520t. It never booted until I accidently discovered it would boot if a bootable cd was present in the drive and triggered the any-key message. I took 4 pages of notes as I went through all kinds of boot order setting on the computer. It does not matter if the legacy hard drive is before or after the cd, XenServer 6.5 only boots for me after the “press any key to boot from the cd” message is triggered and times out. I think it is a firmware problem on this model (I have the latest firmware). I think it might be able to boot if the firmware boots another drive with a boot loader (grub) to boot XenServer 6.5 but I have not tried it yet.
Sorry for the number of questions and the length. You are the best source I have found and I read it. I have struggled for 2 weeks now.