KVM Forum 2015

Assuming HMG can get my passport back to me in time, I am speaking at the KVM Forum 2015 in Seattle USA (full schedule of talks here).

I’m going to be talking about virt-v2v and new features of qemu/KVM that made it possible for virt-v2v to be faster and more reliable than ever.

libguestfs 1.28 released

The new stable version of libguestfs — a C library and tools for accessing and modifying virtual machine disk images — has been released.

There is one brand new tool, virt-log. And I rewrote the virt-v2v and virt-p2v tools. These tools convert VMware and Xen guests and physical machines, to run on KVM. They are now much faster and better than before.

As well as that there are hundreds of other improvements and bug fixes. For a full list, see the release notes.

Libguestfs 1.28 will be available shortly in Fedora 21, Debian/experimental, RHEL and CentOS 7, and elsewhere.

P2V and V2V: new release

Matt has just released virt-p2v and virt-v2v 0.8.5. Packages will be available in Fedora 16 updates-testing shortly. Read this for the full instructions:

https://www.redhat.com/archives/libguestfs/2011-December/msg00061.html

New virt-p2v screenshot

Poor man’s P2V

(P2V = physical to virtual, taking a physical machine and converting it into a virtual machine)

What happens when you have an old server sitting in the corner — the hardware is flaky and you need to set up a virtual equivalent ASAP, but no one can remember how that old server is configured? People will sell you very expensive software to solve this problem for you.

But if you have some time and patience you can do P2V conversions by hand for free, and it’s not too hard. Here’s how.

First of all, grab a bootable Linux rescue CD. A Fedora CD in rescue mode will do just fine, but choose any Linux CD that you’re happy with.

Now you boot your machine from the CD, so that we are in a modern, Linux-based OS. From the Linux command line you will see the physical disks in the machine like /dev/sda or /dev/hda (check /sys/block).

All you do is take each physical disk in turn and copy it complete over to your virtualization host. Just do:

dd if=/dev/sda | ssh root@virthost 'cat > /var/lib/libvirt/images/guest.img'

That makes a block-for-block identical copy of the hard disk, and it usually takes several minutes to an hour to copy everything across, depending how fast the old server and the network is.

Now over to your virtualization host, how do you boot this?

With very recent versions of virt-install there is a virt-install --import option that you can use to import disk images directly.

Alternately, write a libvirt XML configuration file for the virtual machine. It’s usually best to start off with an existing XML configuration, so just pick another guest at random and do virsh dumpxml foo. Take that output, modify it suitably, make sure it’s full virt (“hvm”), and boot using:

virsh define guest.xml

Now at this point it may not in fact boot. You might need to edit a few things inside the virtual machine disk image, typically /etc/fstab, maybe install a new kernel, perhaps edit the network configuration.

Step forward: guestfish and virt-edit.

$ guestfish -i guest.img
$ virt-edit guest.img /etc/fstab

(Note: I am the author of virt-p2v which is currently in a big version 2.0 rewrite).

What things make P2V/V2V conversion hard?

(In case anyone is confused by the title, P2V means turning a physical system into a virtual machine, and V2V means converting one type of virtual machine into another — eg. a Xen VM into a VMWare VM. Usually what we are talking about is making the conversion completely or mostly automatic.)

There are some things that Linux distros do which make P2V and V2V conversions harder than they really need to be. In this article I hope to collect a few of these things. If you can think of any more, post them as comments and I’ll incorporate them here.

1. Your disk partitions are on hard-coded device names like /dev/hda1

When we virtualize a disk, we usually want to install alternate (“paravirt”) drivers, but these drivers cause the disk names to change. Xen paravirt drivers use /dev/xvda and the standard Linux virtio drivers use /dev/vda.

Your Linux distro may have scattered references to /dev/hd* and /dev/sd* in /etc/fstab, inside the boot initramfs, and maybe in some scripts which are used to decrypt the hard drive at boot time. virt-v2v has to perform intimate surgery on the disk to find and fix all these.

Luckily there is a easy way to avoid this: every major filesystem and swap type for Linux supports either labels or UUIDs. These are preserved transparently when converting, and distros should use these scrupulously, and never use device names.

Update: LVM partition names are OK too. (Thanks Matt Booth).

2. You didn’t expect the network hardware would change

When the OS gets converted, it is highly likely that the network device will appear to change, but mysteriously it will still have the same MAC address.

That’s not supposed to happen with real hardware — MAC addrs are allocated by IEEE and no two manufacturers should have the same ones. Virtual hardware doesn’t play by the same rules.

What we’d want you to do is to keep track of the MAC addresses of each interface and when you see the same MAC, give it the same ethX device name.

Update: See comments.

3. Your kernel doesn’t support virtual devices

Some Linux distros don’t contain drivers for virtual (virtio) devices. There’s a variety of reasons for this, not all of them solvable: The kernel might predate virtio, or the drivers are closed source (eg. for older VMWare), or they might have been compiled out. In some cases a whole different kernel is required (as was true for earlier versions of Xen).

In any case, installing a new kernel inside the guest and making it bootable is major surgery, and we’d rather not do that.

4. X needs reconfiguration

Pretty much the same as for disks and network devices, the display device will also change after conversion (either to a generic Cirrus Logic 54xx or to one of the new accelerated paravirt devices).

Ideally X would just deal with this and bring up a display on the first device it finds, and it should probe all possible devices, but by no means all distros work this way.

5. Making assumptions about the environment around the machine

Static IP addresses and static DNS resolution are a pain when moving a machine. Although not necessarily the fault of the distro as such, it’s better if machines are configured to pick up their network details from a DHCP server.

6. Don’t assume CPU extensions like SSE3 will always be there

After conversion, the new virtual CPU and motherboard you see won’t look very much like the old ones. CPU extensions like SSE, vectors, NX might come or go. The apparent CPU model and manufacturer might have changed. Therefore if you spent any time optimizing the installed packages, those optimizations are wasted and might even cause programs to crash.

It’s better to make your packages generic and have programs detect the runtime environment and optimizations needed each time they start up. (Actually, it’s worse than this when you also consider live migration, because the processor might change while a program is running — no one has really solved this one satisfactorily yet).

---

As you can see, P2V and V2V conversions are like major hardware changes. Your distro should be able to handle just about all the hardware changing underneath it. It should probe everything at boot, hard-code nothing, and be designed to cope gracefully with abrupt changes.

Update: A thread on fedora-devel-list about this issue.