XenServer

Installing and Configuring Citrix Xenserver 6.5 – Part 1

Installing and Configuring Citrix Xenserver 6.5 &-8211; Part 1 &-8211; this Article or News was published on this date:2019-05-28 18:17:31 kindly share it with friends if you find it helpful

As computing devices quickly surpass the requirements of operating systems, it has increasingly become more efficient for organizations to invest/migrate to virtualized systems. Operating system virtualization technologies aren’t anything new but over the last several years they have become more and more popular as data centers look to provide more functionality in the same or less amounts of physical space. By simply leveraging un-used resources on powerful servers/workstations companies can effectively run multiple logical servers on one or several physical servers.

XenServer Installation Guide in LinuxXenServer Installation Guide in Linux

XenServer Installation and Configuration Guide – Part 1

Citrix offers such a solution, known as XenServer, which utilizes the popular Linux Xen hypervisor. The Xen hypervisor is referred to as a “bare-metal hypervisor” meaning that it is installed to the physical server and acts as a resource manager for all of the virtualized server instances that will be run on top of Xen.

This contrasts to systems such as Virtualbox which require a Linux/Mac/Windows operating system to be installed and then virtual machines created within the Virtualbox application. This type of hypervisor is generally referred to as a hosted hypervisor. Both types of hypervisors have their place and benefits but this particular article is going to look at the bare-metal hypervisor in XenServer.

In this 5-article Citrix Xenserver series, we will going to cover the following topics:

Part 1: Installation and Configuring XenServer 6.5

Update*: In May 2016, Citrix released the new version of the XenServer 7 platform.

This first article will walk through the process of installing and configuring Citrix XenServer. Future additions to this article will walk through adding virtual machine storage repositories, XenServer pooling, creating virtual machines on the XenServer, as well as managing XenServers with XenCenter and Xen Orchestra as discussed above series.

System Requirements

  1. XenServer 6.5 ISO : http://xenserver.org/open-source-virtualization-download.html
  2. Server capable of virtualization
    1. Hardware Compatibility List is here: http://hcl.xenserver.org/
    2. Many systems will work even if not listed but results may vary, use at your own risk.
  3. Minimum 2GB ram; 4GB or more recommended to run virtual machines
  4. Mimimum 1 64bit 1.5GHz cpu; 2GHz or more and multiple CPUs are suggested
  5. Harddrive space of at least 16GB; more required if virtual machines will be saved locally
  6. At least a 100mbps network card; multiple gigabit suggested

Test System Configuration

  1. 1 IBM X3850
    1. 4 hexcore 2.66 GHz CPUs
    2. 64gb ram
    3. 4 gigabit NIC cards
    4. 4 300GB SAS drives (overkill but it was all that was available)
  2. 24TB Dell PE5500E for storage of the virtual machine disks (Not necessary if enough local space exists on the XenServer)

All in all this server is primed to be a stellar XenServer so let’s begin the installation process.

Installation of Citrix Xenserver 6.5 Guide

1. The first step in the installation is to download the XenServer ISO file. This can easily be accomplished by visiting the link above or using the ‘wget‘ utility on a Linux system.

- wget -c http://downloadns.citrix.com.edgesuite.net/10175/XenServer-6.5.0-xenserver.org-install-cd.iso

Now burn the ISO to a CD or using ‘dd‘ to copy the ISO to a flash drive.

- dd if=XenServer-6.5.0-xenserver.org-install-cd.iso of=/path/to/usb/drive>

2. Now place the media into the system that XenServer will be installed and boot to that media. Upon successful boot the user should be greeted by the wonderful Citrix XenServer boot splash.

XenServer Installation Guide in LinuxXenServer Boot Menu

XenServer Boot Menu

3. At this point simply press enter to begin the booting process. This will boot the user into the XenServer installer. The first screen will ask the user to provide a language selection.

XenServer Installation Guide in LinuxSelect XenServer Installation Language

Select XenServer Installation Language

4. The next screen asks the user to confirm the reason for booting to this media as well as provide the option to load extra hardware drivers if needed. In this particular case, it is to install XenServer to the machine so it is safe to click “OK”.

XenServer Installation Guide in LinuxLoad XenServer Device Driver

