With the launch of XenServer 6.2, we’re seeing the realization of many efforts come together, and one of the most significant is that of the performance engineering team. Look for the details of this effort to appear in a blog series next month, but for now I’d like to set the stage for some of what you’ll see.
As I’ve talked with virtualization admins over the years, one topic comes up repeatedly and that’s VM density. Often there is an RFP and on it is a statement reading something like “must support at least x number of VMs per host”.
Far too often, x is something a preferred vendor documents as a configuration maximum, and not something which represents a real deployment density, or which has any basis in workload performance. It also is often a pretty large number, typically in the hundreds.
In the world of XenServer, we’ve always expressed our VM density in terms of “supported number of VMs”. We obtain that number not by looking at what the architecture can support (which is a very large number), but based on actual testing of real workloads on real servers configured under real world conditions. Of course, since we’re talking real world, our “supported” density tends to be smaller than those of our competitors “maximum” density. It also has increased pretty nicely with each XenServer release, moving from 50 VMs per host with XenServer 5.5/5.6 to 150 VMs per host with XenServer 6.1, and now to 500 VMs per host with XenServer 6.2.
In an effort to dismiss these gains, I’ve frequently heard detractors comment that all we’re doing is taking advantage of the capabilities of new processors and server architectures. Now of course we’d be foolish not to, after all an HP G8 is much more capable than a similarly configured HP G7, but this is about understanding the performance of a system and for that you need to more than just buy the fastest server and turn all the knobs to eleven.
What you’re seeing today is the result of years of work addressing things like boot time optimizations, boot storm management, parallel operation management in xapi, network plug time, disk plug time, event channel management, storage management, and network performance enhancements.
For those of you who have been following the architecture discussions around XenServer, and who were looking forward to the improvements our Windsor architecture would bring, it’s important to note that our jump from supporting 150 VMs per host in XenServer 6.1 to 500 VMs per host in XenServer 6.2 came without Windsor. Those gains have yet to be realized, so much more is yet to come, and as with all XenServer releases, it’s important to remember that our VM density number isn’t a hard limit, but what we’ve tested. Your workload mix could yield a higher or lower number.