by
Brian Madden
The only actual new announcement that VMware made about desktops at VMworld last week was that they were licensing RTO Software’s Virtual Profiles product for inclusion in some future version of VMware View. (press release)
This is great news, as the whole “user data disk” plus roaming profiles technique currently employed by View doesn’t really cut it in the real world.
If you’re not familiar with RTO’s Virtual Profiles product, check out Cassondra McAllister’s demo of it from the DEMO Lab at BriForum 2009 this past July. (The part on Virtual Profiles starts at 1:50 in)
This is an OEM deal, meaning that RTO will maintain the codebase and will continue to sell the Virtual Profiles product on their own, but that at some point you’ll be able to buy VMware View products that include RTO’s technology. VMware has not yet announced any details as to when this might be available.
RTO’s founder and Virtual Profiles creator is Kevin Goodman. Kevin’s been a presenter at the past six BriForum conferences. He co-created the “Citrix Logon Process Chart” with me and he was our very first guest on Brian Madden Live! (Our podcast which has been replaced by Brian Madden TV.)
On the business end, Kevin created the TScale DLL optimization product which he licensed to Citrix (which became the “Memory Optimization Management” feature of XenApp a few years ago). This past March we learned that Kevin licensed his Virtual Profiles technology to Symantec, which is the same core technology he just licensed to VMware. So congrats to Kevin!
Kevin was at VMworld last week and I pulled him aside for a quick interview which we put into last week’s episode of Brian Madden TV. (Interview starts at 2:54)
Why RTO?
With so many profile virtualization / user environment management products on the market, why would VMware choose RTO Software?
Of course we don’t know what the back room negotiations were like, or whether VMware shopped around between several vendors, but one thing that’s interesting about RTO’s Virtual Profiles is that it doesn’t leverage a back-end database or management system. It’s just an agent and some data stored in the profile folder. This is very similar to how ThinApp works and something that makes both ThinApp and RTO different from their competitors. So while it’s not that this is a better technique per se, it’s interesting that both products work in this way and it makes sense that VMware’s would include products that are both similar in this way.
Is this “just” profile management?
Two years ago I wrote a blog post wondering whether it was possible to “just” manage profiles or whether we needed something the manage the entire user environment. That post was based on a conversation with AppSense’s Pete Rawlinson, and Pete actually posted his thoughts to AppSense’s blog last week about the RTO announcement.
Pete argues that while this OEM agreement is a good thing, RTO’s technology only focuses on profile management and doesn’t capture everything that’s needed for managing the “complete” user personality. (So again, this is the same conversation we’ve been having for years, and boils down to whether you want to capture changes that were only written to the user’s profile area or to the entire system.)
Pete makes a good point. The current version of RTO Virtual Profiles does only capture profile changes. That said, RTO is working on a new version of their product that can capture and restore changes written anywhere on the system. This is something that we first learned about back in BMTV Episode #16 when RTO Software was our random vendor of the week. Chief developer Erik Tatum demoed how they could, for example, capture changes written to c:\mystuff and redirect those into the profile folder. (Video here, with this portion beginning at 24:50.)
So today that’s just a future technology from RTO (although they were demoing it at their booth at VMworld last week). But according to Kevin (from BMTV #17), it sounds like VMware will also have access to that capability as it comes online. And this is critical to VMware.
RTO’s product can evolve to help fix offline VDI
During the Day 2 “technical” keynote, VMware CTO Stephen Herrod mentioned that offline VDI was broken. He was talking in the context of syncing disk images, because VMware’s current offline solution leverages the VMDK delta differential file technology. This is a problem because it works at the disk block level, so you end up with a scenario where you have to synchronize huge amounts of data with your client to take it offline, but most of the data ends up being stuff that you didn’t need anyway.
Just imagine how much garbage Windows writes to or changes on the disk. Sure you can make policies to zero out the page file and stuff, but if you’re looking at Windows from the outside, you’re going to end up moving a lot of worthless disk blocks around.
A better way would be to run “in band” so you knew what was valuable and what wasn’t so you only moved around the good stuff. This is where the new capabilities of RTO Virtual Profiles can come in. So now instead of trying to use policies to redirect user changes to auxiliary VMDK files, you could write everything to the c: drive and let RTO capture the changes and sync them in real time up to a file share. Then you’d only need to sync up the actual files to take the thing offline.
This new capability will also help with the complexities that arise from multiple users sharing a single master disk image. (What VMware calls View Composer.) Sure, you can use ThinApp to add apps on demand, and you can use the traditional RTO Virtual Profiles to capture and save profile data. But what about those changes that would be written to the c: drive and then lost when the VM was refreshed? RTO’s new stuff would allow those too to be captured.
So while we should be excited about VMware OEMing RTO Virtual Profiles for “just” profile management today, the real value and brilliance of this deal will be apparent in a few years when they start incorporating this capability into other aspects of their View product.
(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.