Bug reporting

Bug Tracking

The Red Hat Bugzilla Server should be used to report bugs and request features in libvirt. Before submitting a ticket, check the existing tickets to see if the bug/feature is already tracked.

General libvirt bug reports

If you are using official libvirt binaries from a Linux distribution check below for distribution specific bug reporting policies first. For general libvirt bug reports, from self-built releases, GIT snapshots and any other non-distribution supported builds, enter tickets under the Virtualization Tools product and the libvirt component.

• View libvirt tickets
• New libvirt ticket

Linux Distribution specific bug reports

• If you are using official binaries from a Fedora distribution, enter tickets against the Fedora product and the libvirt component.
  • View Fedora libvirt tickets
  • New Fedora libvirt ticket
• If you are using official binaries from Red Hat Enterprise Linux distribution, tickets against the Red Hat Enterprise Linux 5 product and the libvirt component.
  • View Red Hat Enterprise Linux libvirt tickets
  • New Red Hat Enterprise Linux libvirt ticket
• If you are using official binaries from another Linux distribution first follow their own bug reporting guidelines.

How to file high quality bug reports

To increase the likelihood of your bug report being addressed it is important to provide as much information as possible. When filing libvirt bugs use this checklist to see if you are providing enough information:

• The version number of the libvirt build, or SHA1 of the GIT commit
• The hardware architecture being used
• The name of the hypervisor (Xen, QEMU, KVM)
• The XML config of the guest domain if relevant
• For Xen hypervisor, the XenD logfile from /var/log/xen
• For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu

If the bug leads to a tool linked to libvirt crash, then the best is to provide a backtrace along with the scenario used to get the crash, the simplest is to run the program under gdb, reproduce the steps leading to the crash and then issue a gdb "bt" command to get the stack trace, attach it to the bug. Note that for the data to be really useful libvirt debug informations must be present for example by installing libvirt debuginfo package on Fedora or Red Hat Enterprise Linux (with debuginfo-install libvirt) prior to running gdb.

It may also happen that the libvirt daemon itself crashes or get stuck, in the first case run it (as root) under gdb, and reproduce the sequence leading to the crash, similary to a normal program provide the "bt" backtrace information to where gdb will have stopped.
But if libvirtd get stuck, for example seems to stop processing commands, try to attach to the faulty daemon and issue a gdb command "thread apply all bt" to show all the threads backtraces, as in:

 #  ps -o etime,pid `pgrep libvirt`
... note the process id from the output
# gdb /usr/sbin/libvirtd
.... some informations about gdb and loading debug data
(gdb) attach $the_damon_process_id
....
(gdb) thread apply all bt
.... informations to attach to the bug
(gdb)

If requesting a new feature attach any available patch to the ticket and also email the patch to the libvirt mailing list for discussion