With its ConVirt Enterprise 3, Convirture helps IT organizations put to work the virtualization capabilities present in all modern Linux-based server operating systems. The product, which I reviewed in its version 2 form last year, plays a role similar to what VMware’s vCenter plays for its ESX hypervisor hosts, but at a lower cost.
New in version 3 is a set of capabilities, called ConVirt Enterprise Cloud, for building pools of ConVirt-managed hosts into private clouds. IT departments can divvy their virtualization resources into virtual data centers, each with its own set of available virtual machine templates, resource quotas and segregated networks. Administrators can create accounts on these separate clouds and give users access to the resources through ConVirt’s Web-based console.
What’s more, administrators can yoke their ConVirt management environment up to third-party clouds based on Amazon Elastic Compute Cloud (EC2), OpenStack or Eucalyptus, and apply the same resource and access controls to these clouds as to those running on their ConVirt-managed hosts.
I tested ConVirt Enterprise 3 and ConVirt Enterprise Cloud with CentOS-based virtualization hosts running the Kernal-based VM (KVM) hypervisor (the product also supports Xen hosts), with Amazon’s public EC2 cloud and with a private cloud based on the OpenStack project.
As a lower-cost alternative to vSphere, ConVirt is certainly worth IT consideration. Pricing for ConVirt Enterprise 3 starts at $1,495 per host for up to 10 hosts, with volume discounts available. Factoring in the license costs for an enterprise Linux distribution, a ConVirt solution comes with a significant cost-savings. ConVirt supports Red Hat Enterprise Linux and CentOS, with support for Ubuntu and SUSE Linux Enterprise Server on the way.
However, ConVirt Enterprise is definitely rougher around the edges than vSphere; for one thing, support for multiple-host operating systems and hypervisors results in a less tightly integrated system, with more under-the-hood tweaks required than a vSphere plus vCenter match-up.
The cloud-building functionality in ConVirt Enterprise Cloud is simpler to configure, particularly with third-party clouds, which requires little more than entering one’s cloud service credentials to get up and running. With that said, my tests of the cloud features weren’t without snags, either. For instance, I hit an issue (a known bug, according to Convirture) getting OpenStack templates I created after configuring my OpenStack cloud to show up in the ConVirt VM templates list.
ConVirt Enterprise Cloud is sold on a yearly subscription basis, and the price is keyed to the number of sockets used in an organization’s on-premises infrastructure. The price starts at $487 per socket for up to 20 sockets, with discounts for larger numbers of sockets. At this point, use of EC2 in the Enterprise Cloud product does not carry any additional costs.
In addition to its Enterprise editions, ConVirt 3.0 is available in a freely downloadable, open-source version, which lacks the high availability, backup, storage and networking automation, and cloud management functionality included in the Enterprise editions of the product.
ConVirt Enterprise in the Lab
I tested ConVirt Enterprise on a pair of Advanced Micro Devices-powered servers in our lab, running CentOS 6.0. I installed the management server on a VM running on our vSphere infrastructure. For my cloud testing, I used a single-node configuration based on Ubuntu’s OpenStack on a stick test distribution of the private cloud project, as well as Amazon’s public EC2 cloud service.
I referenced above the loose integration between the ConVirt management server and its Linux-based host machines, an impression that begins with the installation documentation for the product. The configuration instructions, which are available on the ConVirt wiki, have a bit of a “choose your own adventure” feel to them, as they jump between pages based on the sort of components in use. Also, ConVirt, which began life as a tool for managing Xen hosts, sports an interface that is full of somewhat confusing Xenisms that users choosing KVM can ignore.
Once I had my ConVirt hosts configured for basic virtualization, preparing the installation for the creation of private clouds entailed the configuration of a virtual LAN identification pool to enable the product to segregate individual clouds on their own networks.
From here, I added an infrastructure-as-a-service (IaaS) connection to my chosen ConVirt pool, within which I could create individual clouds, each with their own allowable VM templates, access controls and resource quotas.
In addition to choosing a ConVirt pool for my IaaS connection, I was able to select from Amazon EC2, OpenStack or Eucalyptus as IaaS providers. In my tests with EC2 and OpenStack, this process ran in much the same way. Both services rely on the EC2 API (as does Eucalyptus, the other supported third-party cloud), and the ConVirt-side configuration boiled down to providing my authentication credentials for the service.
As with the ConVirt-based clouds, I then created virtual data centers under both EC2 and OpenStack, with the template, resource and user controls I desired. For EC2, no further network configuration was required, as the service takes care of network creation on its own. With my OpenStack installation, I had to add a floating address pool, which I was able to take care of easily enough with the aid of the OpenStack documentation. From there, I requested a set of public IP addresses from OpenStack through the ConVirt console, which were then available to allocate to my guest machines.
On EC2, my choice of VM templates was limited to 300 or so Amazon-published templates. I’d like to see Convirture add a means of importing an organization’s own custom Amazon Machine Images for use here as well.
Running my virtual guests on each of the clouds was a straightforward affair, and I could monitor basic stats for each cloud and guests from the ConVirt Web console. I liked being able to access the separate clouds from a common interface, but the product doesn’t currently support any mixing between the clouds. For instance, I wasn’t able to shift a workload from my on-premises OpenStack cloud to EC2, nor could I easily synchronize my available templates between my separate clouds. I’d like to see more inter-cloud capabilities in future versions of the ConVirt product.