Load XenServer Device Driver

5. The next prompt is the obligatory EULA (End User License Agreement). Feel free to read the whole thing, as your supposed to anyways right, otherwise using the keyboard arrows move the cursor over to the “Accept EULA” button and hit enter.

XenServer Installation Guide in LinuxAccept License Agreement

Accept License Agreement

6. The next screen requests the installation device. In this example the RAID setup on the server is where XenServer will be installed.

The RAID system is reflected as “sda – 556 GB [IBM ServeRAID-MR10k]” For this guide, thin provisioning is not necessary. Make sure the the asterisk ( * ) character is next to the hard drive selection to install XenServer and tab to the “OK” button.

XenServer Installation Guide in LinuxSelect XenServer Virtual Machine Storage

Select XenServer Virtual Machine Storage

7. The next screen will prompt the user for the location of the installation files. Since the installer was boot locally with a CD/DVD/USB, make sure to select the “Local Media” option.

XenServer Installation Guide in LinuxSelect XenServer Installation Source

Select XenServer Installation Source

8. The next step allows for the installation of Supplemental Packs (SP) at the time of install. For this guide, none of the supplemental packs available will be installed at this point but will be covered later once XenServer is up and running.

XenServer Installation Guide in LinuxSelect Supplemental Packs

Select Supplemental Packs

9. The next screen will ask if the user wishes to verify that the installer media is not corrupt. Generally this is a good idea but is a personal choice. All in all the verification on this test server took about 3 minutes from a CD.

XenServer Installation Guide in LinuxVerify XenServer Installation Media

Verify XenServer Installation Media

XenServer Installation Guide in LinuxChecking Base Pack

Checking Base Pack

XenServer Installation Guide in LinuxVerification Successful

Verification Successful

Installing XenServer 6.5 Patches with Local Media and Remotely – Part 2

Installing XenServer 6.5 Patches with Local Media and Remotely &-8211; Part 2 &-8211; this Article or News was published on this date:2019-05-28 18:16:21 kindly share it with friends if you find it helpful

Patching a XenServer install is a crucial task to ensure security updates are applied to vulnerable XenServer installs. While in theory the hypervisor is secure from the virtual machines it supports, there are still some potential issues that could happen and Citrix, as well as the rest of the open source community, do their best to provide code updates for these vulnerabilities as they are discovered.

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

Install XenServer Patches in LinuxInstall XenServer Patches in Linux

Install XenServer Patches in Linux – Part 2

That being said, these updates aren’t applied automatically by default and require administrator interaction. Patches also aren’t always security issues. Many times patches will provide increased functionality to the virtual machines hosted on the XenServer. Applying these updates is typically very easy and straight forward and can be done remotely or with local media (local to the XenServer).

While this article is going to walk through applying patches to one XenServer, it is important to note that in the event that multiple pooled XenServers need updated, tools exist to allow the pool master to push the updates out to all of the other XenServers in the pool!

Let’s begin the process of updating a single XenServer by means of local media. Local in this instance means that the administrator has put the update files onto a CD/DVD/USB or similar device and will physically connect this media to the XenServer needing updated.

The first step in this whole process is to obtain the patches. Publicly available patches can be obtained from the following URL:

  1. http://support.citrix.com/article/CTX138115

This guide is going to walk through installing the XenServer 6.5 SP1 patch both using local media as well as remotely sending the update files to the server and then updating remotely.

The patch files are located here: http://support.citrix.com/article/CTX142355

This supplemental pack contains a lot of the patches already put out for XenServer 6.5. It is important to note Citrix’s notes about any patch as many patches require other patches be installed BEFORE! The only prerequisite for this patch is that XenServer 6.5 be installed (which should be covered already).

The file can be downloaded via http or via the wget tool.

- wget -c http://downloadns.citrix.com.edgesuite.net/10340/XS65ESP1.zip

Installing Patches with Local Media

Once the file is downloaded, the contents of the zip file need to be extracted. This can be accomplished with gui tools or via the command line using the ‘unzip‘ tool.

- unzip XS65ESP1.zip

Upon successful completion, two files should now exist in the current working directory. The one of importance will be the file with the extension ‘.xsupdate‘.

Install XenServer Patches in LinuxUnpack Xen Patch Update

