Bugs

Kernel side KVM bugs should be file to the kernel's bug tracker.

Userspace bugs should be filed to Qemu's launchpad tracker. If you think they are qemu-kvm specific (i.e. upstream qemu is not affected), you should mark them clearly as being qemu-kvm specific.

If in doubt, email (kvm@vger.kernel.org) the mailing list first (no need to register) and you will be directed where to file the bug if necessary.

Historical bug reports can be found in the sourceforge bug tracker.

Submitting a bug report

When submitting a bug report, make sure to provide the following information:

What cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210). See /proc/cpuinfo if you're not sure.
What kvm version you are using. If you're using git directly, provide the output of 'git describe'.

The host kernel version

What host kernel arch you are using (i386 or x86_64)

What guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version

The qemu command line you are using to start the guest

Whether the problem goes away if using the -no-kvm-irqchip or -no-kvm-pit switch.

Whether the problem also appears with the -no-kvm switch.

Please use the latest release version of kvm at the time you submit the bug. Even if you use kvm from a distribution (Ubuntu starting from Feisty or Fedora starting from 7), it is important to use the latest sources.

In case qemu-kvm exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with

(gdb) info threads

And for every thread present do:

(gdb) thread n

(gdb) bt

Attach the output to the bug report.

Getting a serial console from the guest

If a guest crashes on boot, it is sometimes useful to have its console output. This can be done using qemu's -serial option to emulate a serial port:

qemu-system-x86_64 -serial file:serial.log

Depending on the guest OS you will need to do some additional changes to instruct it to use the serial port as a console as shown below :

Linux

Change the guest kernel's command line (in the GRUB or LILO menu) to include the string

console=ttyS0,115200

If after a crash, there is still no output in the serial.log file and the guest kernel was configured to use a serial console; chances are that the crash was too early in the process to have the console initialized, so then the following kernel command parameters should be added (but only use as a last resort as it interacts badly with the console boot parameter)

earlyprintk=serial,ttyS0,115200

OpenSolaris

Change the guest kernel's entry in the GRUB menu to include the string

-B console=ttya

if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot as there will be no output in the SDL console and you won't be able to interact with it through the keyboard.

Tracing

When debugging kvm, it is often convenient to get a trace of what's going on.