When I first started looking at using Tintri for my VDI environment, all I could find were white papers and webinars that said “best of the best of the best SIR!”.
I did not know how this mystical unicorn “Tintri Clones” could help me. What is the mechanism that will help get VDI off the ground? How is this so different from what I use today?
In my particular situation, I am using Xendesktop 7.5 MCS with PvD on top of vSphere. I originally used personal vDisks as a way to save disk space. I would redirect the user data to a NAS and use the PvD as user application install space. I found this to be a great provisioning method on a traditional SAN. I would have a central image to maintain and push out the updates to a catalog. But, storage migration is a nightmare when using PvD because it is not supported by Citrix. The way to get around this is to do a backup and restore on to a new pool of desktops. You can continue to use PvD with Tintri, but it really becomes unnecessary. I will show you why.
The plan: build a new pool of desktops on Tintri storage to take advantage of its features. How do I take advantage of the array features and space savings? It was really quite simple. I was expecting to find some complicated configuration setup between Citrix, Tintri and VMware to get things working. It all really boils down to the Tintri host plugin and cloning your master image on the Tintri array. The host plugin activates the Tintri VAAI for reduced host IO, space savings and fast deployments of VMs by offloading the process to the array. Offloading processes to the array is not something new, a lot of vendors do this today. Tintri offers a few whitepapers on how to use Citrix with Tintri: http://www.tintri.com/blog/2014/05/tintri-citrix-xendesktop-citrix-ready . There are some important Pros, CONs and gottachas to go over. The most important gottacha that I think should be noted is that a catalog should not be updated or created from a VM that has snapshots. Doing so negates the space savings and creates full clones of the desktops. It is important to remember that the base image for the catalog should be created from a Tintri clone. This involves logging on to the array and cloning your master image. Simply cloning from the vSphere web client or C# client will not do it. This clone will be used to spawn all of your virtual machines. You would then re-clone this master image with no VM snapshots to push out any updates to your catalog from Citrix with MCS if you are using PvD.
From the diagram below, you can see how personal vDisks work. The user / application data is saved out to a seperate drive. Each vSphere datastore gets a copy of the base disk for each VM to link back to. Each VM with MCS (machine creation services) also gets a small 16MB identity disk. I can say that I’ve had Citrix issues with every other release using personal vDisks. Adding on this piece to your deployment adds a layer of complexity. I find it much easier to just use clones of the master image as regular desktops. You already get space saving from the Tintri array vs PvD. The only advantage would be the ability to push out updates to a catalog from a master image when using a PvD catalog.
The only negative with using a machine catalog that saves data to the local disk instead of a PvD is that you cannot grow the drive on individual VM from the vSphere console. Each VM is tied to a Citrix created snapshot in vSphere with the base disk. A virtual machine with a snapshot cannot change the drive size even if it is powered off. This is not a negative aspect of Tintri, it is a function with Citrix. How do you grow the drives? You would need to create dedicated machines from Tintri clones or clone the VM to a individual VM that is not tied to a master (this would involve creating a new pool).
Citrix creates disk layouts in different ways when it comes to dedicated machines and PvD machines in MCS. PvD machines link each VM’s C drive back to a base master disk in each datastore, but each dedicated machine links back to an individual snapshot of the master disk, so you are dealing with many more C drives that could grow vs having a PvD on each machine that would grow. To review this process, visit the Citrix documentation.
I am not going to cover PVS provisioning, that will be for another post.
So why is it the “best of the best of the best, Sir!”? There are auto tier systems and then there is Tintri AWS. This is the Active Working Set which runs 99% of IOPS in flash. My users get data in flash when they need it.
Overall, I found the process of creating my VDI environment from Tintri quite easy. It is so easy to investigate who is doing what in the Tintri console! No complicated java setups or fat clients that require days of training. It is important to review all of the Tintri best practices before you go about re-platforming your environment. You don’t want to go spawning desktops in a catalog from a VM you built that has snapshots!