mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-11-04 12:24:23 +03:00
147 lines
6.0 KiB
XML
147 lines
6.0 KiB
XML
<?xml version="1.0"?>
|
|
<html>
|
|
<body>
|
|
|
|
<h1>Bug reporting</h1>
|
|
|
|
<ul id="toc"></ul>
|
|
|
|
<h2><a name="bugzilla">Bug Tracking</a></h2>
|
|
|
|
<p>
|
|
If you are using libvirt binaries from a Linux distribution
|
|
check below for distribution specific bug reporting policies
|
|
first.
|
|
</p>
|
|
|
|
<h2><a name="general">General libvirt bug reports</a></h2>
|
|
|
|
<p>
|
|
The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
|
|
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 <code>Virtualization Tools</code> product and the <code>libvirt</code>
|
|
component.
|
|
</p>
|
|
<p>
|
|
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 <a href="contact.html">the libvirt
|
|
mailing lists</a> 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!
|
|
</p>
|
|
<p>
|
|
If you decide to write code, though, before you begin please
|
|
read the <a href="hacking.html">contributor guidelines</a>,
|
|
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.
|
|
</p>
|
|
|
|
<ul>
|
|
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Virtualization%20Tools">View libvirt tickets</a></li>
|
|
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&component=libvirt">New libvirt ticket</a></li>
|
|
</ul>
|
|
|
|
<h2><a name="distribution">Linux Distribution specific bug reports</a></h2>
|
|
<ul>
|
|
<li>
|
|
If you are using binaries from <strong>Fedora</strong>, enter
|
|
tickets against the <code>Fedora</code> product and
|
|
the <code>libvirt</code> component.
|
|
<ul>
|
|
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
|
|
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If you are using binaries from <strong>Red Hat Enterprise
|
|
Linux</strong>, enter tickets against the Red Hat Enterprise
|
|
Linux product that you're using (e.g., Red Hat Enterprise
|
|
Linux 6) and the <code>libvirt</code> component. Red Hat
|
|
bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
|
|
you are a Red Hat customer.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If you are using binaries from another Linux distribution
|
|
first follow their own bug reporting guidelines.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Finally, if you are a contributor to another Linux
|
|
distribution and would like to have your procedure for
|
|
filing bugs mentioned here, please mail the libvirt
|
|
development list.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
<h2><a name="quality">How to file high quality bug reports</a></h2>
|
|
|
|
<p>
|
|
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:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>The version number of the libvirt build, or SHA1 of the GIT
|
|
commit</li>
|
|
<li>The hardware architecture being used</li>
|
|
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
|
|
<li>The XML config of the guest domain if relevant</li>
|
|
<li>For Xen hypervisor, the XenD logfile from /var/log/xen</li>
|
|
<li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
|
|
</ul>
|
|
|
|
<p>
|
|
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.</p>
|
|
<p>
|
|
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.<br/>
|
|
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:</p>
|
|
<pre> # 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)
|
|
</pre>
|
|
|
|
</body>
|
|
</html>
|