Citrix XenDesktop 7.15 installations – Part 2.
Welcome to part 2 in the series of Citrix XenDesktop 7.15 installations. If you have missed it you can find part 1 here where we run Citrix XenDesktop 7.15 on Nutanix NX.
Why run XenDesktop on ESXi 6.5 and vSan 6.6?
The customer requirements were to replace a XenDesktop 7.1 deployment, using traditional 3 tier storage systems. The customer was attracted to HCI for the scalability and performance it provides.
Compatibility.
Citrix currently publish a nice matrix, below is a screenshot of vSphere compatibility, but a full list of hypervisors are available here.
Features not supported.
In the previous article we mentioned several of the Citrix features that are not supported with AHV, but this is not an issue with vSphere which is what you would expect with a much more mature hypervisor.
Setting up your hosting connection.
Getting started you will need to setup a hosting connection, you don’t need to install any plugins as with AHV, as this is supported out of the box.
This connection works over HTTPS so to get this to work it is always recommended you don’t use a self-signed certificate in a production environment. However, if you need to trust your certificate for setting up a hosting connection, this is now a very simple process.
Deploying and updating machines.
The MCS deployment process is much the same however we find one huge issue when trying to update a machine catalogue. Creating the catalogue completes without issues and adding additional machines from the current snapshot also completes. However, when updating the machine, the VM loses its OS disk, and then won’t boot.
Disk structure pre-MCS update.
As you can see here we are using MCS with Cache to RAM, the 3 disks are:
- 1OS Disk
- 2Identity Disk
- 3MCS Cache Disk
However, after running and MCS update, the disk structure is as below.
As you can see there are now only 2 disks:
- 1Identity Disk
- 2MCS Cache Disk
As part of the MCS process the OS disk is removed from the VM so if a VM is started it won’t have an OS to boot into so will try and PXE Boot.
There is apparently a private fix for this, and with the release of 7.16 very recently this might have been resolved (we have not had chance to test this). It is also reported that this error goes back several versions to 7.13 (again we have not had the opportunity to test this).
With the help of several users on the Citrix forums there is a power CLI script that convert the disks to VSAN objects.
$VMs = Get-VM -Name “PREFIX*”
foreach ($VM in $VMs) {
$Datastore = Get-Datastore -VM $vm
$Datacenter = Get-Datacenter -VM $vm
$diskpath = “[” + $Datastore.Name + “] ” + $vm.Name + “/”
$vmidpath = $diskpath + $vm.Name + “_IdentityDisk.vmdk”
$vmtemppath = $diskpath + $vm.Name + “_TemporaryStorage.vmdk”
$renameidSource = “vmstore:\” + $Datacenter +”\vsanDatastore\” + $vm.Name + “\” + $vm.Name + “_IdentityDiskOld.vmdk”
$renameidDestination = $vm.Name + “_IdentityDisk.vmdk”
$converthdd = $diskpath + $vm.Name + “_IdentityDiskOld”
#Convert Disk
Get-HardDisk -VM $vm | Where-Object {$_.Filename -like “*_IdentityDisk*”} | Copy-HardDisk -DestinationPath $converthdd -Confirm:$false
#Remove Disk
Get-HardDisk -VM $vm | Where-Object {$_.Filename -like “*_IdentityDisk*”} | Remove-HardDisk -DeletePermanently:$true -Confirm:$false
Get-HardDisk -VM $vm | Where-Object {$_.Filename -like “*_TemporaryStorage*”} | Remove-HardDisk -Confirm: $false
#Rename Identity Disk
rename-item $renameidSource $renameidDestination
#Add Disk
New-HardDisk -VM $vm -DiskPath $vmidpath
New-HardDisk -VM $vm -DiskPath $vmtemppath
}
Once this has been run we were successfully able to update machines but we found the following issue when running this script.
If a catalogue was deleted then recreated and the machine names were reused VSAN did not clean up existing VM folders causing the new machines to be created in folders with the a suffix _1 etc.
If the script is run where these duplicate folders exist it then errors.
With this failure, the VM loses its cache disk, only the OS disk and Identity disk are present.
If the Cache Disk is removed the machines will BSOD, when the IO is greater than the RAM.
This was resolved by confirming the removal of the machines and associated objects before deploying the catalogue.
Overall impression.
The overall impression is good, and when comparing this to a more immature hypervisor it works well. VSAN performs extremely well, with a very good user experience. However, how something as fundamental as the MCS update failure we experienced on VSAN has slipped through the net is hugely disappointing!
If you found this article useful please give it a share and leave a comment below. Alternatively, if there are some topics you would like us to cover, suggestions are welcome.
