Automatically start a vApp on XenServer boot

This article has been super seeded by a new Step-by-step guide to automatically start a vApp on XenServer. Please follow the steps in this new blog-post as they have been successfully tested on XenServer 6.2.
 

Yesterday I was made aware of a new blogpost by @MichelHelderman on Twitter by my colleague @KBaggerman who refered Michel to a blogpost I wrote on enabling the VM autostart through the CLI for XenServer 6.0.
This feature is no longer available through the XenCenter GUI in XenSeerver 6.0 as it was interfering with the HA features on XenServer.

Michel provides you with a great alternative, namely the introduction of the new vApp feature for XenServer 6.0, which allows you to group VMs on a XenServer and control the automatic startup of the entire VM group. Even allowing you to set the boot order and wait time between boots.

The only setback with using the new vApp feature to group you VMs is that the vApp itself cannot be configured to automatically start when a physical XenServer Host is booted. It still requires a manual action through the GUI or CLI to start the vApp and have all VMs booted in their set order. Something we most definately want to be automated.
As there is no attribute for the vApp to configure it to auto-start, like my previous post explains for individual VMs, there are alternative ways to have a vApp be automatically started when a XenServer Host boots.

In this blogpost I have gathered some of the alternative methods to implement the auto-start feature for your VMs as I have found them on the internet.

Use rc.local for startup commands

With the linux distro’s based upon CentOS, like XenServer, you can use the /etc/rc.local file to define commands that need to be run once when the system is booted. @MichelHelderman offers this option as well to automatically start the vApp when a XenServer is booted.
The following command can be added to the rc.local file:

[root@<name-xs> ~]# xe appliance-start uuid=[uuid-vapp]

 
Which uses the following variables:

• uuid-vapp: A unique identifier for the vApp.

Keep in mind that this solution does require you to know the uuid of the vApp to be started.
To ensure the command is started, you might want to add an additional timer (sleep 40) above the line in the rc.local file.
Errors can occur if the used vApp is (for some reason) deleted or recreated as the above command keep refering to the original uuid.
You have to keep track of the uuid at multiple places (and maybe even multiple XenServer hosts).

Use a script and custom tag

Another way to implement the auto start functionality for vApps, is by using a complete script that checks the vApps to start, based upon a custom tag (or description for a vApp) that can be set for each vApp. A great script for doing this is created by Raido Consultants who have shared their script through their blogpost XenServer 6 Auto-Start VMs. In case you do not want to add the entire script to the rc.local file, you can always choose to create a seperate script file and call the script from the rc.local file. The following script can be used to automatically start each vApp that has the custom tag ‘autostart’ assigned.

# AutoStart Vapp's that have autostart in description
# Script created by Raido Consultants - http://www.raido.be 
TAG="autostart"
# helper function
function xe_param()
{
PARAM=$1
while read DATA; do
LINE=$(echo $DATA | egrep "$PARAM")
if [ $? -eq 0 ]; then
echo "$LINE" | awk 'BEGIN{FS=": "}{print $2}'
fi
done
} # Get all Applicances
sleep 20
VAPPS=$(xe appliance-list | xe_param uuid) for VAPP in $VAPPS; do
echo "Raido AutoStart : Checking vApp $VAPP"
VAPP_TAGS="$(xe appliance-param-get uuid=$VAPP param-name=name-description)" if [[ $VAPP_TAGS == *$TAG* ]]
then
echo "starting vApp $VAPP"
xe appliance-start uuid=$VAPP
sleep 20
fi
done

By using this script, you are more flexible in configuring the auto-start option for you vApp.
You no longer need to keep track of the uuid for you vApp, but can easily turn the auto-start option on or off by adding or removing the custom ‘autostart’ description to you vApp (or whatever description you want to set for the TAG variable.

Unfortunately a vApp does not have the same attributes assigned to it as a VM does, so tags cannot be set and the only custom variable you can use, is the description you can set for your vApp. In case of the script sample, the value ‘autostart’ will trigger the script to automatically start the vApp (and therefore all VMs defined within the vApp).

You can use a tool like WinSCP to edit the rc.local file or add a seperate script file that is called from the rc.local file.

 

* Setting the vApp description with the CLI:

[root@ ~]# xe appliance-param-set uuid=[uuid-vapp] name-description="autostart"

 
Which uses the following syntax:

• uuid-vapp: unique identifier for the specified vApp.

 
The uuid for the vApp can be retrieved with the xe appliance-list command.

* Retrieving the vApp uuid with the CLI:

[root@ ~]# xe appliance-list name-label=[name-vapp]

 
Which uses the following syntax:

• name-vapp: Name given to the vApp (tab can auto complete the name-label).

Esther Barthel

Solutions Architect at cognition IT

Esther has been working in different roles and functions as an IT consultant ever since she finished her Masters degree in Computer Science in 1997. She has worked as a web developer, database administrator, and server administrator until she discovered how Server-Based Computing ( SBC ) combined servers, desktops, and user experience in one solution. Esther has been specializing in virtualization solutions such as SBC, VDI, application, and server virtualization for over eight years now and is currently working as a Senior Consultant at PepperByte, where she designs and implements Citrix® solutions for both small-business and large-enterprise infrastructures scaling from 100 to 15,000 users.
In january 2014 her first book Citrix XenApp 6.5 Expert Cookbook was published by Packt Publishing.

Esther is awarded as a Citrix Technology Professional (CTP) from 2015 - 2017.
Esther is awarded as a Microsoft Most Valuable Professional (MVP) in 2017.

Esther is a Citrix Certified Expert – Virtualization (CCE-V), Citrix Certified Professional – Mobility (CCP-M), Citrix Certified Professional – Networking (CCP-N) and RES Software Certified Professional (RCP).