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.
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
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
to see Convirture add a means of importing an organization's own custom Amazon
Machine Images for use here as well.
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