Spinning up your Provisioning Services Environment
Just a quick blog before Christmas about options to spin up your Citrix Provisioning environment. As you might know you have different options when it comes to spinning up your Provisioning target devices. Which one to choose depends on your (network) setup and how much control you as a Citrix consultant\engineer\architect have in the customers environment. One of the most common boot scenario is using A: PXE or B: DHCP both in combination with TFTP.
With PXE you don’t have to configure the DHCP options to provide the TFTP server to the targets, you can create a kind of redundant configuration by setting up multiple PXE and TFTP servers, but please note that this is not a real HA configuration because there is no logic involved which controls the way a TFTP server is provided to the targets. For example a broken or unavailable TFTP server can be provided to your targets, you can compare this a little with the way how DNS round robin works.
With the DHCP options you can only provide one TFTP server to your targets, to enable HA here you can configure a load balancer (NetScaler for example) in front of the TFTP servers, this is more HA then option A because you can configure the load balancer to check the health of the TFTP servers and bypass TFTP servers that are currently in down state. But you will need to add multiple nodes in your load balancing configuration so you don’t have a single point of failure.
With both option A and B TFTP is used to deliver the bootstrap to your targets, but what if we can’t use PXE or TFTP because of network restrains or just because we want to eliminate the whole PXE and TFTP dependency… Yes we also have the option to create a bootable disk or ISO with the bootstrap embedded, it contains a list of the Provisioning Servers to provide HA for your VDISK.
To create the ISO we use the Provisioning Services Boot Device Manager which is part of the Provisioning Server installation.
After configuring the Provisioning Servers, burn the ISO using the Citrix ISO Image Recorder :
Ok now we have the ISO what should we do with it?
We need to keep in mind that this ISO is now the crucial part for spinning up the targets, without it they simple won’t boot.
The following scenarios are possible to provide the ISO to your targets :
1: When using physical targets
You can burn the ISO to CD\DVD and put it permanently in the drive and boot from there, another alternative is to create a bootable USB drive and put it in the back of the server.
2: When using virtual targets
Here we can leverage the Hypervisor to provide the ISO, because we need to ensure the availability of the ISO we don’t want to put it on a remote ISO (CIFS\NFS) share, because this would be a single point of failure again. If possible you can use the local storage of the Hypervisor to store the ISO.
With VMware ESX and Hyper-V it’s easy just put the ISO on the local disk or Data Store and attach the ISO to the VM, you can also create a template after this so if you use XenDesktop\PVS to automatically create VM’s for you the ISO is already connected when the VM is turned on.
But what about XenServer? We only have the option to create a CIFS or NFS based ISO repository from XenCenter and that’s something we don’t want in this case. Beneath is a procedure which you can use to create a local ISO repository in XenServer, so you can attach the ISO from there :
– Connect with WinSCP to the XenServer host
– Create the following folder : /var/opt/xen/local_iso
– Connect to the XenServer console to access the command line interface
– Create the Local ISO Repository with the following command :
“xe sr-create name-label=”Local ISO” type=iso \device-config:location=/var/opt/xen/local_iso/ \device-config:legacy_mode=true content-type=iso”
– Copy the PVS boot ISO to the /var/opt/xen/local_iso folder
– Check the SR in XenCenter :
And the content of the SR :
* Please note : Do not use the Local ISO repository to store other big ISO’s because it has limited space available.
– Finally attach the ISO to your VM’s and\or templates and check the result :
Using a bootable ISO is a great way to overcome network related issues that can be the case when using TFTP and\or PXE. DHCP will always play an important role in your Provisioning Services environment, use split scopes or clustering there to guaranty the uptime of your Provisioning environment. Provisioning Services comes with a lot of “moving parts” compared to MCS, but with this boot option you can at least eliminate a few of them. It’s nice to see PVS is still alive in Excalibur so there is room for MCS to grow, the power is choice!
From here I wish everybody a merry Christmas and a happy new year!
Please note that the information in this blog is provided as is without warranty of any kind.
4 thoughts on “Spinning up your Provisioning Services Environment”
I am just curious. Do you see any boot problems in XenServer 6.0.2 environments using this method. What we see in all our deployments is that the target needs 2 or 3 reboots. If we look at the console, mots of the time the first boot fails during second stage boot loader on the first PVS server, the second boot fails agin and the third boot is succesfull.
No I didn’t noticed this behaviour, currently using this method in a project with XenServer 6.0.2 (fully patched) and PVS 6.1 (HF001 + HF003).
XenDesktop VM’s starting directly without reboots, what is the message when it hangs? I will watch it more closely, thanks for the info.
To come back to your issue : I cannot reproduce the issue you are seeing, just rebooted a couple of VMs time after time and it boots successful directly the first time.
Nice work mate! I knew it was possible but simply to lazy to find how!