Unpack Xen Patch Update

Now the file ‘XS54ESP1.xsupdate‘ needs to be copied to the installation media. Once the file has been transferred to the media, connect the media to the XenServer in need of the patch.

At this point a monitor and keyboard connected to the server will be needed to complete the update process. Upon connecting a monitor to the XenServer, the XenServer control panel page should be visible. Scroll down to the ‘Local Command Shell‘ selection and hit enter.

Install XenServer Patches in LinuxXen Server Local Command Shell

Xen Server Local Command Shell

This will prompt the user for the XenServer root user password and upon successfully entering that password, the user will be in a command prompt within the XenServer. At this point, the local media will need to be mounted to be accessible to XenServer. In order to do this, the name of the block device needs to be determined using the ‘fdisk‘ utility.

- fdisk -l
Install XenServer Patches in LinuxFind Media Disk

Find Media Disk

From this output the device name of the USB device plugged into the XenServer can be determined as ‘/dev/sdb1‘ and this is what will need to be mounted in order to access the update file. Mounting this device can be accomplished using the ‘mount‘ utility.

- mount /dev/sdb1 /mnt
Install XenServer Patches in LinuxMount Device

Mount Device

Assuming that the system didn’t throw out any errors, the USB device should now be mounted to the ‘/mnt‘ directory. Change to this directory and make sure that the update file is indeed showing up in this directory.

- cd /mnt
- ls
Install XenServer Patches in LinuxCheck Mounted Device

Check Mounted Device

At this point, the update file is accessible to the server and ready to be installed using the ‘xe‘ command. The first thing to do is prepare the patch file and obtain the UUID of the patch file with the ‘xe patch-upload‘ command. This step is important and must be done!

- xe patch-upload file-name=XS65ESP1.xsupdate
Install XenServer Patches in LinuxPrepare XenServer Patch File

Prepare XenServer Patch File

The box in red above is the output from the above command and will be needed when ready to actually install the patch to the XenServer system. Now the UUID of the XenServer itself is needed and can be determined again by passing arguments to the ‘xe‘ command.

- xe host-list
Install XenServer Patches in LinuxCheck XenServer UUID

Check XenServer UUID

Again the box in red is the UUID value that will be needed in order to apply the patch to this particular XenServer. At this point all of the necessary commands have been run and the UUID’s determine.

Once more using the ‘xe‘ command with different arguments, XenServer will be instructed to install the supplemental pack to this local system.

- xe patch-apply uuid=7f2e4a3a-4098-4a71-84ff-b0ba919723c7 host-uuid=be0eeb41-7f50-447d-8561-343edde9fad2
Install XenServer Patches in LinuxApply Patch to XenServer

Apply Patch to XenServer

At this point, the system will begin installing the update but will show nothing more than a flashing cursor until the process is completed. Once the system returns to a command prompt, the system can be checked to confirm that the patch was indeed installed again using the ‘xe’ command with different arguments.

- xe patch-list | grep -i sp1

This command will list all patches applied and then pipe that output into grep which will search for the string ‘sp1‘ regardless of case. If nothing is returned, then the patch likely did not install successfully.

Install XenServer Patches in LinuxList XenServer Installed Patches

List XenServer Installed Patches

If the command returns output similar to the above screen-shot, then the supplemental pack was installed successfully!

XenServer Network (LACP Bond, VLAN and Bonding) Configuration – Part 3

XenServer Network (LACP Bond, VLAN and Bonding) Configuration &-8211; Part 3 &-8211; this Article or News was published on this date:2019-05-28 18:12:56 kindly share it with friends if you find it helpful

In the third part of this series, the configuration of networking in XenServer will be discussed. Networking in XenServer is often a little difficult to grasp at first but is actually quite simple. The first task before configuration is to step back and understand all of the new terminology used by XenServer in reference to networking.

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

XenServer Network ConfigurationXenServer Network Configuration

XenServer Network Configuration – Part 3

Read Also:

Installing and Configuring XenServer – Part 1

Installing XenServer Important Patches – Part 2

XenServer, as a virtualization platform, introduces virtual interfaces for the guests that have to be mapped to physical interfaces or networks on the actual physical network that the XenServer itself is connected. This mapping is what often leads to confusion. So let’s take a look at these new terms and how they allow guests to interact with the actual physical network that is connected to the XenServer.

