Bug reporting

Bug Tracking

If you are using libvirt binaries from a Linux distribution check below for distribution specific bug reporting policies first.

General libvirt bug reports

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. 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.

It's always a good idea to file bug reports, as the process of filing the report always makes it easier to describe the problem, and the bug number provides a quick way of referring to the problem. However, not everybody in the community pays attention to bugzilla, so after you file a bug, asking questions and submitting patches on the libvirt mailing lists will increase your bug's visibility and encourage people to think about your problem. Don't hesitate to ask questions on the list, as others may know of existing solutions or be interested in collaborating with you on finding a solution. Patches are always appreciated, and it's likely that someone else has the same problem you do!

If you decide to write code, though, before you begin please read the contributor guidelines, especially the first point: "Discuss any large changes on the mailing list first. Post patches early and listen to feedback." Few development experiences are more discouraging than spending a bunch of time writing a patch only to have someone point out a better approach on list.

Linux Distribution specific bug reports

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:

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 -a" 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 gets stuck, in the first case run it (as root) under gdb, and reproduce the sequence leading to the crash, similarly to a normal program provide the "bt" backtrace information to where gdb will have stopped.
But if libvirtd gets 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)