Talkback
E-mail
Printer Friendly
Reprints
Xen has had a relatively rough road since it began as a research project at the University of Cambridge. Early releases of the open source virtualization package were quite buggy, yet highly touted by major players in the Linux field, which has led many to view the project skeptically.
|
|
Initial packaging of Xen into Fedora Core 4 and 5 releases didn’t help matters when it became clear that it was at best difficult to run and at worst simply broken right out of the box. Later releases have made significant usability and functional improvements, and the next release will officially include support for Windows guests, but it still lacks the comprehensive management framework offered by VMware. Make no mistake: Xen works, but it’s is still in its infancy as an enterprise virtualization solution.
Demonstrating Xen’s enterprise potential is Virtual Iron 3.1, which, as do XenEnterprise and Enomalism, seeks to leverage the open-source model to provide a viable alternative to VMware at a significant cost savings.
Before turning to Xen, Virtual Iron had spent two years developing a homegrown hypervisor technology aimed not at consolidating many virtual servers onto a single physical server, but allowing a single virtual server to run across multiple physical servers. Although this was certainly a worthwhile concept, the pace of processor development and the progress of clustering technologies were beginning to render this concept outdated before it even matured.
Pumping Virtual Iron
The upcoming release of Virtual Iron 3.1 lacks many of the advanced features of VMware’s Virtual Infrastructure Server 3,
but it does showcase that VMware’s competition is not terribly far behind. In some ways, in fact, the competition is actually
ahead: Virtual Iron 3.1 supports as many as 16 CPUs and 96 GB of RAM per virtual machine, compared with VMware’s current limits
of four CPUs and 8 GB of RAM.
 Click for larger view. |
Virtual Iron 3.1 is a pure Java application that can find a home on a Windows or Linux server, and it ships as a binary GUI install wizard. The setup is minimal, and this first-built server is the equivalent to VMware’s VirtualCenter with one important difference: It serves as the host server deployment system as well as providing the management tools.
When installing Virtual Iron 3.1, it’s recommended to build the server with several network interfaces. One of these NICs will become a management network that should be constructed as an isolated network segment between all virtualization host servers and the management server. This is because by default the Virtual Iron 3.1 server will act as a DHCP/PXE boot server, making deployment of virtualization hosts generally as easy as turning on a new server on that segment.
When the hosts PXEboot, they run a highly modified Linux kernel and no console, so there’s no need for any KVM on the server, because there’s nothing to see and no way to access the system other than through the Virtual Iron management console. Disks local to these servers are available, as are any NICs and HBAs that are supported by the Virtual Iron kernel. In the testing I was able to conduct in Virtual Iron’s labs, this included Emulex and QLogic 2Gb FC (Fibre Channel) HBAs, SATA, and SCSI disk, and Intel and Broadcom NICs.
Paul Venezia is senior contributing editor of the InfoWorld Test Center.
