The Myth of the Gold Image
8 comments, 3135 views
Over the last couple of weeks I have had conversations with a number of VDI customers (and some of those just testing VDI) about their management needs and specifically their apps and gold images. One of these customers put a bug in my ear that eventually turned into this post. Basically, this VDI customer is rolling out about 1000 desktops or so and said to me the following:
“Gold image? Do I have a gold image? Yeah I have a gold image I guess. Then I tarnish it up by pushing down about a dozen different desktop configurations with different “base” applications."
"Of course then I also have the line of business applications on top of that, those dictate the base applications. So if that is a gold image, I have it. But it’s not what I imagined it to be.”
What struck me was his complete disdain for the term ‘Gold Image’. He hates it. He thinks that people talking VDI just don’t get the complications of dealing with desktops, even in a “small” environment like his.
Basically anytime he talks to Citrix or VMware or ANYONE in the VDI game about App and OS patching they always bring up the “gold image”. Then they go on to talk about what goes in there versus what is virtualized as an application or what is streamed. His problem with the “gold image” idea is that he has so many different configurations that a single gold image is impossible. And when he hears about “just patch the gold image and push it out” he has to remind them that just a little bit into his testing he had 5 gold images (not one), and that if he had continued with their system he would have probably had 10 or 15 “gold images”. The other funny thing here is that to really get to a single “gold image” he would need OTHER technologies (other than VDI mgmt tools) to build the desktops that are separate from the OS or image management system.
As a further example of this issue I spoke to another customer and built a simple (VERY VERY SIMPLIFIED) application matrix representing one of the sites this guy is building a VDI solution for. Below is that matrix:
The interesting thing about this configuration is that it does have a number of applications that are, or could be, in the “Gold Image”. The Office version this customer uses can be used by all his users in this one site (of course this is not the case in all of his sites and may change on the whim of an application vendor). But if you start to look at all the other applications you will notice 5 unique application sets not shared by other groups (unique to one group). You will then notice a few applications that are used by multiple groups but not all. And this will only get more complicated as the image only represents about half of the applications sets that will really wind up on the desktops.
In this case, the VDI customer may have 1 Gold Image but then would have to package (virtualize) or stream (XenApp/Terminal Services) all these secondary applications. Or as my customer puts it “I have to build TWO sets of infrastructure, WTH?!” Another option for the customer is to create eight gold images for this site and hope to reuse some of them in other sites… then of course, patch and manage each of the gold images as a unique object.
All of this is crazy and really screams for each part of the desktop to become a unique, manageable object. The OS should be able to be shared by anyone that needs it. Office, Anti-virus, core applications, secondary applications should all be able to be deployed to any desktop (still using the shared OS).
Hardware virtualization took us to the point of separating the logical machine from the physical. Allowing us to manage that logical machine without care for what is going on at the hardware level (upgrades, movement, etc). The same will eventually have to happen for desktops. We need to manage Windows so that you update it, or change it, one time for everyone. Then layer applications on top of it as required by the user’s needs. The idea of managing 8 or 10 or 15 gold images is a step in the right direction, but desktop layering (real layering not what some substitute teachers call layering) is the solution.
Ron’s Politically Incorrect VDI Blog
Too many organizations are out there trying to implement VDI and failing. Whether you like what Ron has to say or not, he is here to say what others won’t about VDI and help you get it right in your environment. Get Ron’s advice… raw…unfiltered… without the sugar coating.
 |
Comments
App virtualization cannot handle all applications. In the example above specifically the fingerprint apps require device drivers and services. The Office plugins cause problem with Thinapp, etc, etc. App virt is a good thing, but not a utopia. Typically even BIG app-virt environments only ever get toe 70% of their apps virtualized and even take some of their base apps OUT of app virt simply because of complicated application interdepencies. See this: http://www.unidesk.com/blog/why-application-virtualization-didnt-turn-out-be-nirvana-lot-us-thought-it-would-be on app virt. Can it be used. Yes. but show me a shop with 100% of their apps virtualized? or 90%. there are very, very few even in the places that have been using it for years. Then adding it to an environment that has never used it...
I don't get it any well implementen VDI environment includes application virtualization which allows you to give access to the virtual apps based on the rights of the user using the VDI instance. You always try to keep the image as 'clean' as possible otherwise you are indeed stuck with the situation as you described.[which isn't only harder to manage but also will need more unnecessary diskspace]
Maintaining two infra's for this... huh? Of course indeed in my suggestion there is The VDI infra is for the OS and the Virtual App infra is for the functional layer above. But this is how you get to a well managed infrastructure which allows you to get to a dynamic situation and you can easily introduce even more stacks of OS+Apps without the need to figure out which groups are unique.
Well if you have any questions give me a yell. Streaming, and even XenApp/TS have a place. Here I am just focusing on building a desktop model that works. Do we solve every problem on the planet???? nope. Just trying to fix some of the hard ones for a desktops.
As I said, give me a ring if I can address something specific about what we do.
Good point. And even the application .vhd for XenClient is really only intended for streamed apps/Citrix receiver so it doesn't solve the problem you mention. The Unidesk solution sounds interesting...time to educate myself. :)
-SpeakVirtual
www.speakvirtual.com
Actually, anything done with separate VHDs or VMDKs wont solve it. The issue is that these are block level solutions. The profile (or parts of the profile) being put on a secondary VMDK work essentially by using folder redir (or what is essentially a romaing locally stored profile). The profile doesnt encompass everything that is in the user personality. Its close, but the weakness is that applications live in the file system and registry and often outside the profile. They are namespace aware. Update the OS VHD and those apps (or more appropriately the disk) will not work. The files there might. but just putting some app files on a second drive and then reconnecting an updated OS drive doesnt update the registry, keep file assocaitions etc. sure you get the profile back, but does it look and act like it did just before the update?
So this must be done within the file system and registry name space (of course that is what Unidesk does).
I'm not very familiar with the Unidesk solution but I wonder if something like what Citrix did with Dynamic Images in XenClient will ultimately be the answer. The OS, Application and "Documents and Settings" layers are separate .vhd files that make up one operating system. A physical separation like this would allow you to easily snap on and remove layers as necessary.
-SpeakVirtual
www.speakvirtual.com
Paul,
Not a bad point and in some smaller environments that is possible. Of course then it becomes more and more complicated for regression testing. Each application on the desktop (for any given business unit) should be tested when one of the other apps or supporting apps are updated. This of course assumes that of all the apps for each business unit will work and play with each other without issue in the first place.
In the example above I show office 2007 across all the users. Of course the customer I helped install this morning is using 3 versions of office to support different lines of business.
Personally I think Unidesk (with the layering technology we have) is the fix for this. The OS and apps all being independently manged objects that can be used to assemble a given desktop build allows for a single "gold image" that is only OS and shared by everyone.
Well... at least I THINK its the solution, which is why I came here :-)
It may seem very simplistic and may contravene some\most licensing models but in theory could you install all necessary applications on the gold image, redirect to a custom 'empty' Start Menu and Desktop and then script the population of both with the shortcuts users need based on security group membership ? If you lock down access to local drives thereby giving them no means to run the apps other than the shortcuts this would be a technical solution to the problem. It would be no different to streaming or publishing the applications in terms of access as access if given via groups. The only question would be the legality of this approach governed by the licensing model of each app installed. It may cut down the number of gold images needed if allowed.
Post new comment