Blatant Self Promotion

As the title says, it’s been one of my more “public” weeks ever. Besides my “normal” vSoup engagement, this week I’ve also been involved with Mike Laverick’s VMTN Subscription Movement Miniwags to voice some of my views about the #VMTNSubscriptionMovement.

Fair warning: This is video, and please to remember that during recording Movember was nearing its final phase.
VMTN Subscription Movement Miniwags – Christian Mohn

Secondly, I was a guest on the Veeam Community Podcast Episode 45 – vSphere 5 Storage Potpourri.

Third, and last, SearchServerVirtualization posted VMware vSphere Storage Appliance: Devil’s in the details which also includes some commentary from yours truly regarding the VSA.

Testing VMware vSphere 5 Swap to Host Cache

A little while ago I fitted a small 64GB SSD disk to my HP MicroServer just to have a quick look at the new vSphere 5 feature Swap to Host Cache, where vSphere 5 reclaims memory by storing the swapped out pages in the host cache on a solid-state drive. Naturally, this is a lot faster than swapping to non-SSD storage, but you will still see a performance hit when this happens. For more details on Swap to Host Cache, have a look at Swap to host cache aka swap to SSD? by Duncan Epping.

Now, in my miniscule home lab setting it’s somewhat hard to get some real tangible performance metrics, so my little experiment is non-scientific and only meant to illustrate how swap to host cache gone wild would look in a real world environment.

After installing the SSD drive, and configuring Swap to Host Cache, I created two VMs ingeniously called hostcacheA and hostcacheB. Both were configured with 14GB of memory, which should nicely overload my host that has a whopping 8GB of memory in total.

Now, with memory features like ballooning, transparent page sharing, and memory compression I needed to make sure that the actual memory was used, and in addition it had to contain different datasets to make sure that the host cache actually kicked in.

To make sure of this, I downloaded the latest ISO version of Memtest86+ and connected it to the empty VMs.

When starting the VMs, they immediately started testing their available memory and sure enough, they started eating into the host cache.

As you can see from the screenshot below, the longer the memtest ran the more host cache was utilized.
Bonus points for figuring out when the test VMs were shut down…

So there it is, performance graphs showing that the host cache is indeed kicking in and getting a run for it’s money. Since this was a non-scientific experiment, I don’t have any real performance counters or metrics to base any sort of conclusion on. All I was after was to see if it came alive, and clearly it did.

VMware Horizon Application Manager Now and Beyond

VMware has announced Horizon Application Manager 1.2, and together with the new ThinApp 4.7 release it promises “end users access to Windows, SaaS and enterprise web applications across different devices while retaining control and visibility via policy-driven management”.

VMware Horizon Application Manager now manages your ThinApp applications making it easier and faster to provide virtualized Windows applications to end users. From Horizon Administration, you can deploy ThinApp packages, entitle users and groups, track user licenses, and manage application updates.

The coupling of the Horizon Application Manager with ThinApp is a great idea, and when I saw today’s announcement I got pretty excited. The possibility to have your own internal application portal providing your end users with self-service installs of virtualized applications is great news and could potentially be really useful in a great number of organizations.

Sadly my initial excitement quickly faded when I realized that for now Horizon Application Manager is a hosted service, that requires an on premise connector in your infrastructure that sends over a limited set of Active Directory data to enable it to check user account or group access to the applications it offers. The connector provides single sign-on (Kerberos) functionality for users already authenticated in your Active Directory and authenticates the user to the Horizon service using SAML, so the hosted service never has the AD password. The hosted service does still needs some information like samaccountname, first name, last name, email and a GlobalUID.

For more details, have a look at Understanding VMware Horizon Application Manager by Eric Sloof.

This also means that users who run a virtualized application provisioned by Horizon Application Manager an active internet connection is required, even if the virtualized application packages are stored on a local (to the user) file share. Subsequent application launches does not require an active connection, as the applications are copied to the local system on the initial run. The Horizon agents retrieves a lease for the application, from the Horizon service, for an administrator configurable number of days (30 days default) and the end-user can run the application, without connecting to the Horizon service, until the lease expires or is renewed.

For many organizations, including mine, this poses a real problem. “Handing over” Active Directory data to a hosted service is not something I would want in my environment, especially when our use case would be to provide end users with a self-service application portal for local applications. Other organizations might look at that differently though, and this might not be a concern for all customers.

I understand that Horizon Application Manager was initially created for SaaS scenarios where a hosted authentication portal makes sense. I also understand that this is the first version that provides integration with ThinApp, and this is very much a product still in development and refinement.

For now, Horizon Application Manager does not provide the use case that I was looking for but thankfully Ben Goodman, Lead Evangelist for VMware Horizon, has taken the time to address my call for an on-premise version of Horizon Application Manager:

I understand your apprehension. Horizon was built on top of technology originally designed exclusively to be a Single-Sign on service to SaaS applications. We are in the process of expanding that technology to become a true enterprise service. This is happening in two ways, the first is by adding application support beyond SaaS. The first step was Windows support via ThinApp and we are looking at other application platforms to follow. The second is evaluating options for moving some or all of product on-prem. Both of these steps are the primary focus of the development team over the next 12-18 months and we are really excited about where we are taking Horizon.

This is great news, an on-premise version that provides exactly what I’m looking for seems to be in the pipeline and on VMware’s roadmap for Horizon Application Manager. I just wish I had it now, it would have been perfect for a project I’m working on at the moment that I hope to wrap up by the end of the year.

Oh well, there is always next year and the next project!