As a mountaineer, I enjoy getting up high and pushing my limits. I also love doing the same with our software. Much like training for the hills, the XenServer Team has been intensively analysing and making changes to take our new kernel and 64-bit platform to ascend new peaks in the number of virtual machines (VMs) which can be run on a server, and also in ensuring that they’re in good shape when they get there.

With the right equipment (CPU and memory) – previous releases of XenServer like 6.1 are able to run up to 150 concurrent versions of Windows and Linux on a single server. More recent releases like 6.2 and 6.5 have pushed this envelope to the higher and higher altitudes of 500 and 650 Windows and Linux VMs respectively. The upcoming 6.5 SP1 release is looking to climb yet higher into the stratosphere. These configuration limits define the summits of what can be achieved by the software.

In terms of arriving in shape though – let’s have a quick deep-dive into what that means for a VM. For a typical VM – used by a typical knowledge-worker as a desktop – then “being in shape” corresponds to its ability to perform tasks like email, web browsing and other office-data applications. Login VSI is a test workload that is designed to measure this.

To determine what shape each additional VM is in when it gets started – the Login VSImax benchmark is used. It makes measurements within each VM running the Login VSI workload to check how responsive it is. It is used to determine the number of VMs it can run at an acceptable level of performance. To do this, we run such a real-life workload inside many concurrent VMs to emulate a series of typical Windows desktop users.

How much higher can XenServer 6.5 scale than previous releases?

Using Login VSI workloads, and the Login VSImax measure of an acceptable level of performance, we can work out the proportion of VMs that are performing well at such dizzy heights. This reflects the increased ability of XenServer 6.5 to comfortably handle a large number of running VMs. So – it’s a bit like not only being able to get your rucksack to the top – but also having the energy to make use of its contents when you get there.

The following graph shows how the successive releases of XenServer have become better and better at handling large numbers of VMs. The horizontal axis is the number of VMs running the Login VSI workload, the vertical axis is the number of those VMs running at an acceptable level of performance. So when all VMs are running fine, this is indicated by a point on the diagonal. If some number of VMs are underperforming, this is indicated by a point below the diagonal.

The red line is XenServer 6.1, the yellow line is XenServer 6.2 and the light blue line is XenServer 6.5. All measurements were made directly on XenServer with Login VSI 3.5 (medium load).

Taking the yellow points (XenServer 6.2) as an example, you can see that when there are 350 VMs running the Login VSI workload, all 350 are performing acceptably. So far, so good. But when running 375 VMs, a large proportion of them perform less well, and when running 400, almost none of them perform well at all. This is an example of the system essentially collapsing before the top of the mountain is reached (500 VMs in the case of 6.2) – and hence defines a more practical, as opposed to a theoretical, limit. The perspiration stops the system well before its aspiration is reached.

However, the light blue line (XenServer 6.5) shows that it can handle 500 VMs with every single one of them performing acceptably. This is a significant improvement over 6.1 and 6.2 and allows the much higher 6.5 summit of 500 VMs to be reached – with each VM arriving in good shape at the top.

Thus XenServer 6.5 enjoys a massive 40% improvement over XenServer 6.2 in this metric, and a massive 125% improvement over XenServer 6.1.

So exactly what kind of shape is XenServer 6.5 in when running at 500 VMs?

To get a better idea of whether 6.5 is doing this comfortably – or is just crawling to the top – the following graph shows some raw measurements made inside the VMs by the Login VSI benchmark.

It shows the behaviour in two scenarios: XenServer 6.2 running 375 VMs (yellow line) and XenServer 6.5 running a full 500 VMs (blue line). The horizontal axis is the index of the VM the measurement comes from; the vertical axis is the timing that measures that VM’s responsiveness (in milliseconds). Lower values indicate VMs that are more responsive. You can think of this as equivalent to having a low pulse rate after exercise or at altitude.

On XenServer 6.5, it is clear that all 500 VMs are super-responsive, with the timings in each VM remaining well below the threshold of 4000 ms defined by the benchmark. On the other hand, on XenServer 6.2, performance was much less consistent and several of the 375 VMs experienced sub-standard performance. Moreover, at 500 VMs, we are limited only by the XenServer configuration limit of 500 VMs per host: all VMs are within the threshold defined by Login VSI.

You can firmly expect more to come in the XenServer 6.5 SP1 release too – as we’ve been doing more training at these higher altitudes and, due to a raft of changes to reduce overheads and increase efficiencies in the way the system stores and captures data for each VM which is started, we are now working towards delivering power to users at even higher peak numbers of VMs.

Why do we climb mountains?

The benefits of the XenServer 6.5 changes to the core platform have been combined with a tough testing and tuning regimen. The results are a robust, hardened system which not only allows you to go way up into the many hundreds of VMs running on a single host – it can also ensure that each of the steps upward in number of VMs feels as responsive and lively as the last – right to the top configuration limit.

As mountaineers, we often hear the question of why do we climb mountains? In software, we also hear similar questions like “who runs that number of VMs on a host anyway?”

Edmund Hillary’s answer to the first question was that “It is not the mountain we conquer, but ourselves”.

To me, the answer to the second question is similar.   It’s not the number of VMs which matters ultimately, it’s the understanding of our system which is important.   That is – if our hypervisor solution can climb its own equivalent of Everest –  in the number of VMs which it can run – and do it by treading as lightly, efficiently and comfortably as the new versions of XenServer can – then it’s also going to be capable of absolutely awesome hiking in the lower hills of our data-centres, not to mention being fully ready to ascend with us into the Clouds.

Preliminary numbers for XenServer 6.5 SP1  are even better than 6.5 above and we will be publishing those and post a new blog in the next few weeks when all the cross checks and validation is complete. Onwards and upwards.