A deeper look at VMware's upcoming "View Composer" VDI disk image sharing technology

At VMworld last month, VMware announced several future capabilities of their VDI product. Yesterday we looked at VMware's bare-metal hypervisor, and today we'll look at the technology that will allow multiple VDI VMs to share the same disk image.

At VMworld last month, VMware announced several future capabilities of their VDI product. Yesterday we looked at VMware's bare-metal hypervisor, and today we'll look at the technology that will allow multiple VDI VMs to share the same disk image. This will be done with a new product that will be called "VMware View Composer." ("VMware View" is the new name for their VDI product, so "View Composer" is what you use to compose your disk images. Get it?)

This is similar to Citrix Provisioning Server (Ardence), and another one of the core requirements outlined in the 2010 VDI+ vision. (Super-fast explanation: VDI is about desktops. If you want to convert all your desktops to VDI, fine, but you sure as heck don't want to manage hundreds or thousands of images. So if there was a way for multiple VDI desktops to share the same image, then this whole VDI thing would be a lot more feasible. This is what View Composer does.)

Those of you who are not too familiar with VMware's current VDI product might be surprised to learn that it doesn't actually have this feature today!!?! In other words, if you want to use VMware VDI for 100 desktops, you have to create 100 disk images! This is bad because:

  • The actual cloning process takes several minutes per VM, so it could take all weekend to provision the images you need for your whole environment, and you certainly can't do it on-demand.
  • The storage requirements are stupidly huge: you need the full space in your SAN for all disk images combined.
  • Huge storage requirements equal huge storage costs. (This is not a bad thing if you're owned by a storage vendor though.)
  • Once you clone a desktop, that's it, you're done, the clone is separate from the master. If you need to apply a patch, you need to either (a) patch the master and re-clone everything the next weekend, or (b) patch each of the clones individually.

This is obviously a huge negative of today's VMware VDI product, and it's one of the aspects that's really holding it back from wider adoption. So VMware's announcement that this View Composer thing will let multiple VDI VMs share the same disk image is a very, very cool thing. From a very high level, here's how View Composer will work:

  1. You build a VM disk image that you want to use for your master.
  2. You use the View Composer management thing to make a full copy of that master that will be the base image for multiple VDI instances. (They wanted to make this a separate process so that some uneducated admin using VirtualCenter didn't blow away the master image and instantly screw thousands of users.)
  3. You then assign that single master image to multiple VDI instances or users or whatever.
  4. Then when a new VM is needed (either on-demand or in advance), a new very small "diff" ("delta"?) file is created.
  5. The VM mounts the disk, which is a combination of the read-only master plus the read-write diff image.
  6. All changes / writes / etc. are written to the diff file, which grows over time.
  7. When the VM is shut down, you can choose what happens to the diff file. (Throw it away, save it for the user for next time, etc.)

Interestingly, this technology is not too fundamentally different than the checkpoint / redo / delta disk image structure that VMware's had in place for years. (Heck, even VMware Workstation 5 had linked clones back in 2005.) They also like to point out that View Composer is not the vStorage Link Cloning feature per se.

What makes View Manager different is that VMware is packaging and customizing this technical capability specifically for VDI instances. In fact, they even did a lot of research figuring out how Windows XP and Vista interact with the disk and how that can be minimized. (Disable the automatic book disk optimization defragging, put any user data that needs to persist in its own partition, etc.)

While the two primary advantages of View Composer are the ability for multiple clients to share a single image, and the massive reduction in storage space, a [bonus] advantage is that there's potential for significant performance gains, SAN-wise. Current VDI environments can see about 20-30 desktop VMs per LUN, but since a View Composer environment would have more machines sharing the same bits on disk, VMware's thinking that number could surpass 60 VMs per LUN. (I guess it's worth pointing out that this advantage, as well as the storage space reduction advantage, could both be addressed today with the de-duping capabilities of a SAN, but that's typically an even greater expense on top of what's already ridiculously expensive desktop storage.)

How will VMware handle multiple Windows machines sharing the same personality?

Simple: they won't.

You know you can't just copy copy copy copy a single Windows disk image and deploy it to multiple computers on the same network. You'd run into problems with conflicting computer names, SIDs, etc.

Citrix Provisioning Server solves this problem by creating a database and then injecting certain machine personality into the image on the fly. VMware View Composer will do basically the same thing via a process they're calling "Quick Prep," (although I'm not sure whether that's the final name).

The idea with quick prep is that when a VM boots, it can mount the master disk image with the newly-created, yet completely blank, read-write diff file. A VMware component running within the VM would ensure that when it looks to the disk for the SID or whatever, the request is sent to a database which provides the proper data. The VM can then write these settings to "disk," which would of course be written to the read-write diff file (which is now not as small as it was a moment ago). This whole process should be fast enough so it can be done on-demand.

After running a VDI environment with View Composer, you'll end up with a bunch of clones. You can choose to delete the clones in several ways:

  • When the user logs off. (This would make your VDI environment the most like terminal services, since the user would get a "new" image each time he or she logged in.)
  • When the diff disk image clone grows past a certain size.
  • After a certain amount of time has past.
  • Manually by administrators.
  • Never.

A final word on View Composer: VMware hasn't specifically announced any intentions to do anything around user profiles. To use their words, they hope to "play nice" with the profile vendors, and to let them innovate on top of the structure that they're creating. While that sounds noble, it also is a bit at odds with the longer-term vision that VMware CEO Paul Maritz outlined in the VMworld keynote, namely, that VMware wants to focus on deploying a personality to a user, not to a device. Certainly View Composer goes a long way in centrally managing desktops, but I wouldn't be surprised if VMware does more in the user personalization space in the future as well.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Taken the fact that untill recently VMWare had no clue about desktops, you would expect them to buy some knowledge\technology to make this happen. Any ideas about vendors they would need to approach?
expensive too !
How will patching work? Seem like there would be challenges if you let users keep thier diff/clone.
I was wonodering the same thing. Presumably most system patches will be applied to the core and dynamic generation from the image means everyone gets the patched core next time they ask for a session; but surely there are likley to be elements of the diff flies tha needs to be patched too? How does the system inject the changes into all existing diff files; or do the diff files have to be dumped and recreated? Doesn't sound like a recipie for happy users....

Great Question! This was something I meant to address in the article that I kind of forgot about. From the high-level, Ewen is right. You patch the master image. Of course since the diff files are block-level images, changing the image invalidates all of the diffs. If you really need to keep persistent data in a diff file, you can instead redirect that out to another disk image file that contains data-only that would not be affected by the master getting rebuilt.


This is a critical question.  With Provisioning Server I can patch, add programs, rool back, etc. and the windows identity remains intact.  If View Composer is truely just a repackaging of the existing technology, then this is a problem.  For example, if I snapshot a VM (or make a linked clone), I can make several derivatives of it.  If I go back to the base and make changes, it makes another branch, but then new version is the only one that sees the update.  This is because the other variations are pointing to a pre-updated state of the disk.  Until now at least, you could not modify the reference disk that the other varients are pointing to or it would invalidate the pointers.  I'd like to know the answer to this as well.

User personalization and patching go hand and hand with this approach. There are a couple of ways this can be addressed. With patching we provide the capability to recompose the images. Create a new snapshot of the master, add the patches and redirect users to the updated image. This provides a roll back feature as well. It’s also granular in the sense it can be done per user / VM instance, scheduled etc. To address user settings, apps etc. several approach’s can be taken to ensure the user environment is contained and restored. You can use our user data disk, our user data disk with a profile virtualization solution, or just a profile virtualization solution. With each approach there are pros and cons and considerations that should be taken into account. We are working on a white paper detailing several use cases and each approach that we will make available when the product is released.

You must have answered as I was responding.  Does this means that if there are 10000 desktops, when a patch is released, 10000 objects get removed and 10000 new objects get added back in to AD?  If there is a problem and you need to roll back?

This is a load of crap by Vmware all there doing with these future announcements is putting companies off potentially buying an alternative product.

When creating the VDI session (VM) for users you can designate a seperate vdisk for the user's profile (personality vdisk).  When the user logs onto their VDI session, VDM merges theses vdisks together.  This is the delta file from what I understand.  You can not use vclone technology with offline VDI, since it requires the full vdisk. 

Also price for the existing VDM solution isn't all that bad.  The architecture of PVS and VDM with vclone is completely different.  Plus I can use PVS to boot desktop/servers, I can't do that with VDM.

Still at the end of the day, VDM 3.0 is still a welcome upgrade to the 2.1 version. 

Seriously? So do you think that companies shouldn't announce future plans? In the past, people have accused companies of being too secretive by not talking about the future, and now that companies talk about the future you're complaining again?
Regarding objects being removed and re-added to AD, no, it wouldn't happen like that. This is what that database will take care of, so the AD personality will stay with each "clone," even if the clones are blown away and rebuilt on-demand each time. This is just like Citrix Provisioning Server.
Good point brian never thought of it that way kudos :)

Thanks for clarifying.  It would be interesting to see which scales better. I can see arguments for both.  It is good to see that PVS may eventually have a competitor.


Quoting a very knowledgable industry expert - "Buy a VDI solution that does what you want now, not next quarter" :-)

It's still pretty cool....


Can much of this already be achieved with the VMWare Lab Manager software, especially if you are looking at the "new image each time" scenario?

If not what are the major differences. 

Actually the new version of VDM uses the linked clone ability that comes from Lab Manager.  With that said, Lab Manager is not a VDI solution.
Any word on how this performs as more and more clones are added?  Surely every linked clone must frequently reference the master, and if so, having 100/1000/10000 links will kill performance?

Just wondering - how is VMWare's View Composer different than NetApp's FlexClone?

Can somebody confirm this whole Flex Clone technology only works with NetApp FlexVol storage?

Let me rephrase the question

Can somebody confirm that VMWare SVI/View Composer only works with NetApp FlexVol enabled storage and does not work with any other storage?

Incorrect, SVI works on other SAN's not just NetApp.  Again, it is just linked clones.

When I use SVI for say 10 desktops, does the hypervisor see what appear to be 10 different vmdk files, each one stand alone by itself?

Or does the hypervisor see 11 vmdk files, consisting of 10 differencing vmdk files and 1 parent linked to all 10 differencing disks?


Vmware has always put Citrix down. I just find it funny that at VMworld, they attacked almost everything Citrix does, but yet they come out with products that mimic exactly what Citrix has been doing. People have to get away from VMware as this company that can do no wrong and all products are golden. While it is very true that their hypervisor was cutting edge and an industry changer, people have to keep in mind, that most of the other vmware products are really just thrown together. They are not based on proven technology. I have been constantly hearing about this View Composer and how its going to be so great.... Citrix provisioning server ( previously Ardence ) is an established product with hundreds, if not thousands of customers having deployed it sucessfully. People have to stop drinking the vmware koolaid and start looking at PROVEN tech. FYI, Citrix provisioning server can work with vmware hypervisor. Now if you want to use VMware hypervisor, Citrix Provisioning server, and XenApp on your VDI solution, now I think you have best of breed.

One Question, will this vmware product give the ability to boot an image to VM as well as hardware?


If you are looking to resolving user profile issues for VDI users, I would look at using RTO Software Virtual Profiles as spoken about at VMWorld 2008 by John Dodge during his session on VMware Virtual Desktop Infrastructure Design


Nice work VMware - only took you about 2 years to catch up to Citrix.  By the way - the best of breed VDI solution is XenDesktop (ICA) + Provisioning Server (standard mode images) + ESX.  Period.  Let's all admit it and get on with our lives.


Completely agree with that combination XenDesktop, PVS, backended by ESX.


Hmm.."only took you about 2 years to catch up to Citrix"

Funny, you are talking about XenDesktop that was released in June this year, 6 months ater VMwares VDM2 product?

Provisioning server is OK but with volatile images only supported, and
requirement for physical servers to stream its not perfect. Its great
to se new options being added to VDI solutions and I will hold back
judgemen until the VMware solution is released and I can get my hands
on it to test.

Warren, you mention a profile virtualization solution to handle this and we already had a solution that fit this issue.  We were an open source user of Script Start and just upgrated to Script Start ProfileUnity because they now enable you to store your profile seperate from the desktop session.  We migrated many of our traditional desktop users to VDI this way and will look at it in relation to VDM 3.0 because it solves the same issue.
The more I use PVS, the less I like it...I actually think is was better BEFORE Citrix bought them.  Until someone (MS) can figure out Setting the TS path is session0, I think Standard images have a very small use case scenario and that small use case still makes Terminal Server a better solution (just my no-name $.02 opinion)  Without it your forced to go third party for Profile Management which is why I'm sure Citrix bought Sepago.  Most people think offline VDI is next big hurdle to jump...I still think there are hurdles to jump with online VDI.
Um....FlexClone exists VMWare Composer doesn't?  As far as only working with NetApp...its just linked clones so any storage should work.
Are you kidding? XenDesktop is a thrown together make-it-to-market product. The only thing that makes them special ICA and Provisioning Server. Provisioning Server can be integrated with any VDI solution. And Quest is taking a serious chunk out of the ICA argument. Take your head out of the ground and pay attention.
Provision Networks has hybrid profile mangement built into their product. Has for years.
From my experience pilotting various products in various combos, I agree that technically this is best combination I've come across, and it's what I'm recommending to customers. However it's certainly not very efficient cost-wise to run ESX backend with a Citrix VDI solution. XenDesktop licensing includes XenServer, and last time I looked ESX with VC licenses including all that good stuff like HA and DRS doesn't come cheap. Alternatively, if you already have ESX with all the bells and whistles, VMWare will generally package their VDM solution for a LOT cheaper than investing in XenDesktop. In reality, techos don't get to make all the choices, there's still a budget to fit within!
It is a private beta, now in RC for the beta team.

It's true that Provision Networks has had User Profile Management for Terminal Services for several years, but Quest vWorkspace 6.0 (the next release and new name) is the first release that includes this functionality for virtual and physical desktops.