I have been doing quite a bit of work lately on Desktop Virtualization, obviously with VMware View. As a number of analysts and non-analysts had predicted, 2009 is definitely the year that desktop virtualization is taking off. Partially because of the technology has reach a level of maturity where it is usable for most use cases and partially driven by the cost savings potential that it can provide. As I have indicated in previous posts, there are real conversations happening within corporate desktop IT discussing getting rid of corporate owned laptops or desktops all together.
While reading Chris Wolf’s descriptiong of the demo he saw of PCoIP at VMworld in Europe, it struck me that the sizing metrics used to describe dekstop virtualization tend to vary. Chris mentioned in his post:
“…with a virtual desktop consolidation density ranging from 30-60 VMs (densities commonly found by our clients piloting or running VDI today).”
While there are times when we need to simplify measurements to keep complexity in check, it can be misleading to talk about virtualization densities without mentioning the units for that density. I’m assuming that Chris was referring to VMs per Server, that would make sense given the number.
I would have to argue that this is the wrong unit to use for desktop virtualization, the proper unit that should be used for desktop virtualization density is VMs per Core. As the number of Core’s per CPU socket keep increasing and as the size of servers, measured in number of sockets, keep increasing in the data center we should be measuring virtualization density in VMs per Core. This is the best metric to guage technology advancements against.
When talking with my customers about VMware View deployments, we are always talking about the density in VMs per Core and cost of solution per desktop for a given use case (common population). The cost can be impacted by playing around with how you package those cores in the data center. As long as the server can contain as much memory as needed by the total number of VMs your golden. And the memory limitations won’t be as great of a limitation for much longer.
The use case is the other key aspect. When looking at a desktop virtualization solution, I have found that you need to keep the solution contained to a single use case which describes a single virtual desktop size. Call center desktops have their own unique size (hard drive space, memory, and hard drive usage) while a knowledge worker desktop has a different unique size. Each use case’s different size will impact the costs and ROI/TCO model.
So, when analyzing virtual desktop solutions, keep in mind your sizing metrics and keep your use case scopes focused. Like any solution, desktop virtualization should be taken in bites and these two suggestions will help keep in that task.
Good post, Greg. I agree with your comments on sizing. In my post, I had made assumptions on server platforms and should have stated them explicitly. I was assuming 8-16 cores in the 30-60 desktop VM consolidation density range. VMs per core is abosolutely how density should be judged. This is also why I think eventually we’ll see hypervisor platform licensing based on physical cores, since it’s the easiest and most accurate way to way the value of a virtualization software license. To be clear, I’m only condoning this model for the software that runs on the metail (i.e., the hypervisor and supporting services such as high availability). Software running inside VMs should have absolutely no ties to the physical hardware.
[Reply]
latoga Reply:
March 9th, 2009 at 10:41 pm
I completely agree with you that per core pricing is the only thing that makes sense for the hypervisor and related management technology layers. It still kills me that so many ISVs don’t understand how to license appropriately for virtualized environments (both the big ones that always come to mind as well as small ones). But, as one VP of Data Center Strategy commented in a recent meeting “If they don’t support it running in a VM, good for me! Because I’ll run it in a VM, not pay support and save myself a bunch on maintenance.”
[Reply]