Over the past several months, literally hundreds of people have asked me the question “When will Tampa release?”  I am pleased to announce that earlier today, “Tampa” officially reached GA as XenServer 6.1.  Within engineering, this is officially considered a “cloud centric” release.  While on the surface that would seem to indicate a lack of features for traditional server virtualization and desktop, but the reality is quite different.  When you consider that a cloud runs in a datacenter, and that cloud workloads typically translate into some pretty large VM densities, all with a requirement for a high degree of workload isolation; “cloud centric” actually translates into a set of pretty stringent performance requirements.  To illustrate the point, let’s consider three key features, live storage migration, network security and VM conversion.

When you look at some of the most successful clouds, you’ll quickly see that the concept of resource pools are somewhat limiting.  Regardless of the size of the pool, if your cloud is successful, eventually you’re going to have more customers than can fit in your cluster or pool.  During the design phase for Storage XenMotion, we accounted for this with the result being a shared nothing live storage migration solution which works equally well across all storage types and without being confined to an arbitrary resource pool concept.  While designed for the cloud, it fully supports enterprise storage management requirements, and even supports live VM migration between local storage for those cases where shared storage wasn’t implemented.

This same philosophy was used for the network security and performance improvements which include everything from LACP 802.3ad, 4 NIC bonds and IPv6 guest support all the way down to switch-port locking to prevent MAC and IP spoofing.  We even went as far looking at the amount of time is takes to create large numbers of VLANs and improved upon that by a few orders of magnitude.

Lastly we took a look at one of the more interesting trends today, and that is cost containment of vSphere implementations.  Despite the various pricing changes VMware has made, the reality is that VMware focused attention on the cost of their virtual infrastructure and that companies are looking at ways to contain the cost of leveraging vSphere.  This really boils down to leveraging vSphere for its strengths and when vSphere isn’t really needed, looking to an alternate platform.  Since XenServer is often that alternate platform we created the XenServer Conversion Manager to seamlessly batch convert vSphere VMs to XenServer.

To learn more about XenServer 6.1 I invite you to: