Virtual Iron Standardizes on Xen, Goes Open Source

Published: April 3, 2006

by Timothy Prickett Morgan

If you can't beat 'em, join 'em and emulate 'em. While Virtual Iron has some of the most sophisticated server virtualization technologies ever developed, what seems clear to most observers is that while VMware's closed source hypervisor inside its VMware Server and ESX Server products got a very early lead on the rest of the industry, the open source Xen hypervisor is probably on its way to be a rival standard if not the de facto standard in a few years as the hypervisor goes from oddity to commodity.

And so, at LinuxWorld today, Virtual Iron will announce that it will standardize on a specific kernel developed by the Xen community--a kernel that is has been contributing to for several months--and will create open source and commercial variants of its Virtual Iron extensions to that Xen hypervisor as a means of building up its own community and getting software licensing and support fees to pay its bills.

Virtual Iron, like Xen, burst onto the scene after being in stealth mode, a year ago at LinuxWorld. Unlike VMware, Xen, and other virtual machine partitioning environments that could dice and slice a single server into pieces, Virtual Iron's VFe product, which is now called simply Virtual Iron Version 3, was the only one that could do this and additionally glom together multiple servers connected by an InfiniBand switched fabric into a single virtual machine. Of course, using VFe required a distinct set of kernel modifications, which had to be grafted onto Linux. Earlier this year, Virtual Iron and Novell announced that the latter would ship a VFe-capable kernel as an option in its SUSE Linux Server 9 SP3 distribution, and Virtual Iron had been working to get its kernel mods into Red Hat's distributions, too.

VFe 2.0 and Virtual Iron Version 3 can make a partition as small as one-sixteenth of a processor core or as large as 16 processor cores; the only limit is that the combined maximum number of virtual machines that the VFe hypervisor can manage is 128 partitions, which was delivered with VFe 2.0 in October 2005. The Virtual Iron VFe software doesn't just virtualize processor partitions, but has built-in SAN and network virtualization technologies, too. For a true virtualized infrastructure, you need to virtualize processor, memory, and I/O, which is why VFe does all three. In August 2005, Virtual Iron announced that its VFe software would eventually manage partitions created by the Xen hypervisor, and the company began working on support for Intel's VT and AMD's AVT hardware-assisted instruction set virtualization technologies.

That was then, and this is now. With Virtual Iron 3, the company is tossing its own VFe kernel out the window and opting for the Xen tweaks to operating system kernels. Alex Vasilevsky, co-founder and chief technology officer at Virtual Iron, explains that there are actually three Xen-capable kernels of interest, and Virtual Iron is picking only one of them. There are 32-bit and 64-bit Xen kernels that use so-called paravirtualization approach, where instructions that cannot be or are not virtualized by hardware are replaced by APIs in a modified operating system. This is obviously not a very attractive option. But, luckily, there is a Xen hypervisor variant called HVM (short for Hardware Virtual Machine), which was contributed by IBM Research last year and is used primarily to provide a consistent interface to the VT and AVT features in the Intel and AMD processors. Virtual Iron will from this point out focus on the HVM variant and wrap all of its code around that. Vasilevsky says that this hypervisor represents about 40,000 lines of code, and that when Virtual Iron joined the Xen community about five months ago, it started contributing code to this part of the project to get its software and the Xen hypervisor in synch. His pointing bringing this up was to show that in an environment that assumes VT or AVT is present, the hypervisor is nothing you can differentiate with.

Virtual Iron does, however, believe that it can differentiate and perhaps even dominate by wrapping around Xen--and maybe even VMware and Virtual Server--hypervisors and giving them a consistent management interface as well as extending their capabilities. "We firmly believe that Xen will be one of the hypervisor standards," says Vasilevsky. "So we did an engine swap, but we are going to keep all of the rest of the car that surrounds it."

Another good thing that Virtual Iron has done is break free from InfiniBand interconnection for virtualized servers. With Virtual Iron Version 3, any high-speed interconnect, which means Gigabit Ethernet and 10 GigE for companies with lots of money, will also work now, too.

However, by using Xen HVM exclusively, Virtual Iron is requiring customers to move to new servers with chips that have VT or AVT electronics in them. The company again believes it is making the right choice. "Would you rather have to upgrade and recertify you operating system and software stack, or would you rather roll in a new server?" asks Mike Grandinetti, Virtual Iron's chief marketing officer. Good question, and many companies would rather buy hardware than mess around in their software stack. "This is a tradeoff we think customers will make, especially considering that they do hardware refreshes a lot more frequently and a lot quicker than they do software updates."

Picking Xen as the engine is not the only thing Virtual Iron will do today. The company is also releasing its own code as an open source project. When Virtual Iron 3 begins shipping later this year, the base product will be available as open source code through its Web site. The base product will be called Open Virtual Iron 3 for Xen/Community Edition, and it will be distributed under the GNU General Public License. This product consists of the Xen HVM hypervisor, and a stack of software collectively called Virtualization Services, which provides the virtual storage and networking capability that was formerly in VFe as well as virtual server resource management, logical partitioning, hot-plug processor and main memory, LiveMigration partition transportation facilities, and a number of other features. The Community Edition of the product is intended to be used by members of the Xen development community. Companies will want to play with and deploy Virtual Iron 3 for Xen/Professional Edition, which is a compiled version of the stack that is free and that includes support for partitioning and managing a single server. Virtual Iron 3 for Xen/Enterprise Edition is where the company will make money, since this edition will include the closed source Virtualization Manager, which has Web-based tools and policy managers for provisioning and moving around partitions in a Virtual Iron configuration. This product will not be free, and is expected to cost $1,500 for a single physical server.

Virtual Iron 3 for Xen will start beta testing on the Linux platform in July, and will start testing on Windows in September. SUSE Linux Enterprise Server 9 and Red Hat Enterprise Linux 3 and 4 will be supported initially, with SLES 10 and RHEL 5 support coming as those products get to market later this year. On the Windows front, both Windows 2000 Server and Windows Server 2003 will be supported. Like XenSource, Virtual Iron is banking on the fact that Red Hat, Novell, and Microsoft will not want to support each other's operating systems when they support Xen or Virtual Server hypervisors, respectively. "Red Hat and Novell will support their own distributions, and they are not going to be motivated to support Windows," says Grandinetti. "All I know is that we will be the first company to ship a commercial version of Xen into the market--no patching, no compiling." This software will, thanks to VT and AVT features on the X64 chips, run unmodified Linux and Windows code--which is what most companies really want to do.