In my experience, the main component that drives VDI costs up is the supporting storage infrastructure. If storage can be made to perform significantly better and still remain cost effective, the CapEx costs of a VDI solution would come down. As I covered in my original column, intelligent caching is one way to accomplish this.
My analyst firm, Storage Switzerland, recently was hired by caching software manufacturer VeloBit to run a lab test and potentially verify their product claims. My original column was not about any particular vendor, but more about the importance of reducing CapEx and the effectiveness of caching as a method to drive down the cost of the storage components of a VDI project. I did, however, link to that report as an example of our research.
[ Want more on VDI's increased acceptance? Read Is Storage Saving Virtual Desktop Infrastructure? ]
The first of Art's concerns was how "real world" our tests were. That's a fair concern of any lab test as, obviously, no test can perfectly recreate a production environment. All you can do is accurately document the test methodology and the configurations that you tested. Users have to translate that into their reality. We learn something from every test we do and attempt to apply that to our next test suite.
The second concern raised was that we used non-persistent desktops. We acknowledged this and stated that we will specifically test both persistent and non-persistent desktops in the future. That said, based on what we saw, I don't think the use of non-persistent desktops would significantly change the overall efficiency, but we will need to verify that through separate testing. Clearly the desktop type is something that the reader should factor into his assessment, but the level of improvement from technologies such as what we tested can't be ignored no matter what type of desktop is eventually chosen.
We wanted to test both desktop types because that would have been an interesting comparison and because it's a choice that VDI project planners routinely have to make. But this time we simply didn't have the time to get both tests done and compiled for this particular report.