App Volumes – Apps in a snap!
VMware have long been a presence in the virtual desktop market – even ignoring their own VMware View® product, vSphere® is used to support other brokers, such as Citrix® XenDesktop. Regardless of product set, a common problem is how to deliver applications to the desktop.
Let’s have a bit of background. Most applications are provided as either a batch of files dropped in place on an end point, while others are provided using an installer application of some sort. This is generally the case regardless of operating system, but let’s focus on Microsoft Windows® as this is most prevalent.
Historically, most application delivery systems have been focussed on pushing down the binaries to a system and installing as required. This approach has a number of limiting factors – it takes time to download the package to the machine and install the application, not to mention in many cases, the application would need a reboot, causing further disruption. This was acceptable for physical PCs and Laptops as these are persistent devices on the whole so a little disruption is manageable.
Of course, one of the key benefits of virtual desktops is supposed to be flexibility and rapid delivery – so spinning up non-persistent desktops, only to have them scuppered by long application delivery times meant other measures were necessary.
Building applications in the base build is very common, but far from efficient, particularly if the application is only used by a user subset.
Application Virtualisation solutions such as VMware® ThinApp answer a number of issues, notably the sandboxing of applications which prevents the need to reboot, and streaming over the network improves delivery times. However, there is still the time-to-deliver over the wire (especially with large applications), plus Application Virtualisation will not work with all applications (such as those with device drivers or Windows Services).
Most organisations would fall back to persistent desktops or Remote Desktop application delivery solutions such as Citrix XenApp to make up the short fall, but there is another way.
CloudVolumes to VMware App Volumes™
CloudVolumes was founded back in 2011 with a simple premise – publish applications using a virtual disk container as a delivery mechanism to a hosting operating system using an agent that merges the virtual disk contents with the operating system partition. VMware scooped them up in 2014 and re-branded the technology as App Volumes.
By using a Virtual Disk as a container, you can collect multiple applications in a single virtual disk (an AppStack) and push them out together. Of course, in a virtual infrastructure, this disk sits on shared storage, alongside the virtual desktop, so delivery time is reduced to how fast the solution can mount the virtual disk.
The other clever feature of this ‘agent plus disk’ affair is that the AppStack disk is read-only (I’ll discuss where changes go later). Being read-only means that the single disk can be shared by many desktops (on SSD, potentially 1,000-2,000 per disk) – doing wonders for scaling and storage efficiency.
So, consider our non-persistent VDI example. Both VMware and Citrix can spin up a non-persistent desktop based upon a template Windows operating system installation in next to no time. The user logs on to the client, the agent takes the identity of the user and pushes it to the App Volumes management server which, in turn, subject to entitlements, attaches the relevant AppStacks to the user’s desktop. All this happens as the user logs on. No mess, no delay – and consistent too.
Creating an AppStack requires only a basic Virtual Machine to serve as a provisioning desktop. A blank AppStack is assigned to this VM in a provisioning mode (read-write) – applications are installed as required. Once it’s ready, it can be entitled to Active Directory users, groups or even computer objects. AppStacks can be assigned to a VM at either boot up, log on (or immediately – though this is not recommended).
App Volumes and Terminal Servers
A clever use case for App Volumes is in conjunction with Terminal Servers. By assigning a common AppStack to a farm of Windows 2008R2/2012 VMs running as a Terminal Server (for example Citrix XenApp, VMware View RDSH), it’s possible to rapidly deploy a consistent farm. A really nice side-benefit is that if you want to re-allocate hosts between multiple farms with different applications, this is possible simply by changing AppStack and re-assigning the host – it’s no longer a rip-down and rebuild affair.
So AppStacks are read-only – what about writing back?
A mighty fine question. If you need to make writes back to an application installation, they are written to the C: drive of the VM (as you’d expect) – don’t forget, our AppStack is invisible – the C: drive is merged.
While many applications drop configuration changes etc. in the user profile, some less than well written ones do tweak content in the installation path. This isn’t too useful for non-persistent applications – such setting changes would be lost as soon as the non-persistent desktop is destroyed. However, another App Volumes feature comes into play here – Writable Disks.
A Writable Disk is a user-specific disk (so one per user) that can be deployed alongside AppStacks (it’s always the last one attached). This too is merged and is otherwise invisible. A Writable Volume can be deployed to support three policies –
User Profile only – basically, it can replace VMware View Persistent Disks for User Profiles. Don’t consider it as a replacement for a proper environment management solution though.
**User Installed Applications only ** – so it can manage user writes to the C: drive excluding the user profile.
**Profile and User Installed Applications ** – a policy covering both of the above.
This disk, particularly with the latter policy is a powerful tool. As it can capture writes back to the OS disk, it provides the ability to capture writes to applications in AppStacks as well as allowing the user to install their own applications (subject to user rights, of course). The implication of this is that it’s possible to deploy a non-persistent desktop and allow it to behave in the same way as a persistent desktop!
Maintaining Applications in an AppStack
This is a pretty straight forward affair. There’s an edit function in App Volumes that effectively clones the current version of an AppStack. This can be attached to a VM in a read-write manner and the application stack upgraded, enhanced etc. prior to being assigned as a replacement for the existing stack. Don’t worry – rolling back is easy too – just re-assign the previous version.
Nice. So….what’s the catch?
As with everything, there are limitations.
Multiple AppStacks can conflict
An AppStack can contain multiple applications, some of which might include shared components, such as specific Java versions, DLLs etc. Presenting multiple AppStacks can have a negative effect – AppStacks are applied in sequence, with the last one applied taking precedence. For example. AppStack A has an application which uses wibble.dll version 1.0, while AppStack B has an application that uses wibble.dll version 2.0. If both AppStacks are assigned to the VM, and AppStack A is attached last, then the application in AppStack B might fail due to wibble.dll 1.0 taking precedence.
There are three ways around this issue:
For a given application, try deploying it as a ThinApp package inside the AppStack – The virtualised application sandboxing avoids conflicts.
Override the order in which AppStacks are deployed – this is possible from the App Volumes Manager.
Plan your AppStacks – try, where possible, to group applications for a department together to minimise the need to deploy multiple AppStacks.
How many AppStacks can you deploy to a VM?
In many ways, this is a limitation of the technology – You’re mounting virtual disks – the more you mount, the longer the log on time. In addition, the more you mount, the more you might risk application issues between AppStacks. VMware recommend less than 15 disks, including AppStacks and Writable disks.
Try not to look at this as a solution for delivering granular applications – use it to shift stacks (the clue is in the AppStack name…). Generally, in most environments, departmental users have applications in common – so using AppStacks containing a common stack can be used to meet 90-100% of a user’s needs in this manner – if granularity is required for the last 10%, consider using Writable Disks, either allowing the user to install their own or using Writable in concert with an alternate delivery system such as SCCM or VMware Horizon® Workspace published ThinApp packages.
AppStacks are pretty powerful. Even device drivers and services are possible, however anything that needs direct access to the kernel is a problem – so deploying a PDF printer will work, but deploying an Antivirus tool or disk encryption software probably won’t.
Doesn’t support Windows XP or physical devices.
At present, App Volumes doesn’t support physical devices – for that, you can use VMware Horizon Mirage App Layers for a similar experience.
As for Windows XP – No support here either and this is a good thing. Time to move on – ye olde Windows XP is not in support any more!
So, for delivering applications to a VDI solution, App Volumes is a really slick answer. Provisioning of stacks of applications in a LAN-free rapid manner is an attractive selling pitch, especially as it can support not just virtualized application packages, but full, natively installed Windows applications. The writable disks are a bonus too – the combination of non-persistent desktops, AppStacks and writable disks makes a compelling case for ditching persistent desktops in nearly all scenarios.
The interesting part is that it is (and will remain) broker agnostic. It can be delivered as easily in a Citrix XenDesktop/XenApp solution as it can a VMware Horizon View solution. This is why VMware now offer App Volumes as part of the new Horizon Application Management Bundle – a suite that takes VMware Horizon solutions that complement an existing Citrix solution.
Otherwise, VMware App Volumes is now included as part of the VMware Horizon Enterprise suite or can be purchased individually.
If you’d like any assistance with a VMware App Volumes project or simply want to learn more about it or any aspects of VMware Horizon please contact us, and we’d be more than happy to use our real world experiences to support you.
