AppVolumes is the Chlorine for your Horizon View Pools

Actual things I’ve said:

“So, you have 32 different pools for 400 people?”

“So, you have one full virtual for every employee worldwide?”

When I’ve said these things or things like it, I usually get the Nicholas Cage look back, like “DUDE I KNOW…It’s not like I had a choice”

It seems that plenty of folks have had the same problem of pool sprawl due to application compatibility issues, or things they were unable to script or work around. Having been in delivery in the virtual desktop space means that I have seen and lived with the problems of a stateless desktop environment, most of which can be overcome with some time, energy and willingness to script. Most of these obstacles are profile related, and can be easily mopped up with third party tools, but the focus of this post is what happens if we stay inside the VMware product suite without any third party extras. So the main painpoints that remain apart from profile and application setting abstraction are:

• What happens if a user legitimately needs to install their own apps, they want it to persist on the local drive for best performance, and they’re already using a stateless desktop?
• How can we consolidate as many users into the same desktop pool as possible without application dependency contention?
• How can we granularly control and minimize risk during locally installed application updates? Also, how can we do it faster?

What ends up happening to most organizations is that we end up getting bacteria-like applications which cause admins to create separate pools or put a user on a full virtual. The VDI admins often times end up getting torqued at the “fringe apps” that are not central to the core business but still need to run in the virtual desktops. This is usually due to the fact that there are more use cases in a department than are initially guessed. A good example is when a Marketing department is actually 4 different use cases rather than 1 due to crazy one-off app requirements. Along those lines, these are some of the problems I’ve seen with some of the fringe “problem child” applications:

• No support for AppData redirection
• Large application in size which drives poor performance on network share or when virtualized
• Vendor requires locally installed application
• Apps that require multiple conflicting dependencies such as verisons Microsoft Office or Office Templates
• Apps that require weekly or monthly updates that users don’t want to have to perform only once per interval (and View admins certainly don’t want to recompose for, ugh)
• Security requirements that dictate applications cannot be installed for users that need them installed, even if locking them down another way is available.
• Countless “one-off” applications that will not virtualize, sequence or otherwise be delivered unless they are locally installed

Let’s take a look at an image from the vmware.com AppVolumes page which clearly illustrates the difference between a locally installed or streamed from the network or remotely hosted application.

While AppVolumes won’t kill the bacteria in your swimming pool, it will most certainly allow you to clean and clear up your View pools and pave the way to a single golden image dream with instant and simple application delivery along with much cleaner and safer update methods with a faster rollback. It will mean that the only legitimate need to create a new pool is for resource differences in the VM containers themselves, and the golden images themselves will mostly likely have no apps installed locally in it. This is absolutely FANTASTIC. Under the covers, what’s really happening is that the applications and settings are being captured to a VMDK which is mounted to the capture machine, then the application is installed to it. It’s sealed, and then disconnected and hot added to multiple VMs simultaneously. The craziest part of this whole method of updating the installed applications means that you almost never have to kick a user out of their VM. However in the software as is, you have to unpresent the AppStack, then re-present the updated version during an update, so it’s a not an entirely seamless AppStack update procedure, but it’s a heck of a lot better than dealing with a recompose that impacts more departments than it needs to due to the use of a COE pool (common operating environment) which I and others preach when using stateless desktops use cases. Once I get some hands on with the product I’ll know more about the update procedure and will write about it for sure, but apparently it’s been a pretty hard to get hands on even for partners.

So what does this mean looking forward? It means that you can crack open a can of Happy New Year 2015, and start fresh. REALLY. Fresh. It’s the opportunity to start with a clean slate and keep it clean as a whistle, while maintaining persistent user installed applications, per department applications, and one off applications. Not to mention if you own Horizon Enterprise, you will get AppVolumes for free out of the gate! Cheers to that!

I’m going to try to start a new App Volumes themed blog post series for those like myself waiting for Cloud Volumes to become GA. The following are some of the topics I’d like to write on. If you’d like to hear one of them, please sound off in the comments, it’s a good source of motivation. : )

1. Optimize Your Windows Base Image Like a Boss
2. AppVolumes: Best Practices for AppStacks and Updating
3. AppVolumes compared with RDSH for One-Off Application Delivery
4. A Real World Plan for Migrating to AppStacks from Traditional LC Pools