XenServer introduces three new terms when it comes to networking. The first of which is generally the easiest to understand as it is simply a variant of the traditional Network Interface Card (NIC). In XenServer, the actual physical NICs of a system are often referenced as Physical Interfaces or its acronym of ‘PIF‘.

The second term that XenServer will use is what is known as a Virtual Interface or more commonly its acronym of ‘VIF‘. These Virtual Interfaces represent the Network Interface Cards that will be attached to the guests (virtual machines) running on the XenServer.

The third term that is often used when talking about XenServer networking is the Xen Bridge whose acronym will vary but typically will be represented as ‘xenbr0‘. These bridges are created at the time of the XenServer install and one is created per each PIF (Physical Interface) that is found during the installation. These bridges are used to allow VIF (Virtual Interfaces) to communicate through PIF (Physical Interfaces).

Now that the terminology is out of the way, there are some special caveats when working with virtual interfaces. Since the virtual interfaces will be used to connect guests to networks, it is important to understand what is needed from these interfaces. One caveat that will cause individuals lots of grief is when a guest needs connectivity to two real networks from a XenServer.

In order to accomplish this task the virtual machine (guest) will need to have 2 VIFs (virtual interfaces) connected to it so that each can be on the appropriate network. This will require some manipulation of the guest’s routing table as well to ensure that guests communicate out the proper interfaces.

Another caveat with virtual interfaces is that each one needs its own Media Access Control address or MAC address. XenServer can automatically assign a randomly generated MAC address or an administrator can manually assign them as well.

The last couple of paragraphs have greatly condensed a lot of the networking concepts within XenServer. Sometimes reading isn’t nearly as easy to comprehend as seeing drawings or actually configuring.

Below is a diagram that attempts to cover the concepts introduced before the actual configuration of XenServer networking.

XenServer Network ConfigurationXenServer Networking Diagram

Figure 1 introduces the major terms involved in XenServer networking. Now that the terminology is out of the way, it is time to begin configuring the physical interfaces to allow the XenServer host and guests connectivity.

XenServer typically requires an interface for management traffic and an interface for guest traffic, however, this guide will be showing how to setup bonds for redundancy as well as link aggregation.

As a result this guide will assume the following about the physical wiring of the XenServer host:

  1. The server has four total PIFs (Physical Interfaces).
  2. The first two PIF interfaces are wired to a switch and will be aggregated via LACP (guide will cover this on the XenServer side but LACP requires the switch side be configured as well).
  3. The remaining two PIF interfaces are wired to a switch and are on the same network and will be used for management traffic as well as storage traffic.
  4. Remaining PIF interfaces will be setup in an active/failover setup.

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

How to Create and Add Citrix XenServer Storage Repositories &-8211; Part 4 &-8211; this Article or News was published on this date:2019-05-28 18:10:08 kindly share it with friends if you find it helpful

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.

Add Xenserver Storage RepositoryAdd Xenserver Storage Repository

Add Xenserver Storage Repository – Part 4

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.

Add Xenserver Storage RepositoryCitrix XenServer Storage Concepts

Citrix XenServer Storage Concepts

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.

Add Xenserver Storage RepositoryXenServer Storage Works

XenServer Storage Works

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="sfnews" device-config:chappassword="sfnews_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 “sfnews”. 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="sfnews" device-config:chappassword="sfnews_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="sfnews 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="sfnews" device-config:chappassword="sfnews_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="sfnews iSCSI Storage"
Sample Output
uuid ( RO)                 : bea6caa4-ecab-8509-33a4-2cda2599fb75
          name-label ( RW) : sfnews 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.

How to Create and Install Guest Virtual Machines in XenServer – Part 5

How to Create and Install Guest Virtual Machines in XenServer &-8211; Part 5 &-8211; this Article or News was published on this date:2019-05-28 17:58:26 kindly share it with friends if you find it helpful

Continuing to move forward with the XenServer series, this article will approach the creation of the actual guests themselves (often called virtual machines).

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

Create and Install Guest Virtual Machines in XenServerCreate and Install Guest Virtual Machines in XenServer

