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 … [More]
By Curtis Brown 38 0
IntroductionVMware 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 ServersA 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.
Maintaining Applications in an AppStackThis 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 conflictAn 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.