XenDesktop Image Management
Citix have released this cool script that handles an automated deployment of images in a multi-site environment.
Download XenDesktop Image Management script here
Summary
Currently XenDesktop does not support multi-site deployment. If the administrator has same images, they have to manually keep all the images in sync. We have come up with a way to automate this process.
Components
Beside the general XenDesktop components, there are the following few additional components required to perform Image Management.
Note: These additional components are not part of either XenDesktop or XenServer.
Control Machine is Windows OS which has Desktop Studio (for XenDeskop SDK) and XenServer PowerShell SDK installed. This machine hosts the PowerShell script (Control Script) which manages the image synchronization and updating of slave Catalogs.
The Control Script is a PowerShell script which runs on the Control Machine. It interacts with the user by getting the Master Site and Slave Sites details and keep them updated with the progress and result of the sync process.
The Sync Script is a bash script started by the control script and is run in Dom0 on the master site’s XenServer Pool-Master to copy the consolidated image’s VHD file across to a XenServer residing on the slave site. rsync-over-SSH is used to complete this task.
The rationale for placing the sync script on the hypervisor itself rather than on the control machine is that neither of the XenDesktop or XenServer APIs currently provides a mechanism for copying files across hosting units located in different pools or sites.
The sync script is started by the control script on the control machine and takes the following parameters.
- VDI Name
- Arbitrary number of Host/SR pairs as targets for the synchronization.
The following is an overview of the sync script’s operations:
- Resolve the VDI to all possible candidate VHD files on the host’s SRs.
- Locate the youngest candidate VHD for the given VDI. The assumption being that the youngest file is the product of the most recent consolidation.
- Determine the mount point of the target host’s SR to copy the VHD file to.
- Use rsync to initiate the synchronization process.
- Attempt to verify that the VHD file has indeed been copied to the target.
- Change the following flags on the VHD file for use in reconsolidation on the slave site:
- Managed: True
- Read-Only: False
- The sync script requires interaction with hosts that have visibility of the file-systems associated with the SRs involved in this process.
- The remote target must be visible over ssh from the host pushing the VHD out.
- The host initiating the transfer must have been setup for SSH Public Key Authentication for a fully automatic schedulable synchronization.
- The mount-point for the remote SR must have necessary space and permissions to allow the VHD copy.
Process
On the Master XenDesktop Site an administrator updates the image and within XenDesktop updates the Catalog. This results in the creation of Consolidation disk in a VHD format.
Storage and Host Identification
User provides the address of the Desktop Delivery Controller (DDC) and the Catalog which the user has updated. This is regarded as the Master site details. User also provides the same information for all the salve sites the image needs to be synced to. Control Script determines the VHD name of the base image that is being used for the Master Site Catalog and host addresses and the storage names where the VHD needs copying and calls sync script with this information.
When XenDesktop creates a consolidation disk for a Provisioning Scheme it gives it the VDI name as <Provisioning Scheme Name>-baseDisk. There can be many updates to that Provisioning Scheme so can have many VDI’s with the same name. So the script checks for the latest disk looking into the Linux file system and copies it across the Slave Sites. Once the VHD is copied across it uses VHD-util utility and ensures that the read-only flag is set to false and managed flag is set to true
Once the copy is successfully completed, the Control Script plugs the copied VDI to a wrapper Virtual Machine and updates the Provisioning Scheme using that Virtual Machine.
Assumptions and Limitations
- The solution is only implemented on XenServer as Hypervisor platform using NFS Storage.
- The solution assumes that there is only one XenServer Pool per Hypervisor Connection.
- There is one Provisioning Scheme per Catalog.
- SSH is setup to use RSA on Master Site’s XenServer Pool Master and all Slave Sites’ XenServer Pool Master.
- All the sites VDAs are in the same domain.
- The user who is running the Control Script has access to all sites.
- Slave and Master Catalogs are in the same site or DDC is address is configured through GPO.
- Control Script is run in Powershell x86.
Source
