KVM

From KVM

(Difference between revisions)
Revision as of 21:10, 9 July 2009
MarkusArmbruster (Talk | contribs)
(Fix markup)
← Previous diff
Revision as of 16:22, 21 May 2010
Iggy@theiggy.com (Talk | contribs)
(Change to using Qemu and the kernel's trackers instead of the sourceforge one... also some white space cleanups)
Next diff →
Line 1: Line 1:
=Bugs= =Bugs=
-You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto:kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well. +Kernel side KVM bugs should be file to the [[https://bugzilla.kernel.org/|kernel's bug tracker]].
 + 
 +Userspace bugs should be filed to [[https://bugs.launchpad.net/qemu|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 [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker].
== Submitting a bug report == == Submitting a bug report ==
Line 7: Line 13:
When submitting a bug report, make sure to provide the following information: 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 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'. +* 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) +* The host kernel version
-* 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 +* What host kernel arch you are using (i386 or x86_64)
-* whether the problem goes away if using the <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch. + 
-* whether the problem also appears with the <code>-no-kvm</code> switch. +* 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 <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.
 +
 +* Whether the problem also appears with the <code>-no-kvm</code> 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. 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.

Revision as of 16:22, 21 May 2010

Contents

Bugs

Kernel side KVM bugs should be file to the [bug tracker].

Userspace bugs should be filed to [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 touse a serial console; chances are that the crash was too early in the process to have the console initialized and then the following kernel command line should be used additionally (only to be used 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 asthere will be no output in the SDL console and you won't be able to interact with it through the keyboard.

Views Article Discussion Edit History
Personal tools:  Log in / create account
Toolbox What links here Related changes Upload file Special pages Printable version