seife’s assorted rants

Yesterday I finally figured out how to use the virtio console on KVM, which is very easy once you know what to do.

A short explanation of what a “virtio console” is:
On paravirtualized environments like Xen the VM (guest) has no direct hardware access, but also no emulated hardware but instead needs special drivers that know it is running on a hypervisor. The advantage of this approach is that you don’t need to emulate hardware and that the driver for the guest is often much simpler (it does not need to probe hardware, for example, as it talks to the hypervisor via a special interface). This makes for a very convenient default Xen setup where you can just do “xm console ” on the hypervisor and get a functional console without any fiddling.
On fully virtualized environments, usually an emulated serial port is used for that, which is harder to set up. It is not impossible, but definitely not that easy and there is quite some stuff to configure to get it working.
Nowadays even fully virtualized systems often have some paravirtualized drivers available, mostly for performance reasons. One of those paravirtualized drivers available with KVM is the virtio console driver.

So back on topic: how to set up the virtio console driver for a KVM guest
First, edit the configuration of your guest, in my case with “virsh edit factorytest” (factorytest is the name of my guest). Add the following snippet of configuration before the closing “</devices>” tag:

    <console type='pty'>
      <target type='virtio' port='0'/>
    </console>

Then a few things need to be done on the KVM guest. In my case of an openSUSE 12.2 guest, the virtio_console module was loaded automatically. However, it surely won’t hurt to put it into INITRD_MODULES in /etc/sysconfig/kernel.
The second thing is “console=hvc0″ needs to go onto the Kernel command line.
The easiest way to accomplish this is to use the YaST bootloader module and add it in the “Boot Loader Options” tab. You need to actually make sure there is “console=tty console=hvc0″ there, because without the “console=tty” the system did not boot up cleanly for me. I guess that the kernel is not happy with only a console that gets added later via a module, but I need to investigate that.

All the rest was handled by systemd and friends just fine, after rebooting the VM guest, I was immedately able to do “virsh console factorytest”, hit “Enter”, get the login prompt and log in.

…then work around the bug.

One example is bug 699400: hwclock is never set correctly when NTP is used (unless it was almost correct before…).

I reported the bug, I argued with the maintainer, it did lead to nothing, the bug was “RESOLVED INVALID” (interesting notion: either it is resolved or it is invalid, then there is nothing to resolve…)

What’s my workaround? I exploit the fact that old SysV init uses bash scripts. The init script which sets the clock does source /etc/sysconfig/clock. Internally, it uses a variable ELEVENMIN_MODE.
So what did I do? Simply add

readonly ELEVENMIN_MODE=no

at the end of /etc/sysconfig/clock.
The script will throw some errors on boot and shutdown due to its inability to change a readonly shell variable, but I can live much better with a harmless warning than with a totally wrong system time at each reboot

Update: Werner has pointed out in the bug that this is totally wrong and will make a mess of your time settings, so use this at your own risk. OTOH I have more than 2000 productive systems here running with this. We had lots of problems before and have no problems anymore after doing it like described here. So at least for me the wrong solution works good.

Kids, don’t try this at home.
Anyway, here is what worked for me:

• add arch = x86_64 to /etc/zypp/zypp.conf
• zypper ref -f
• rpm -qa kernel*
• zypper in -f kernel-default kernel-default-base (the kernel packages found by the step above)
• mkinitrd
• reboot
• zypper in -f glibc
• zypper in -f rpm Attention: don’t install, just resolve everything and get the list of -32bit packages that would get installed
• zypper in -f file-32bit libbz2-1-32bit… Install all the -32bit packages that were selected in the previous step
• zypper in -f rpm
• zypper dup --no-recommends --download-in-advance
• mkinitrd
• reboot

Whenever zypper asks you for conflict resolution (which will be every single case), select the option that involves “change architecture”, never select “break …” or “do not install …”. There should be no “uninstall…” proposal in the summary before confirming, only architecture changes and newly installed -32bit packgages.

There were some failing postinstalls for glib and other libraries, which could probably have been avoided by more carefully updating in intermediate steps, or by installing some -32bit library packages before the “dup” step, but the resulting system seems to work just fine.