Create and Install Guest Virtual Machines in XenServer

This article will assume all the previous articles covering networking, patching, and storage have been completed. Thankfully, no more new terminology really needs to be discussed and the creation of the guests can begin!

System Review

At this point, a lot has been configured on this XenServer host. This will serve as a quick review about what has been configured and which article the topic was discussed.

  1. XenServer 6.5 was installed to the server
    1. https://schoolforum.me/citrix-xenserver-installation-and-network-configuration-in-linux/
  2. All XenServer 6.5 patches have been applied
    1. https://schoolforum.me/install-xenserver-patches-in-linux/
  3. Network interface teaming and VLANs were created
    1. https://schoolforum.me/xenserver-network-lacp-bond-vlan-and-bonding-configuration/
  4. iSCSI and ISO storage repositories were created to hold operating system installation files and the virtual harddisks used by the guests
    1. https://schoolforum.me/xenserver-create-and-add-storage-repository/

Creation of Virtual Guests in XenServer

This portion of the guide will be relying on ISO installers to actually boot the newly created guest machine and install an operating system. Be sure to review the fourth article for information on creating an ISO repository.

XenServer comes with a series of templates that can be used to quickly provision a virtual guest. These templates provide common options for the chosen operating system. Options include things such as hard drive space, CPU architecture, and amount of ram available among other options.

These options can be manually modified later but for now a simple template will be used to illustrate their usage. To obtain the list of available templates, the traditional 'xe' command can be passed different arguments to prompt the system to return the templates available.

- xe template-list

This command is likely to return a lot of output. To make the output easier to read, it is suggested that the output be piped into ‘less’ as follows:

- xe template-list | less

This will allow for easier parsing of the available templates to locate the necessary UUID information. This article is going to be working with Debian 8 Jessie but will require the use of the older Debian 7 Wheezy template until Citrix releases the new template.

Selecting Debian 7 won’t affect anything in the operation of the actual operating system. (The screen shot below used the UUID in the command to trim out some of the normal output).

Create and Install Guest Virtual Machines in XenServerCheck XenServer Template List

Check XenServer Template List

- xe sr-list name-label=”sfnews iSCSI Storage”
Create and Install Guest Virtual Machines in XenServerList XenServer Storage Label Name

List XenServer Storage Label Name

With this UUID, all of the initial information to setup this guest has been obtained. As with almost everything in XenServer, another ‘xe’ command will be used to provision the new guest.

- xe vm-install template=”Debian Wheezy 7.0 (64-bit)” new-name-label="sfnewsVM" sr-uuid=bea6caa4-ecab-8509-33a4-2cda2599fb75
Create and Install Guest Virtual Machines in XenServerXenServer Guest Template Creation

XenServer Guest Template Creation

The highlighted UUID is the UUID of the newly provisioned guest. There are a couple of house keeping steps that can potentially make things easier in the future. The first is to provide a name-label to the newly created VDI and the second is modifying any of the default hardware specifications provisioned by the template.

To see why it would be important to name the VDI, take a look at what the system will automatically assign to the VDI when provisioned using the following ‘xe’ commands:

- xe vbd-list vm-name-label=sfnewsVM – Used to get the VDI UUID
- xe vdi-list vbd-uuids=2eac0d98-485a-7c22-216c-caa920b10ea9    [Used to show naming issue]
Create and Install Guest Virtual Machines in XenServerCheck XenServer VDI Name and UUID

Check XenServer VDI Name and UUID

Another option available is to gather both pieces of information is the following command:

- xe vm-disk-list vm=sfnewsVM
Create and Install Guest Virtual Machines in XenServerList Virtual Machine Disk Information

List Virtual Machine Disk Information

The part in yellow is the concern. To many people this issue is minor but for house keeping purposes a more descriptive name is desired to keep track of the purpose of this particular VDI. To rename this particular VDI, the UUID in the above output is needed and another ‘xe’ command needs to be created.

- xe vdi-param-set uuid=90611915-fb7e-485b-a0a8-31c84a59b9d8 name-label="sfnewsVM Disk 0 VDI"
- xe vm-disk-list vm=sfnewsVM
Create and Install Guest Virtual Machines in XenServerRename VDI Name Label

