A few weeks ago I wrote about VMware’s upcoming OnDemand streaming technology. (This is a feature that lets a local virtual machine boot a VM from a disk image before it has been copied 100% across the network. In effect it “streams” the disk image from a file server to the client.) I wrote that this was similar to Citrix’s Ardence technology, and I said the VMware technology might be better than Ardence’s since it would work offline.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Many readers disagreed with my views. They felt that Ardence was better than VMware because (1) it could work with any hypervisor or on native hardware, and (2) that Ardence’s “shared disk image mode” (where multiple clients mount and stream the same disk image from a server) is critical in the VDI space.
On the first point, I think the readers who commented on that article were right—Ardence will provide more flexibility since in addition to working on native hardware, Ardence can be used with VMware, Xen, Virtual Server, Parallels, etc.
The second point about Ardence’s shared disks—and how this might compare to VMware’s OnDemand technology— requires more thought. In today's article, we'll look at the shared versus individual disk architectures. Then we'll look at what it will take to enable each of these to work offline.
The importance of shared disk images in VDI environments
It’s certainly true that VMware’s OnDemand announcement was little more than a few sentences mentioned at a trade show, so right now we don’t know too much about this technology and whether it will even support a model where a single image could be used by multiple machines at the same time. So instead of speculating about what VMware may or may not have, I’d like to look at this “shared image” issue in general and highlight some of the architectures that are out there.
One of the main advantages of moving to a centrally-hosted desktop (VDI, DDI, xDI, whatever) is that you can create a single disk image that can be used by multiple computers. (Imagine a single disk image shared by thousands of end-user workstations!) Of course this advantage is also a challenge, because as you know you can’t simply boot 1000 desktops from the same disk image file. You’ll have issues with computer names, domain memberships, SIDs, etc. So to really leverage a VDI-type investment, you need to move beyond the 1-to-1 disk image-to-client ratio.
In order to implement a 1-to-many disk image environment, you’ll need some tricks or software to enable multiple clients to share the one image. There are two basic ways this can work:
- Create an initial “template” disk image. All of your users would have their own image based on this template. Any changes a user makes are saved to their own image. This is known as a “stateful” image.
- Create a “shared” image. All of your users would use this same image each time. Their changes would not be saved from session to session. This is also known as a “stateless” desktop.
Stateless versus stateful: This is the question
Fundamentally you need to figure out if your users need to be able to save their own desktop image each time they’re done working (stateful), or whether you can “reset” the users’ desktops to the initial state each time they connect (stateless). As you can imagine, the stateless image is much easier to manage. (After all, mandatory profiles are MUCH easier to implement than roaming profiles, right? This is the same concept, just applied to an entire disk instead of just one image.)
Unfortunately the stateless image is scary to a lot of people. The thinking is, “What? The exact same image for all users? Impossible! My users need to save their own settings and customize their own desktops.” Even though this stateless image sounds scary, keep in mind that people have been doing this for twelve years with something called Terminal Server! Remember that every single user that connects to a Terminal Server gets the exact same desktop. (After all, not only are TS users connecting to the same image—they’re connecting to the same COMPUTER!) But of course there are ways to let users customize their own desktops. We can use roaming profiles or flex profiles. We can use SoftGrid or Citrix Streaming Server (or ThinStall or Endeavors or Altiris or whatever) to stream applications to users’ desktops. We can use Citrix Presentation Server or Provision Networks Virtual Access Suite or Ericom PowerTerm to deliver icons for server-based computing applications on other servers directly to the users’ desktop.
The point is that even though all users share the same desktop, we can use profiles and streaming and several other technologies to customize the desktop on-demand for each user. This applies to server-based computing desktops and VDI-based desktops.
So let’s say you decide you want use a shared stateless desktop for your VDI environment. How do you physically make that happen? I’ve written in the past that Ardence has a very slick way of doing this. With Ardence, multiple (even thousands) of client computers (physical or VM) can mount the same disk image file over the network. When the Windows instance running from the shared image queries the registry for information like computer name, domain RID, etc., Ardence redirects that request to a central database where it replaces the generic information in the image with the specific information needed by that client computer. Out-of-the-box, Ardence allows thousands of client computers to share a single stateless disk image.
What other stateless solutions are out there? Does any other vendor have a solution similar to Ardence’s where VDI desktops can share a same image?
The closest thing I’ve seen are solutions that manage delta image files. (Or “change” files.) VMware’s ACE solution falls into this category. With ACE, you create one master image, just like Ardence. However instead of deploying that image directly, you run Sysprep on it to prepare it for imaging (just like in a traditional way). Then when VDI or ACE users connect and boot their VMs, they connect to a Sysprep source image that they can then customize for themselves.
One of the nice things about VMware is that you don’t need to have one full image file for each user. VMware allows you to perform “snapshots” of disk images that you can then roll back to. When using VMware disk images in VDI scenarios, the Sysprepped source image acts like a “snap-shotted” image, and each user’s customizations are saved in delta image files. So instead of having a multi-gigabyte disk image on your network for every single user, you have a single master image that is several gigabytes, with each user’s customizations in delta image files that are maybe only a few hundred megabytes.
This master template / delta file method balances the best of two worlds. You get a stateful desktop image without requiring multiple gigabytes of network storage per user. Unfortunately it has some disadvantages too, the primary one being that you now have to manage these as separate images when it comes to patches. Since the delta image files are engineered at the disk block level, if you patch the master template then all the deltas will break.
A possible hybrid solution?
One possible solution to this is for a software vendor to create a template / delta system that was “smart.” Imagine a solution that was kind of like roaming profiles, except for a whole computer. This could capture specific files and folders and changes that users made at the file-level, while still allowing administrators to patch the original template image.
I know several vendors have been talking about something like this. Does anyone know whether it exists yet?
Always connected versus offline use
The initial driver that caused me to write the article about VMware’s OnDemand technology a few weeks ago was that VMware's solution can be used offline. I felt that offline capabilities were something that was lacking in Ardence’s solution, and I sort of hinted that it would be cool if we could see offline support from Ardence soon.
However, the more I thought about it, the more I realized there are a few complexities in the offline use case that would have to be addressed.
First and foremost is the fact that for true offline use, the VM must be able to boot and the user must be able to login without any connectivity. Windows has several intrinsic capabilities here (logon via cached credentials, etc.), so I’m not suggesting this is a show-stopper, but it’s something that would have to be considered.
The bigger issue comes back to this whole “stateful versus stateless” question. In a stateful scenario, the user’s “state” has been saved into their environment (most likely with some form of master image plus delta file). Thus a user could boot and reboot their VM locally without any network connectivity.
However in a stateless scenario like with Ardence, the user state is reset to scratch when the desktop is powered off, and upon booting the user’s environment is dynamically recreated from various elements that require the network (profiles, streaming, etc.). So at least in theory, an Ardence image couldn’t effectively boot without the network.
One potential work-around would be for Ardence to not allow the offline VM to reboot. If it was only pausing and resuming, then it could always resume with the state that was cached locally. Essentially this means the Ardence image would become stateful while offline. Then upon regaining a network connection, the user’s state (profiles, etc.) could be saved back to the network and the locally cached state could be discarded.
Now that I've outlined what I feel are the real issues in the VDI disk image management arena, what do you think is next? Is offline usage that important? Is a stateless desktop possible and worth the trouble? How would you handle patching in a stateful environment?