Site icon CormacHogan.com

A primer on App Volumes and AppStacks on VSAN

Last week I wrote a post on Horizon View 7 on VSAN. That was all about showing the policies that were associated with the different desktops that can be deployed. I did mention that while one could use vmFork/Instant Clones for desktops, they did not include any sort of persistence. I did add a caveat to say that you could provide persistent storage to these desktops using App Volumes. In this post, I wanted to give some details on App Volumes, and the different moving components one will need if they want to deploy View desktops with App Volumes. However, I am only going to show the considerations around deploying AppStacks which is an application that is presented to the desktop via a read-only VMDK. I do not get into the specifics around writable volumes in this post, but this is also available via AppStacks. Hopefully this will be a good enough primer to get you started with App Volumes. I will say at the beginning that there is nothing unique about using VSAN in this case, other than the fact that policies can be used for the VMDKs. As you will see shortly, both the management cluster and production cluster both run VSAN, and I could use App Volumes and AppStacks with no issues.

First, lets being by a look at all of the moving parts required if you are going to provision a View desktop with AppStacks. I put this together quickly to explain it. I have two clusters; the management cluster and the production cluster. The blue components are typically those you would have in a typical View desktop deployment. I have View Connection Server, View Composer, and vCenter server all running on the management site. On the production site, I have another vCenter Server and the golden image VM (and snapshot) for deploying desktops. This is cloned to a replica when we begin to create desktop pools (there is an old article on this process here if you want to read up on it).

OK – so what about the other bits. On the management cluster, marked in grey, is the App Volumes Manager. This is where administrators select a vSphere environment for App Volumes, and then create and manage the read-only AppStacks or “writable” volumes.

On the production site, I needed to ensure that the VM that I was going to use for applications had the App Volumes Agent installed (note that this is referred to as a template above, but it is not a template. It is a running VM). This agents enables communication between it and the App Volumes Manager. Similarly the golden image VM that is to be used for the desktops also has the App Volumes Agent installed. Since I plan on deploying desktops based on linked clones. I also have the View Composer Agent installed on this golden image VM. The versions I deployed are as follows:

For AppStacks, if I can simplify the process somewhat, the administrator selects the template VM, marks it for “provisioning”, captures the applications that are installed in that VM, and then saves them in a VMDK on a datastore such as VSAN along with the appropriate metadata. Next, the administrator decides who is going to consume these applications. Here is an App Volumes Manager view showing the fact that I have captured one application, and that this AppStack has been assigned to Domain Admins (there are lots of ways to assign AppStack – this is only one way). Then when chogan , who is a Domain Admin in this environment, logged into a desktop, this AppStack was attached to that desktop (in the form of a VMDK).

In this example, the AppStack was called c0, and this is how it appeared on the VSAN datastore:

App Volumes provides a bunch of sample VMDKs, and it is a copy of one of these that is used for the AppStacks. As this was a linked clone desktop deployed on VSAN, there were four disks in total, without the AppStacks. You can read about these different disks in this earlier post. However, once I logged in as a domain admin, another disk was added to the desktop – the AppStack VMDK:

It all sounds really simple, doesn’t it? Well, not quite. It took me quite a while as I kept missing one or more bits, either an agent not installed where it should have been, or not in the correct place, etc. That’s more or less why I put together the layout of components above.

If you are considering deploying App Volumes and AppStacks in your own environment, I found these guides from Jason Langer extremely useful.

My next step is to get hold of the App Volumes backup utility fling, and try to back up some of these App Stacks that are sitting on my VSAN datastore. I’ll follow up with a post on that once it is complete. [Update] It looks like there is already a good article on how to use the fling to back up AppStacks and writable volumes here.

Exit mobile version