New! Listen to this post in our daily podcast.
Yesterday’s main article on BrianMadden.com was about the disk images used for today’s VDI deployments. We specifically looked at whether the technologies that allow many users to “share” a single master image are actually ready for hard core users now, or whether today’s large VDI deployments are limited to using “personal” images where each user has his or her own image that’s saved from session-to-session.
The main point of the article (which jives with what most of the commenters wrote) was that VDI was in fact not ready for large populations of disparate users to share single master images.
But why not? That’s what we’re going to look at today:
Background on shared images versus personal images
If you’re not yet familiar with the concept of “shared images” versus “personal images,” I suggest you first read an article I wrote earlier this year about Atlantis Computing’s ILIO product. That article has a whole section called “Background info on the VDI shared master disk image concept” that really gives you the background you need. (And of course, if you haven’t done so, read yesterday’s article “Is today’s VDI really only about non-shared personal images” to catch up on the conversation so far.)
Assume we’ve solved the disk image block and file problems. Now what?
Ok, so now that you’ve read the prerequisites, let’s assume for sake of argument that you’ve totally solved the “file versus block” disk image delta problem. (Maybe you’re using Atlantis ILIO or you’re reading this at a time when another vendor’s solved the problem.) Fine. So if that problem is solved, then what’s the big deal? Isn’t that the end of the conversation?
Hardly. (I mean come on.. this is BrianMadden.com! :)
There’s still a fairly complex logistical problem. For example, Atlantis can show you a badass demo of them building a master Windows XP image based on SP2 which is then deployed to users. Then they can show a user installing iTunes which of course persists between reboots in their personalized image. (I know, I know.. Atlantis doesn’t have “images” per se, but just hang with me for sec.)
So then Atlantis can show you how an admin can crack open the master image and make a major change, like updating it from XP SP2 to SP3. Finally they’ll show you how they can boot the user’s instance which is now on SP3 while still having iTunes installed!
This is super amazing, and peoples’ first reaction is typically something like “HOLY CRAP THEY’VE DONE IT!” In fact that’s what I even wrote in the article.. (I literally wrote “"Wow. Wow. Wow. YES! This is what we need! Wow. Wow. Must breathe. Wow.")
Except there’s a huge problem here. In the XP SP2 to SP3 with iTunes example, we were lucky enough that the same install of iTunes was compatible with both SP2 and SP3. But what if it hadn’t been? What if XP SP3 changed some file that would break iTunes? Even Atlantis’ file-level and block-level intelligence is worthless here. (Sure, it’s great that it knows which files and which blocks were changed, but it doesn’t have the smarts to deal with every app out there.)
So while that’s a great demo, (and while there are many other reasons to use Atlantis, like for the massive increase in IOPS you can get which lead to more users per disk than anything else in the market), Atlantis isn’t the magic bullet that’s going to make all of your complex apps work on a single shared master image.
Enter the app virtualization vendors
At this point you think, “No problem, this is where the traditional app virtualization vendors come into play.” If we can just isolate/virtualize each app, then we in essence separate them from the underlying OS.
If only it were so simple! (Seriously, if it were so simple, we’d all be doing that with all our apps today.) But everyone knows that there are issues with app virtualization with certain apps, and that no solution out there can deal with everything.
Actually there’s a weird irony here... App virt products increase “compatibility” by sort of staying out of the way of what the apps are trying to do. So this helps broaden compatibility while hurting the chances that multiple conflicting apps will work side-by-side. In other words, there’s a sliding scale in app virt between “compability” and “isolation.” More of one equals less of the other. (This is kind of like the age-old “security” versus “convenience” balance.)
This is the problem that also dogs non-traditional app virt vendors like RingCube. (RingCube? Seriously? Hell yeah! Even though their traditional play has been about super portable VMs that reuse existing Windows client components, I see their future as one of the sort of “ultimate” app virtualization environment. But that will also come at the expense of interoperability, as they would essentially give each app its own Windows VM.)
What’s the solution?
So if conflicting updates at different layers is the problem, then what’s the solution? (If you’re waiting for a punchline here, there isn’t one. I actually want to know what the solution is!)
I’m just starting to worry that since Windows was never designed to be assembled this way, I wonder if we’re ever going to solve this problem? I mean there are just so many complexities and dependencies and incompatibilities and lines and arrows and layers... do you think that we’ll ever see an answer to this problem before we’re all running Chromium?
I guess I want to be optimistic. We still don’t know what Unidesk is up to. And certainly Atlantis has made improvements since we first discussed them. And RingCube is getting better all the time. And let’s not forget all the traditional app virtualization and user environment vendors!
But is this a problem that can be solved with technology? Or is the whole sharing a single image for “real” users just a pipe dream?
[PROGRAM NOTE: This is the week of the Thanksgiving holiday in the US, so this article is our last for the week. We’ll see you all back here on Monday November 30.]
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.