Lessons Learned: Deploying App Volumes
By Kyle Susoev, Solutions Consultant, Kovarus
Anyone who has dealt with delivering and managing applications at an enterprise level can attest that it can be a huge undertaking. In the past, there have been a myriad of options to perform workspace service delivery; though the delivery method almost always required pushing the package to the endpoints and installing the application (not to mention the additional hassle if the application then required a system reboot). Once we moved into the virtual space, application virtualization solutions such as VMware ThinApp allowed for these actions to take place without these disruptions by leveraging sandboxing and network streaming. There were still some applications that could not be ThinApp’d due to size constraints, drivers, Windows components, etc.; that’s where VMware App Volumes come into play.
According to VMware, deploying App Volumes (formerly Cloud Volumes) will reduce storage and operational costs, reduce time spent managing images, and deliver personalized applications at a fraction of the time required by alternative methods.
App Volumes will allow for non-persistent architecture with a persistent feel, which is accomplished by leveraging writable volumes. Within App Volumes, an application or group of applications is containerized in a virtual disk and re-anointed as an AppStack. This allows the administrator to quickly deploy a collection of applications to an entire group of users. One small caveat is that these AppStack disks are read-only. Therefore, if the application requires Read/Write capability, such as for application settings changes or to capture a change to the user profile, AppStacks alone will not accomplish this. While a user is in their non-persistent session, that data would remain, but would subsequently be deleted when that VM reboots or resets as one would expect. However, with writable volumes, that data is captured and preserved.
While both AppStacks and Writable Volumes are virtual disks, all users share AppStack VMDKs while Writable Volumes are dedicated to a single user. User changes are captured in the writable volume and applied to the associated VM on top of the non-persistent architecture (see Just-in-Time model).
There are three types of profiles that can be assigned to the user based on their needs:
- User Profile only
- User Installed Applications only
- Profile and User Installed Applications
It is important to note that App Volumes is not necessarily a replacement for ThinApp, but rather a complementary application delivery tool with its own application packaging capabilities. App Volumes and ThinApp can work together happily, and App Volumes is a great tool for quickly delivering ThinApped applications to the end user.
This all sounds great, but just like anything else there are limitations and lessons learned. I was recently involved in implementing App Volumes to replace an existing Unidesk solution. This particular client’s environment at any given time contains roughly 5000 users, 1500–2000 concurrent sessions, and some 400 applications. I remember looking at this project at the beginning and thinking, “We’re going from persistent to non-persistent virtual machines, but App Volumes will take care of that with writable volumes. The groups of users and associated applications are already defined in the Unidesk environment. So, all I need to do is rebuild the existing system with App Volumes.” That was not the case.
The portion of the implementation that required the most reengineering was how these applications work in a non-persistent setting.
Some applications required specific hostnames or IPs for authentication. Since these virtual machines were scheduled to refresh, we had to register each hostname and IP in range to avoid the end user having to authenticate after each refresh. Another issue we came across was when an end user needed access to multiple virtual machines with different AppStacks associated to those systems. For instance, if an end user opens a 32-bit Office Suite application on their test virtual machine, then launches a 64-bit version on their production virtual machine, Office will try to reconfigure the application and ultimately require a reboot. We were able to work around this issue by standardizing on Office 32-bit, but you can see how this type of integration issue could cause issues if proper testing was not conducted. The remaining AppStack conflicts we encountered were resolved by deploying a ThinApp package as an Appstack.
In closing, application delivery in a VDI environment can be a complex undertaking, but deploying App Volumes is a more than capable solution.
Rapid deployment, custom application stacks, and writable disks, allow for a highly agile and low impact solution to current application delivery methods. Coupling AppVolumes with ThinApp provides an easily managed solution that can streamline base images and makes a persuasive argument for moving away from those storage heavy persistent desktops.