Tip: Set the keyboard layout in virt-builder

Compared to setting the language of a guest setting the keyboard layout of a guest in virt-builder is a relative piece of cake.

In CentOS you can use the nice Perl-based virt-builder file editing feature to edit the appropriate configuration file:

virt-builder centos-6 \
  --edit '/etc/sysconfig/keyboard:
            s/^KEYTABLE=.*/KEYTABLE="uk"/'

Any line in the file matching KEYTABLE=... is replaced by KEYTABLE="uk". This works by running the Perl expression (s/.../.../ above, but full Perl programs are possible) on the guest file (/etc/sysconfig/keyboard) and uploading the result.

Debian is also simple:

virt-builder debian-7 \
  --edit '/etc/default/keyboard:
            s/^XKBLAYOUT=.*/XKBLAYOUT="gb"/'

Fedora requires that we run a program, localectl(1). Unfortunately localectl requires that dbus is running (for good reasons, but in this case it’s unhelpful), so we can’t just use --run-command to run it while building the guest because libguestfs doesn’t run a dbus daemon. Instead we’ve got to schedule the command to run at first boot, like this:

virt-builder fedora-20 \
  --firstboot-command 'localectl set-keymap uk'

Should virt-builder try to hide all this complexity behind a nice, simple --keyboard option? It’s something to consider.

It would be nice if distros could be more standardized too. I’m suspicious of requiring a program to be run in order to change what ought to be a pure configuration file setting. (If your objection is that other programs must be informed when the configuration changes, then dbus could provide a way to monitor when configuration files change, implemented using inotify.)

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.