Importing KVM guests to oVirt or RHEV

One of the tools I maintain is virt-v2v. It’s a program to import guests from foreign hypervisors like VMware and Xen, to KVM. It only does conversions to KVM, not the other way. And a feature I intentionally removed in RHEL 7 was importing KVM → KVM.

Why would you want to “import” KVM → KVM? Well, no reason actually. In fact it’s one of those really bad ideas for V2V. However it used to have a useful purpose: oVirt/RHEV can’t import a plain disk image, but virt-v2v knows how to import things to oVirt, so people used virt-v2v as backdoor for this missing feature.

Removing this virt-v2v feature has caused a lot of moaning, but I’m adamant it’s a very bad idea to use virt-v2v as a way to import disk images. Virt-v2v does all sorts of complex filesystem and Windows Registry manipulations, which you don’t want and don’t need if your guest already runs on KVM. Worst case, you could even end up breaking your guest.

However I have now written a replacement script that does the job: http://git.annexia.org/?p=import-to-ovirt.git

If your guest is a disk image that already runs on KVM, then you can use this script to import the guest. You’ll need to clone the git repo, read the README file, and then read the tool’s man page. It’s pretty straightforward.

There are a few shortcomings with this script to be aware of:

1. The guest must have virtio drivers installed already, and must be able to boot off virtio-blk (default) or virtio-scsi. For virtio-scsi, you’ll need to flip the checkbox in the ‘Advanced’ section of the guest parameters in the oVirt UI.
2. It should be possible to import guests that don’t have virtio drivers installed, but can use IDE. This is a missing feature (patches welcome).
3. No network card is added to the guest, so it probably won’t have network when it boots. It should be possible to add a network card through the UI, but really this is something that needs to be fixed in the script (patches welcome).
4. It doesn’t handle all the random packaging formats that guests come in, like OVA. You’ll have to extract these first and import just the disk image.
5. It’s not in any way supported or endorsed by Red Hat.

RHEV-M 3.0 beta part 4

To get access to the RHEV-M 3.0 beta, you must have an active Red Hat Enterprise Virtualization subscription. Go to this RHN page to see links to the beta channels. See this page for discussion around the beta. This is the official announcement.

In a small change of plan from last week I decided to use RHEL 6.1 as the second host, so my architecture now looks like this:

In brief RHEV-H (in this beta version) had a bug which affected me, and installing a full RHEL host allows me more insight into how RHEV is really working under the covers.

Another word of warning: NFSv4 does not work at all with RHEV unless your NFS server can also fall back to NFSv3. I turned off NFSv3 support because of all the hassle with ports and firewalls.

Finally Amazon use an appallingly bad courier company called Hermes Europe who ruined one of the hard drives I was sent. So although I am able to use local storage for guests, I’m short of space until the replacement arrives.

RHEV-M host configuration was pretty straightforward (if you read the docs).

After creating a user in IPA and assigning a desktop to the user, the user portal shows the desktop and lets me click to open it. This was in Firefox 6 on Linux using the spice-xpi plugin:

When you double click on the desktop, the guest opens full screen using SPICE. A good tip is that you can use Shift + F11 to leave full screen mode, and Shift + F12 to release the mouse:

RHEV-M 3.0 beta part 3

To get access to the RHEV-M 3.0 beta, you must have an active Red Hat Enterprise Virtualization subscription. Go to this RHN page to see links to the beta channels. See this page for discussion around the beta. This is the official announcement.

As planned (see part 2) I installed RHEV-M 3.0 beta management server inside a guest on the first host:

There are various reasons for using a guest: (1) The management server has some pretty heavyweight dependencies, like Java, JBoss and FreeIPA, so keeping it in a guest is good for isolation. (2) It means I can easily turn the management server off when I’m not using RHEV-M, and fire up other guests for other work.

On the other hand, RHEV-M has some serious requirements. It needs 2GB of RAM (I found that in fact you have to give it strictly > 2GB of RAM before it will even install), and recommends using 4GB of RAM. The requirements are no joke either, since once it’s running you’ll see a huge JVM process consuming a constant 2GB of RAM and 10% of CPU even when nothing is happening. Welcome to the world of Java …

I also gave the guest 100GB of disk space, thinking it would need a large amount, but in fact it has only used 5GB.

Installation was very straightforward. First I created an ordinary RHEL 6.1 guest (using virt-install). Then I registered the guest with RHN, added the RHN channels, and followed the instructions, and it went mostly without a hitch.

This version runs on Linux, but you still need Internet Explorer to access the Admin Portal. (Note: This requirement will be removed in the next version: RHEV-M 3.1).

Thus I had to use a Windows 7 guest locally in order to get these screenshots:

There’s nothing much I can do in the UI at the moment, because I have no hosts to manage yet. Next week I should have some hard drives.

RHEV-M 3.0 beta part 2

To get access to the RHEV-M 3.0 beta, you must have an active Red Hat Enterprise Virtualization subscription. Go to this RHN page to see links to the beta channels. See this page for discussion around the beta. This is the official announcement.

I received the 2 x HP microservers and the 8 GB RAM upgrades today. Although I don’t yet have the disk upgrades (expected next week) I can make a start installing standard RHEL on one of the servers. I’m going to install RHEV-M into a virtual machine on this first server, but I can’t install that yet without the disk upgrade.

Performing the memory upgrade is relatively simple. Once about 5 cables are removed, the motherboard slides right out:

Because these machines have no CD drive, I used PXE to install RHEL 6.1 (on the first server only):

For clarity, this is what I’m expecting the installation to look like right now (I may change my mind in future though …)

RHEV-M 3.0 beta part 1

To get access to the RHEV-M 3.0 beta, you must have an active Red Hat Enterprise Virtualization subscription. Go to this RHN page to see links to the beta channels. See this page for discussion around the beta. There is also a Webinar taking place today (18th August). Finally here is the official announcement.

I’m getting ready to install RHEV-M 3.0 beta, and that starts with buying some cheap hardware.

RHEV-M requires two physical servers, one running our minimal hypervisor RHEV-H and one running the management console. Starting with RHEV-M 3.0 the management console runs on Linux [PDF] (you can still run it on Windows if you want). The management console can be run in a VM, but it can’t unfortunately be run in a VM on top of RHEV-H because there’s a chicken-and-egg problem that the management console needs to talk to RHEV-H to instruct it to start VMs.

I’m doing this on the cheap, so the hardware I’ve ordered is not the recommended way. Performance is expected to be fairly abysmal.

I ordered two HP Proliant Microservers, and upgrades to the RAM and disks.

2 x HP microservers @£250 each inc tax/delivery	£500
2 x 1 TB Samsung HD103SJ @£44.80 each inc tax/delivery	£89.60
2 x 8 GB RAM @£67.99 each + £27.20 tax, delivery included	£163.18
Total	£752.78

HP have extended the cashback offer on these servers through August 2011, so I should be able to claim £200 back.