Rename VDI Name Label

This may seem trivial to set but from experience, this has prevented a serious issue when detaching a storage repository from one XenServer and attempting to attach it to another XenServer. This particular scenario, a metadata backup of all the guest information failed to be restore-able on the new XenServer and thankfully by naming the VDI on each of the guests, proper mapping of the guest to its VDI was able to be done simply by the name-label.

The next house keeping step for this article is to provide this particular guest with more resources. As provisioned this guest will only have about 256 MiB (Mebibytes) worth of memory. Most guests this isn’t enough so it is beneficial to know how to increase a guest’s available memory. As with anything in XenServer this can be accomplished with ‘xe’ commands.

- xe vm-param-list uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e | grep -i memory
Create and Install Guest Virtual Machines in XenServerCheck XenServer Guest Memory List

Check XenServer Guest Memory List

The box in green above indicates that the most memory that this particular guest could ever have is about 256 MiB. For testing purposes this would be okay but for any sort of heavy use system, this would prove to be insufficient.

To modify this value to give the guest access to more RAM, a simple ‘xe’ command can be issued with the guest powered off. In this example, the amount of ram to be given to this machine will be represented in bytes but will equal 2 Gibibytes worth of ram.

- xe vm-memory-limits-set dynamic-max=2147483648 dynamic-min=2147483648 static-max=2147483648 static-min=2147483648 name-label=sfnewsVM

Notice that this will reserve two GiB of ram for this guest all the time.

Create and Install Guest Virtual Machines in XenServerIncrease XenServer Guest Memory Limit

Increase XenServer Guest Memory Limit

Now this particular guest is ready to have an operating system installed. From the previous article about Storage Repositories, a Samba share was added to this XenServer to store ISO installer files. This can be confirmed with the following ‘xe’ command:

- xe sr-list name-label=Remote ISO Library on: //servername>/ISO
Create and Install Guest Virtual Machines in XenServerList XenServer Samba Share Directory

List XenServer Samba Share Directory

Be sure to replace servername> with the name of the proper Samba server for the environment in which this configuration is taking place. Once the XenServer is confirmed to see the ISO storage repository, a virtual CD-ROM needs to be added to the guest in order to boot the ISO file. This guide will assume that the Debian Net Installer ISO exists on the ISO storage repository.

- xe cd-list | grep debian
Create and Install Guest Virtual Machines in XenServerCheck Guest ISO in XenServer ISO Storage

Check Guest ISO in XenServer ISO Storage

- xe vm-cd-add vm=sfnewsVM cd-name=debian-8-netinst.iso device=3
- xe vbd-list vm-name-label=sfnewsVM userdevice=3
Create and Install Guest Virtual Machines in XenServerAdd Guest ISO to XenServer

Add Guest ISO to XenServer

The above commands first list out the name for the Debian ISO. The next command will add a virtual CD-ROM device to the sfnewsVM guest and assigns it the device ID of 3.

The third command is used to determine the UUID for the newly added CD-ROM to continue setting up the device to boot the Debian ISO.

The next step is to make the CD-ROM bootable as well as instruct the guest to install an operating system from the CD-ROM.

- xe vbd-param-set uuid=3836851f-928e-599f-dc3b-3d8d8879dd18 bootable=true
- xe vm-param-set uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e other-config:install-repository=cdrom

The first command above sets the CD-ROM to be bootable by using its UUID highlighted in green in the above screen-shot. The second command instructs the guest to use the CD-ROM as the method for installing the operating system. The UUID for the sfnews guest is highlight in the above screen-shot in yellow.

Create and Install Guest Virtual Machines in XenServerInstall Guest Operating System in XenServer

Install Guest Operating System in XenServer

The last step in setting up the guest is to attach a virtual network interface (VIF). This is especially important for this install method since the Debian Network installer is being used and will need to pull packages from the Debian repositories.

Looking back at the XenServer networking article, a special VLAN was already created for this guest and it was VLAN 10. Using ‘xe’ the necessary network interface can be created and assigned to this guest.

- xe network-list name-description="sfnews test VLAN 10"
- xe vif-create vm-uuid=6eab5bdd-c277-e55d-0363-dcfd186c8e8e network-uuid=cfe987f0-b37c-dbd7-39be-36e7bfd94cef device=0

