by
Brian Madden
Last week I wrote that one of the main challenges in the leading VDI products on the market today is that their remote display protocols—ICA and RDP—don't work with all applications. I also put forward the idea that until VDI can work for 100% of applications, it won't grow much beyond the niche solution it is today. Putting those two thoughts together, one could argue that better protocols = broader VDI adoption.
But the whole "protocol capabilities" discussion is really about graphical application performance and local peripheral compatibility. The ultimate long-term goal of these remote computing protocols is to make them work as well as a normal locally-installed OS.
Taking a step back, it's important to think about why companies will adopt VDI in the first place. Fundamentally it's about saving money. Most of savings will be in the form of reduced management costs.
Since today's VDI solutions are SBC-based, companies also get the traditional SBC-related benefits in addition to cost savings. (These SBC benefits are things like data security, decent app performance over slow connections, back-end live migration of running VMs, access from any client, etc). But of course SBC-based VDI environments suffer from the same downsides of any SBC environment, like poor graphics performance and not being able to work offline.
So how can a company get the cost savings of VDI without the downsides of SBC? Simple... don't use SBC!
In other words, imagine a VDI environment where the desktop VM is running locally on the client device instead of on a backend server in a datacenter. Crazy, eh? "Client-based computing." (CBC?) What a concept! ;)
At VMworld in Cannes earlier this year, VMware previewed a technology they're calling "Offline VDI." (Check out the middle bullet item about half-way down that page.) With offline VDI (OVDI), users can "check out" a desktop VM that they're accessing remotely. The VM is copied down to the client device where it can be booted and executed locally. When the user is back online, they power off their local VM, click an option to check it back in, and their delta disk image changes are sent back up to the server where they can use their VDI image in an online SBC way again.
At this point OVDI is just a basic technology preview, and it's rough around the edges, but it solves some interesting problems for VMware:
- OVDI fixes the protocol capabilities problem. What protocol is better than ICA, RDP, Spice, or PC-over-IP? VGA!
- OVDI fixes the peripheral problem, in that all local USB camera, mics, phones, scanners, devices, etc. work as planned.
- And of course, by definition, OVDI fixes the offline problem.
Will offline VDI replace SBC-based VDI?
With these three major advantages of OVDI, why would anyone use the (now) "old school" SBC-based VDI? Well, OVDI still has some disadvantages when compared to SBC-based VDI, namely:
- OVDI requires sufficient local computing capabilities that can run the VM.
- OVDI requires that the VM disk image somehow gets from the server to the client.
- OVDI requires at least some kind of client device support, since there needs to be a baseline OS/hypervisor/VMM of some sort.
OVDI + SBC-based VDI: The 100% solution?
Going back to that whole "VDI needs to be 100% to be mainstream" thing, do you think that traditional SBC-based VDI (like what we have today), combined with offline VDI for certain use cases, could be the ultimate solution?
This "ultimate" solution, in my mind, is still tied to being able to use a single stateless disk image for all users—online and offline. Imagine if we had a true layered model, with the base OS, the user environment, and applications all running in their own isolated layers in the stack. Then a single disk image could be used for about as close to 100% of users as we'll ever get.
Other vendors besides VMware are thinking about this too. Microsoft's purchase of Kidaro this past January could be the first steps of their entry into the offline VDI space. Citrix doesn't have a local VM story today, but maybe they can piggyback on Microsoft / Kidaro and add some "capabilities" there too?