ConVirt Enterprise in the Lab

By Jason Brooks  |  Posted 2011-10-25 Print this article Print

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.



As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel