With the right equipment (CPU and memory) – previous releases of XenServer like 6.1 are able to run up to 150 concurrent instances of Microsoft Windows and Linux VMs 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 newly released 6.5 SP1 version has climbed yet higher into the stratosphere and is now able to run an amazing 1000 Windows 7 VMs. The next question is always - OK so the system can run these large numbers of VMs - but how many are useful in real-world environments and use-cases?
To answer this - we carry out detailed performance investigations to understand how well the system behaves under LoginVSI loads which simulate a typical knowledge-worker as a desktop (email, browser, apps etc.). In the case of the following test, the workload was a LoginVSI Medium one. We then determine the maximum number of such VMs which can be run like this, whilst offering the end-user really good performance and responsiveness.
- Starting with changes made to XenServer 6.5 - we show here that XS 6.5 can handle 500 VMs with every single one of them performing acceptably. 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. Full details and plots etc. are shown in the article here.
- On top of this - we have now completed the same measurements using XenServer 6.5 SP1. From this, I am very happy to say that 6.5 SP1 is able to run yet more, a lot more. In fact - an astonishing 20% more responsive VMs than 6.5 using the LoginVSI 3.5 workload. It gives a LoginVSI max score of 600 out of its maximum 1000 Windows 7 VMs which we can run on this host.
With a bigger server, we fully expect XenServer to be able to run 1000 with the same responsiveness for full desktop workloads like LoginVSI. The full details and plots etc. are shown in the article here.
We've had an important advisory for users who are trying the new XenServer 6.5 release and would like to use the new Space Reclamation feature (TRIM) on LUNs bigger than 2 TiB as we have found an issue (inherited from upstream) in the original release which might result in data corruption of virtual disks under certain conditions such as high I/O.
This issue has now been fixed so please apply Hotfix XS65E005 as soon as possible which has been released to address this issue. More information is available here Http://support.citrix.com/article/CTX142141
In XenCenter, this functionality is labeled "Reclaim Freed Space" under the host's storage tab.
Note - this doesn't affect other functionality in the product - and is now resolved by applying this hotfix.
A very big thank you for everyone who participated in the Creedence Alpha/Beta programme!
The programme was very successful and raised a total of 177 issues, of which 138 were resolved during the Alpha/Beta period. We are reviewing how the pre-release process can be improved and streamlined going forward.
The Creedence Alpha/Beta programme has now come to an end with the focus of nightly snapshots moving on to the next version of XenServer.
The Creedence Alpha/Beta source code remains available and can be accessed here:
Creedence Alpha/Beta bugs may still be reported on https://bugs.xenserver.org
Work is already progressing on the next version of XenServer and the nightly snapshots are available here:
As this work is new and still expected to be unstable, please do not raise any Creedence Alpha/Beta bugs against it.