This is a multi-part blog where I am exploring and learning about VMware App Volumes. This is part 1 so welcome to my mind crunch.

Another acquisition leads to another IP release for VMware, this is the reality of IT today. In August of 2014 VMware bought a company called CloudVolumes, haven’t heard of them? Not surprising, but the product that this relates to is VMware App Volumes for Horizon suite. It comes packaged for free with the Enterprise edition. So what does App Volumes provide?

As always I am glad you are asking these questions voices in my head. App Volumes delivers applications to virtual desktops via VMDKs. Think persistent disks that we use for user profiles but now with applications? The funniest part of this to me at least is that VMware calls the App Volume deployment an Application Container **cough Docker cough**. Sorry I had a different technology stuck in my throat. So the solution looks like this:

 

Yeah I stole that from VMware’s product page sue me.

This application abstraction layer isn’t unlike what we see with Mirage or ThinApp except that rather than streaming the application from a CIFS share, instead the application is installed on a VMDK as either a read-only or writable volume.

The way VMware makes the writable volume sound from the documentation is that this disk should be used for application and user profile data as well as provide a location to install applications away from the base image. From a high level I take issue with this as one of the goals of EUC and VDI in particular is eliminating image and application sprawl and reduction in OPEX. How in the hell do we reduce these if we are allowing users to install apps willy-nilly on a writable VMDK that we then have to manage? Take that one step further and if you have leverage persistent disks for user data you know the pain of having to re-map user data disks after re-provisioning. This is why the persistent desktop folks gain any traction vs those of us who preach non-persistent desktop pools. More on this in a bit though.

Back to the solution: so the application disks (these are called AppStacks) can be assigned via the App Volume manager. Before you say it I know, Horizon is getting so many products in the suite that it’s looking more and more like a Citrix XenDesktop deployment with all the different management consoles. But let’s look past that shall we? So the App Volume manager leverages Microsoft Active Directory security groups to provision the AppStacks to user groups. The good news here is we can still do AppSync like application upgrades and patching. We can just resync the updated disk with the associated users. Cool right?

Since we are “containerizing” our apps we can leverage multiple app volumes (VMDKs aka AppStacks) and stack them to our groups. So if we have 1 app mapped originally and have to deploy a second then like Emeril Lagasse we just say BAM! and add the app disk. The default deployment is a 20GB AppStack template, this can be customized, I didn’t have anything to deploy bigger than that so I stuck with it.

AppStacks are captured during the installation process very similar to how ThinApp package captures occur. However unlike streaming an app, the App Volume Agent helps to blend the AppStack seamlessly with the virtual desktop so the user doesn’t notice that it’s not installed natively (again I am in a lab so if this looks different in production let me know). ThinApps can now be provisioned as AppStacks as well which (again in theory) reduce network traffic and previously experienced network latency on streamed apps.

RDSH desktops are also supported with App Volumes as an AppStack, as long as the agent is installed you provision them just like you would in any other EUC instance. Note thought that only Windows 2008 works with RDSH integration.

Ok so the writable volume, here is where I am confused (yes it’s not hard), essentially you would leverage this to be both the application repository as well as the user data and app data storage. With each Writeable Volume deployment three templates get created. A User Installed Applications (UIA) Only, a User Profile Only, and a UIA & User Profile. Writable volumes default to 10Gb.

App Volumes comes with a Block Login Policy. This is key if you have ever managed user profiles the one thing that sucked about Microsoft roaming profiles was profile corruption from a user having multiple logins at once and the corruption that occurs as they log out and the UPHclean runs and syncs the profile. The Block Login Policy stops users from logging into additional VMs while their writable volume is attached and active.

We can also set a Limit Attachment policy which requires a set machine prefix to attach the writable volume. Think how kiosk mode in Horizon works. There is also a Defer Create Policy is smart and dumb at the same time, so because App Volume links to AD OUs or groups if you enable Writable volumes for a group all users automatically get a writable volume created, the Defer Create policy helps to regulate that by not creating the volume until the user logs on the first time.

Profile migration can be done through writable volumes as well, as Windows Roaming profiles can be captured into a writeable volume this volume can than be attached as a local profile to Terminal Service logins as the user spirits about your vast array of application servers.

The last thing to know about Writable Volumes is that it has unique storage groups. You can have Spread which distributes evenly across all storage locations, spillover which fills one location before spilling to the next, and round robin which distributes sequentially based on oldest or last file time stamp.

AppVolume is for non-persistent desktops to me at least seems to work best on non-persistent desktops. I don’t want to get into a religious debate between persistent vs non-persistent. I will say if you are a persistent desktop zealot check out what Liquidware Labs is doing with FlexApp2. I think they have a compelling case against App Volumes.

App Volumes is also a sold as a stand-alone product so for the folks who were previously leveraging it to layer apps for their XenDesktop environments because they didn’t want to deploy XenApp or wanted an easier management they can still do that. Heck if you don’t want to use AppV for it’s bloat issue App Volumes may be a good fit for Microsoft VDI environments too.

Ok so let’s answer some simple questions:

Q) What happens to ThinApp?

A) Apparently the teams are rolled together and working on Project Meteor which is pretty cool. It’s the concept of Just-In-Time desktops with instant cloning and app provisioning. Check it out here.

Q) Horizon workspace used ThinApp, how do I do an App Catalog now?

A) App Volumes will work with Workspace by presenting RDSH apps individually. Yeah got me that’s from VMware’s official blog.

This is based off of the VMware blog and the Technical Deployment Guide next up will be install and config in the lab and testing