Can you manage different hypervisor platforms from a single pane of glass? Yes, you can.
Virtualization is now a staple of the modern enterprise. As more and more shops switch to the virtual paradigm, managing those new virtual resources is a critical part of any deployment. For admins using Microsoft- or VMware-based hypervisors, powerful management tools are available to keep their virtual houses in order. Unfortunately, those products and their accompanying tools come with a hefty price tag. The good news is that inexpensive open-source virtualization is on the rise, driven in large part due to its low performance overhead. However, one of the primary obstacles to large-scale open-source virtualization adoption has been the lack of robust management tools. virt-manager is the most well known and used, and although it's a great tool, it does not hold a candle to the enterprise tools put out by the big vendors. That's where ConVirt comes in.
ConVirt is an open-source tool capable of managing multiple types of hypervisors including Xen, KVM and now VMware from a single pane of glass. When evaluating ConVirt for your needs, it is best to think of it as a front end to the native tools of the hypervisors that provides extended features not available in a standalone hypervisor. Although there is some overlap with virt-manager, ConVirt adds an additional level of enterprise manageability. ConVirt is currently offered in three tiers: Open Source, Enterprise and Enterprise Cloud. This article focuses on the open-source version. The open-source version does not include the ability to manage VMware items, so the testing environment for this article contains only Xen and KVM servers. Even though I don't cover it here, the ability to manage VMware hosts along with KVM and Xen hosts from the same pane of glass should peak the interests of many admins.
Let's get started by installing the ConVirt Management Server or CMS. ConVirt can be installed on most flavors of Linux or as a pre-configured virtual appliance that can be imported into a KVM or Xen server. I chose to deploy my CMS on a physical server running CentOS 6.2 to allow plenty of storage space (the virtual appliance is roughly 2–3GB in size), although the appliance probably will get you up and running faster. Make sure that whichever installation method you select, that you open all the necessary ports on your CMS and on your managed servers/hosts that you want to manage through the console (TCP 8081, 8006, VNC ports and SSH).
The term “managed server” refers to those hosts running a hypervisor that is managed by ConVirt and can be used interchangeably with the term “host”. Follow the installation procedures available on the Convirture Wiki site to perform the installation of the CMS. Most of the install is handled by a script that pulls down the dependencies and installs MySQL. I won't go into finer detail on the server install, as it is well documented on the site and I would just be repeating the information here.
After the CMS install is complete, access your management page at http://youripaddress:8081 (Figure 1). Use the default login of “admin/admin” to bring up the main console. For those used to VMware's vSphere, this interface will feel familiar. The layout is broken into three main panels: a navigation panel on the left, a display panel for selected items in the middle of the page and a panel at the bottom for displaying task results (Figure 2).
Figure 1. The Main Login Screen
Figure 2. First View of the Data Center
The navigation pane is logically divided into a tree with your Data Center at the top with Server Pools and Templates listed underneath it. This outline reflects how resources are organized in ConVirt: Data Center→Server Pool→Managed Server (host)→Guest. Your Data Center is the top-most delineation of your virtual environment. It could be a site or an organizational unit. Under the Data Center are Server Pools that group together like managed servers that share common items like storage and virtual network configurations. Managed servers are placed in the server pools along with any guests/VMs that reside on them. Templates fall into their own category, but also are available from the navigation pane. Templates are pre-configured groups of settings used at provisioning time to carve up/define the virtual resources available to new guests (processors, memory, storage and NICS).
The next step in your deployment is to prepare your hosts to become managed servers. Specific hypervisors have individual requirements before being added to the CMS, but the process for preparing each host is roughly the same for each. Create a network bridge on each host, download the ConVirt tool from the site and install any dependencies. Then configure SSH on each managed/server host for root access, and finally, run the convirt-tool setup command. Debian/Ubuntu users should note that you will need to set a password on the root account manually in order to manage any hypervisor from the CMS. I also suggest that you name any bridges you create with identical names (for example, KVM=br0, Xen=Xenbr0), as this helps standardize your guests' networking options. For this article, I created two KVM servers and one Xen server to manage with ConVirt.
With the hosts prepared, you now can add them to the CMS. This starts by adding hosts to a server pool. You can use the pre-configured Server Pools (Desktop, Server, QA Lab) or create your own. I created an additional pool to play with that I named “Production”, and in case I messed anything up, it wouldn't affect the default pools. When you have your pool selected, right-click on it and select Add Server. On the resulting screen, select your platform, either Xen or KVM, and fill in the hostname or IP address.
If you have not configured SSH for root access on the host, the server will fail. If the server is added successfully, it now should display under the server pool you chose with a little K (K) or X (Xen) icon (Figure 3). Click on the newly added server to see performance information about your host displayed in the center pane (Figure 4). From this display, you also can view the number, type and status of the guest running on the host.
Figure 3. Our New Server Group
Figure 4. Real-Time Performance Stats on One of Our KVM Servers
Continue adding all of your hosts as managed servers to the console until they have all been added. You then can import any pre-existing VMs on your hosts by right-clicking the managed server and selecting Import Virtual Machine Config Files. You also might notice from this same menu context that you can move servers between pools. This feature is useful during organizational changes or when moving test servers into a production environment. Be aware that moving a server between pools also moves any that reside on it, so be aware of any configuration changes that might be applied by moving your server/guests into the new pool. You also are required to power down any running guests before moving the server.
Because I already have covered how to add existing guests to managed servers, let's create a new guest from a template (this also is called provisioning). To get a feel for all of your options, let's provision a guest VM from CD as well as clone a guest from a golden image using a reference disk.
Out of the box, ConVirt has two pre-configured templates for use with provisioning. These templates contain common configuration settings for a specific OS installed from a CD. Provisioning from the built-in templates is easy. Simply right-click a template, and select Provision to create a guest on your selected managed server.
For this example setup, let's create a Linux desktop from the existing Linux CD template. After clicking on Provision, you are asked on which server to place the new guest VM, and then you're prompted to provide a name for the it (Figure 5). ConVirt then creates a guest based on your name and creates a 10GB virtual hard drive and maps the guest to the physical CD/DVD of the host on which it's provisioned.
Figure 5. Provisioning a Guest from the Linux Template
Next, insert your physical install media on the host's physical drive. Once the guest VM appears under the host, power it up by right-clicking on the new guest and clicking Start.
If you do not want to use CDs, you also have the option to boot from an .iso file. To do so, change the path of your /dev/cdrom to an accessible .iso file (Figure 6) in the settings of a template or the guest itself. Once the VM has been started, right-click on it and select View Console. If you have a Java-enabled browser, you can access the new VM's desktop via the Web console, or if you choose another VNC client, ConVirt will display the IP and port required to access the VM. If you prefer to administer your host via SSH, you also can launch a session from the guest's right-click context menu.
Figure 6. Mounting an .iso to the Guest CD-ROM
Provisioning from CD is nice for custom machines or one-off builds, but if you have to spin up multiple guests at once, it is a very inefficient method. It is much more efficient to create a single VM and clone it over and over again, which is possible in ConVirt. To demonstrate this method of provisioning, I created a pristine (or “golden”) image of a Windows XP machine. This VM contains all of the settings and software needed so that I don't need to make changes to each new VM that is spun up. After the golden image is ready, power it down in the hypervisor or ConVirt, and copy the guest's .xm file to a separate location. In my case, I copied it to an NFS share mounted on the ConVirt and all of my managed servers. You then need to gzip your .xm image in its new location to give it a .gz extension. Next, copy the Windows CD template by right-clicking it in the templates section and clicking on the Create Like option.
You could create a template from scratch, but copying and modifying a built-in one is just as quick. If you have very custom settings that differ greatly from those found in the pre-built templates, that may be the way to go.
When prompted, give your template a new name. Once the new template appears in the list, right-click on it and select the Edit Settings option. Click on the Storage option and remove the existing storage defined for hda. Click on the New button at the top of the window. On the resulting window, set the Option field to Clone Reference Disk. Change the Ref. Disk Type to Disk Image and the Ref. Format to .gzip. In the Ref Loc. field, browse or enter the path to your .iso file. Change the VM Device: field to “hda”. Your settings should resemble those shown in Figure 7.
Figure 7. Provisioning Settings to Clone the Golden Image
To deploy a new cloned VM from this template, right-click it and select Provision. With the reference disk method, ConVirt will copy the .gz file to its destination and expand it to the desired size of the new VM. What is really nice is that you can specify a larger disk size than the one inside your golden image. On my XP VMs, the space automatically was added to the guest partition (not usually an easy task). It is a common best practice to keep your golden image as small as possible to fit as many different size drives (virtual or physical) that you will deploy it to.
After your deployment is in place, you may find that you need to move guests to another host to balance loads between servers, to move a VM from one network site or segment to another or to perform maintenance on a host with zero downtime to running guests. VMware dominated the market for years with its vMotion feature that performs this task well. ConVirt provides this same operation.
Note that in order to migrate running guests between hosts, both hosts must have access to the same shared storage. You may run into other limitations when migrating guests, such as both hosts must have the same processor type and/or must be on the same hypervisor platform (like KVM or Xen), so plan accordingly. I was unable to determine whether this was a technical limitation or an unlocked feature in the enterprise version of ConVirt. Either way, there are some native tools in the hypervisors that can convert foreign disk/VM types for importation into their native platform. After you have met all the prerequisites, migrating is as simple as right-clicking the guest and selecting your destination server. You can monitor your migration task in the bottom pane of the console.
One last feature I want to mention is ConVirt's management of shared storage, because I think it is useful (Figures 8 and 9). With the designer's tree-based approach to organizing virtual resources, you set shared storage at the Data Center-level and then attach it to Server Pools, which gives you the ability to mix and match your storage among the pools. Be aware that for all servers in the pool to use the storage, they must connect to the storage using the same logical path (like migration). I found this feature incredibly useful as it really simplifies assignment of any networked storage resources you have in your environment (SAN, iSCSI or NFS). You also can set certain provisioning settings at the pool level that override those in a template. This means you can provision the same template with multiple storage options. This would be very handy if you have Server Pools in different sites or different departments, each that should use their own storage resources.
Figure 8. Shared Storage Details
Figure 9. Server Pools That Can Use This Storage
In this article, I've touched on many of the nicer features in ConVirt, but now let me talk about some things that are missing. Before doing so, you should recognize that I am comparing apples and oranges when I talk about ConVirt and vendor-produced management tools. Even comparing the Enterprise version of ConVirt is not wholly accurate, as ConVirt is meant to manage a heterogeneous virtual environment whereas Microsoft and VMware are tuned to their own homogeneous platforms.
That being said, I still had a few gripes with ConVirt. The first is that it requires root access to managed servers to communicate with the CMS, which I am sure most admins won't be crazy about. Snapshot support also is noticeably missing from the open-source version. There is an option available for the VMs called Hibernate, but that takes a snapshot only of the running memory not the underlying disk. The lack of snapshots bothered me only for half-a-second when I realized it is available in the Enterprise version. The last item missing from ConVirt is administrative roles. You do have the ability to create users and groups in the console, but as far as I can tell, the only thing that gets you is auditing of the tasks that take place on the CMS server. It felt like this was added into the product in its most basic form, but never fully developed.
In the end, these are minor complaints as ConVirt provides far more utility than the few features it lacks. The software really gives you a lot of flexibility, especially with KVM, and you can't beat the price point. I'm sure those features unlocked in the Enterprise version (snapshots, high availability and spanned virtual networks) are worth the money and bring it more in line with the vendor-produced management offerings. I know how much VMware costs, and I am sure ConVirt comes in under that. I will say that you really need to know your chops when managing different hypervisors at the same time. I am one of those admins who works with vSphere daily, and I have become accustomed to a homogeneous environment, so I really had to get under the hood of both KVM and Xen to make things go smoothly. That being said, once it in place, I believe it is easier to administer by non-Linux IT pros or admins who need to perform day-to-day tasks in their virtual environment than virt-manager or command-line tools. Add in the ability to manage a multiplatform hypervisor environment, and the value of ConVirt is apparent.