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:
- vSphere 6.0U2 (vCenter and ESXi)
- VSAN 6.2
- Horizon View 7
- App Volumes 2.10
- Golden image VM and App template VM were both Windows 7
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.
7 Replies to “A primer on App Volumes and AppStacks on VSAN”
Nice post, just what I was looking for clarification on!
So we are saying that it is supported to have the AV Manager in the Management Cluster residing on it’s VSAN Datastore and then provision AV AppStacks to the Production Clusters VSAN Datastore for the desktop pools within that cluster to mount/consume?
I was aware that VMs cannot consume AppStacks hosted on VSAN outside of the VMs own VSAN Datastore but wanted to confirm that the setup you have described, and my take upon on it, is supported and correct!
My understanding is that this is the preferred way to deploy such a setup. Let me get one of the EUC guys to bless it though.
I spoke to one of the EUC guys. One recommendation is that both VCs are on the management site. Don’t have any VC on the production site. This keeps the servers/workloads separated. If you want to scale out and add in more desktop clusters, you just add in another vCenter into Management Cluster.
There are other things you can do with App volume Managers – you could have a pair of App Volumes Managers (sitting behind a load balancer or round robin DNS, etc) for performance reasons.
Other than that, I don’t think there is much difference to the way I drew it out in the post.
Thanks for clarifying Cormac!
Question from Stephen Massman on slack:
Can anyone expand on why not to run app volumes 3.0 in production.
“Important note on VMware App Volumes: We were excited to announce a new App Volumes platform in 2016. If you are a Horizon Enterprise customer, you can continue to leverage existing versions of App Volumes, User Environment Manager and vRealize Operations for Horizon with Horizon 7. For all Horizon customers with App Volumes in production, we recommend that you continue to leverage the existing App Volumes 2.10. VMware delivered a new extensible platform that tightly integrates these technologies and delivers some new capabilities. If you are interested in testing out this new platform be sure to consider App Volumes 3. We are committed to developing and building out this platform as we move forward and welcome your feedback.”
No idea about this Manish – where did the original statement originate? Is it in an official doc, or was it posted somewhere?
Also, if I check the product interop matrix, it shows that VSAN 6.2 is supported with App Volumes 3.0 – http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php#interop&100=1010&131=
I’ve noticed that when an AppStack is connected to a VM the policy compliance is always “outOfDate” even if you check the compliance again. Plus, if you try re-apply the policy I get an error message stating that “it’s not possible to apply a policy to a non-persistent disk while the VM is on”.
Basically, all the VMs with AppStacks connected have a compliance error but I understand this could be cosmetic since they are all connected to the same VMDK.
So the question is:
– is this normal behavior?
– how do I check the compliance of the App Stack VMDK since this is not a VMDK connected to a VM and thus the vCenter doesn’t display this object?
Comments are closed.