The first command is used to obtain the UUID of the network created for this guest. The next command is used to create a network adapter for the guest and attach the network adapter to the proper network.

Create and Install Guest Virtual Machines in XenServerAdd Network Adapter to XenServer Guest OS

Add Network Adapter to XenServer Guest OS

Congrats! At this point, the virtual machine is ready to boot and install! To start the guest, issue the following ‘xe’ command.

- xe vm-start name-label=sfnewsVM

If the terminal doesn’t produce any errors, then the guest started successfully. Proper starting of the guest can be confirmed with the following ‘xe’ command:

- xe vm-list name-label=sfnewsVM
Create and Install Guest Virtual Machines in XenServerCheck XenServer Guest OS Running Status

Check XenServer Guest OS Running Status

Now the big question. How to access the installer? This is a valid question. Citrix’s approved method is to use XenCenter. The issue here is that XenCenter doesn’t run on Linux! So a workaround exists so that users don’t have to create a special Windows station simply to access the console of a running guest.

This process involves creating an SSH tunnel from the Linux computer to the XenServer host and then port forwarding a VNC connection through that tunnel. It is very clever and works wonderfully but this method does assume that the user can access the XenServer over SSH.

The first step is to determine the guest’s domain number on the XenServer. This is done through the use of several different commands.

- xe vm-list params=dom-id name-label=sfnewsVM
- xenstore-read /local/domain/1/console/vnc-port

The order of these commands is important! The first command will return a number that is needed for the second command.

Create and Install Guest Virtual Machines in XenServerFind Out XenServer Domain Name Number

Find Out XenServer Domain Name Number

The output from both commands is important. The first output states the domain ID that the guest is running in; 1 in this case. The next command requires that number in order to determine the VNC port for the guest console session. The output from this command provides the VNC port that can be used to connect to the video out of this particular guest.

With the above information obtained, it is time to switch to a Linux station and connect to the XenServer to view the console session of this guest. To do this, an SSH tunnel will be created and port forwarding will be setup to direct a local VNC connection through the SSH tunnel. This connection will be done from a Linux Mint 17.2 workstation but should be similar for other distributions.

The first step is to ensure that OpenSSH client and xtightnvcviewer are installed on the Linux host. In Linux Mint this can be accomplished with the following command:

$ sudo apt-get install openssh-client xtightvncviewer

This command will install the necessary utilities. The next step is to create an SSH tunnel to the XenServer host and setup port forwarding to the VNC port determine earlier on the XenServer host (5902).

- ssh -L any_port>:localhost:VM_Port_Above> [email protected]server> -N
- ssh -L 5902:localhost:5902 [email protected]servername> -N

The ‘-L’ option tells ssh to port forward. The first port can be any port above 1024 that isn’t in use on the Linux Mint machine. The ‘localhost:5902’ indicates that the traffic should be forwarded to the remote localhost port 5902 in this case that is the XenServer VNC port of the sfnewsVM.

The [email protected]server>’ is the login credentials to SSH into the XenServer host. Finally the ‘-N’ tells SSH to simply open a port forwarding connection. Using ‘lsof’ command the tunnel can be viewed in the output.

$ sudo lsof -i | grep 5902
Create and Install Guest Virtual Machines in XenServerCheck Port Number Listening

Check Port Number Listening

Here the tunnel is setup and listening for connections. Now it is time to open a VNC connection to the guest on the XenServer. The utility installed is ‘xvncviewer’ and the ssh connection to forward traffic to the XenServer is listening on ‘localhost:5902’ so the appropriate command can be built.

$ xvncviewer localhost:5902
Create and Install Guest Virtual Machines in XenServerConnect XenServer Over VNC Connection

Connect XenServer Over VNC Connection

Voila! There is the sfnewsVM console session running the Debian Network Installer waiting for the installation process to begin. At this point, the installation proceeds just like any other Debian installation.

Up to this point, everything with XenServer has been done via command line interface (CLI). While many Linux users enjoy the CLI, there are utilities that exist to simplify the process of managing XenServer hosts and pools. The next article in this series will cover the installation of those tools for users who wish to use graphical systems rather than CLI.