The next virtualization strategy I’m testing out is KVM. I’m using Proxmox as the management layer (similar to how I used XenServer on top of Xen), and this provides a nice API, command-line interface, and web-based GUI. Proxmox also makes it easy to do common tasks like pool servers and live migrations. To start, the first task is to automate getting a VM running.
Xen and KVM
KVM (Kernel Virtual Machine) is similar to Xen in that they’re both hypervisors (and in fact, both are “Type 1” hypervisors). They both allow you to partition off some disk space and plop an isolated virtual machine on it. They both manage CPU, IO, power, and memory for their virtual machines, and they both promise isolation and security. They differ, though, in how they perform these tasks, and that’s what I’ll be exploring in the next few posts.
Proxmox, KVM & Containers
Proxmox will manage not only virtual machines (using KVM), but also containers (using OpenVZ). Containers are a cool idea, but beyond the scope of what I’m interested in testing. So, for everything I talk about with respect to Proxmox, you can assume I’m talking about the KVM virtual machines.
The concepts required to work with KVM are considerably simpler than Xen. For instance, in Xen you explicitly create a VIF (Virtual INterface) to connect a VM to a network, and then you attach that VIF to a VM. With KVM, it’s just a set of attributes directly on the VM. When it comes to storage, a VM’s disks appear as files on the hypervisor’s filesystem, which means you can copy them or back them up as you please, using normal linux tools. Similarly, you can manage other aspects of the KVM hypervisor in the normal linux fashion (eg creating multiple bridges on the hypervisor).
Starting a VM
To create a new VM, it’s a matter of 2 commands. First you create an empty disk image for it to use, then you create the VM. All the options it needs (network settings, CPU count, etc) are just arguments to that creation command. If you add the command to start the VM after creation, this is what you end up with:
After executing the above, you will have a running VM with a 32GB disk, 2GB of RAM, 1 cores, 2 network devices (public and private, in my case), and a mounted ISO of Centos 6. I loaded the ISO previously, but even that was just a matter of moving it to a spot on the linux filesystem (which is easier than what you have to do for Xen).
As I mentioned above, Proxmox adds a management layer on top of KVM which includes a nice command-line interface & API. You saw the CLI in the snippet above. The API mirrors the CLI, which makes it easy to translate the above script into API calls:
Well, at least that’s how it ought to work. The command to actually create the VM (line 15) bombs out with a validation error on ide2. Not sure why, but if we get serious about KVM then I’ll definitely dig into that more to determine if it’s a bug or just PEBKAC.
Like XenServer, you can either use a vnc client to connect to a VM, or have it exposed via a java applet. I fiddled with getting a VNC session to work through an SSH tunnel, and couldn’t get it to work. The way most Proxmox users seem to handle this is by exposing the VNC port over the network interface (which would be the public interface, for this test), and I don’t want to do that. Instead, I just used the web-based applet to run through the CentOS installation and get the box’s networking set up.
So far, I like KVM’s simple structure, and I like Proxmox’s API and CLI. I did hit some rough edges (eg the validation error from the API and the console over SSH), which I’m sure could be worked out, but take away a little from the polished feel. Even if they were PEBKAC, not being able to figure them out after what I consider a fair amount of effort/research isn’t a great sign. In addition to all that, I also like that linux is the hypervisor, and that a lot of the familiarity I have with administering linux will be useful on a KVM hypervisor (this is largely contrary to xen).