What jumped out at me in our meeting was the cost per desktop. Based on the number of desktop instances they felt that their "pod" of host and storage could support, the average cost per desktop was about $500 to $600, prior to the actual device that sits on the desktop.
Obviously the device has some bearing on the cost per desktop, but this company was counting on the Bring Your Own Device (BYOD) trend to alleviate all of those costs. However, the company reimbursed for the device brought in by employees, so it really should have been factored into the overall cost. But for now, let's leave the cost per desktop at $500 to $600. I think that cost is still way too high for broad adoption of VDI to make sense.
What Is Driving The VDI Cost Per Desktop?
The key factor that drives up the cost per desktop is simple. How many desktops can you support per host? Obviously 2,000 desktops per host is going to be far less expensive per desktop than 1,000. What is the big limiter to desktop density? Storage -- primarily storage performance, not storage capacity. Capacity issues, assuming your storage has the performance capabilities to handle the dynamic write nature of thin provisioning, golden masters and linked clones, have largely been solved thanks to the efficiency of these technologies.
[ Learn more about this issue. Read How Server-Side Storage Memory Impacts VDI Costs. ]
It is important to note what is not the problem -- processing power. In almost every VDI environment we have studied there is more than enough processing power to increase desktop density. The bottleneck almost always is somewhere in the storage infrastructure.
Storage performance is a problem because the higher the density of desktops the more random the I/O becomes. Also, as mentioned above, in a persistent desktop VDI strategy, the need to handle the dynamic writes caused by thin provisioning, golden masters and linked clones also puts stress on the storage infrastructure.
This puts IT in an awkward position. They can either solve the storage performance problem with an expensive, high-end storage system or stand up more hosts as the bottleneck is reached. The most common is for IT to create "pods" for their VDI rollout. Each pod is a dedicated number of hosts connected to a dedicated storage device. The aggregate use of the CPUs in that pod is rarely above 25% but the storage system is running at full tilt. Adding more "pods" to increase the number of supported desktops becomes an expensive and inefficient solution that increases the cost per desktop.
Ending The VDI Vs. Storage Battle
The answer from the storage community has been to throw flash at the problem. And basically throw flash everywhere: in the server, in the network and on the storage system itself. We don't buy into this strategy of haphazardly applying flash technology, but each technique has an advantage and applying the right technique for your environment can make a significant difference and most importantly bring down the per desktop cost of a VDI infrastructure.
As we saw in our recent lab report "Making Storage the VDI Solution, Not the Problem", where DRAM in the server was leveraged we projected a significant increase in the number of desktop instances per host, a reduction in the shared storage expense and a huge decrease in the cost per virtualized desktop. Based on that study and a few more that are still in the works we suggest that the new target per virtualized desktop should be less than $250 while delivering better performance than what is available to a standalone desktop.
This type of technology makes VDI justifiable from a CapEx perspective in addition to its traditional strength as an operational saver. It also helps VDI make more sense for organizations that traditionally considered themselves too small for a VDI project. We project that a small business may be able to configure a viable 250 desktop VDI installation for less than $150 per desktop.
In my next entry "Are You Delivering The Right VDI IOPs" we will examine the new reality in IOPs per desktop and see if "acceptable" really is acceptable.