Brian Madden posted a topic the other day that addressed a concern by one of his readers about styles of provisioning VDI. Essentially Brian talked about thin provisioning (and the need/problem of data deduplication) versus non-persistent shared disk images and how he wishes some day we could get to a shared image/layering concept someday. The full entry is here.

Since Brian doesn't seem to think that anyone but VMware and Citrix or a small handful of  niche startups merit his attention, I felt the need to chime in on their thread to try and bring some accuracy and reality to the discussion.

The following is my response (with contributions from Leo Reiter, Virtual Bridges CTO)

There are a couple of things that bother me about the way this topic is presented.

1) The claim that "In the early days of VDI, everything was done with the persistent 1-to-1 images." is just plain wrong. If we could ever get Brian to keep one of the appointments he's asked for with Virtual Bridges he would learn that our VDI solution predates VMware's by several years and our architecture always employed stateless, gold master sessions coupled dynamically with a persistent user data image

2) The second thing is the conclusion that "this whole single-image / shared-image / layering concept, while great, is just not real today." Hello. See above. Right here. When will people start expanding the conversation beyond VMware and Citrix? Thankfully, IBM gets it. And, so does Austin Ventures who are now the backers of Virtual Bridges.

To elaborate on some technical points:

1. deduplication is a hack for needing duplication in the first place, which is an element of really bad design; despite the slickness of deduplication technology it is complicated and expensive, and is only a patch for the problem - you still need to manage separate stateful images which is no different than managing individual PC's, and therefore a non-starter for any serious VDI implementation plan.

2. delta files are also a bad approach, because they need to be thrown away when the master image is updated, and again are a patch for a bad design (see #3)

3. VERDE separates user and system data in virtual desktops of any type (Windows XP, Windows 7, Linux, etc.), therefore the "deltas" are persistent across gold master updates (this has been proven over 5 years of field deployments).  Also, the system administrator assigns a cap to the size of the user "image" for each gold master deployment ahead of time, so there is no such thing as a "runaway" delta file - you plan for the peak storage you will need (see #4), and this method is better than roaming profiles for various reasons (see #5)

4. requiring expensive SAN for VDI is both a myth and an artifact of poor early (and some current, such as View) VDI implementations. VERDE uses NAS for shared storage and connections are limited to just the servers themselves - there is no 1:1 VM->storage requirement.

5. roaming profiles vs. VERDE user persistence technology - VERDE wins here for various reasons:

     a. roaming profiles are a practice many organizations refuse to consider (this is based on talking to customers for years, not conjecture or surveys)

     b. roaming profiles typically carry a long log-in time than local profiles - sometimes much longer (measured in the 1 minute+ range in some cases)

     c. roaming profiles only work for Windows virtual desktops, which of course is fine and addresses most of the market, but encourages lock-in for the future     (like when Linux desktops become more and more useful to Enterprise in the years to come); limiting vendor lock-in at every level possible should be an important consideration for forward-looking organizations deploying VDI today

     d. roaming profiles are vulnerable to VM crashes and user aborts because you have to log off completely in order to have your data preserved - VERDE overcomes this by writing user data to persistent disk much more frequently

     e. even if roaming profiles are used, the VERDE mechanism still helps to greatly speed up logins because some per-user local persistence remains to keep the login process reasonably quick; most of the penalty of domain logons (which are typically required for roaming profile use) is creating the initial user profile bits that are assumed to be persistent - if these bits are not there, they are created each time and a huge time premium is paid; VERDE preserves these bits between logins to eliminate most of the overhead

     f. with or without roaming profile use, the VERDE mechanism provides additional per-user persistence that can be used by scripts and/or custom applications to improve the user experience or automate IT processes - this is the per-user space you get "outside roaming profiles"

In summary, VERDE marries the benefits of thin provisioning with a far superior management model that enables centralized updates without sacrificing per-user persistence, and without runaway storage requirements and costs.