docs/bugs.html.in

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE html>
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4   <body>
   5
   6     <h1>Bug reporting</h1>
   7
   8     <ul id="toc"></ul>
   9
  10     <h2><a id="security">Security Issues</a></h2>
  11
  12     <p>
  13       If you think that an issue with libvirt may have security
  14       implications, <strong>please do not</strong> publicly
  15       report it in the bug tracker, mailing lists, or irc. Libvirt
  16       has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
  17       that should be used instead. So if your issue has security
  18       implications, ignore the rest of this page and follow the
  19       <a href="securityprocess.html">security process</a> instead.
  20     </p>
  21
  22     <h2><a id="bugzilla">Bug Tracking</a></h2>
  23
  24     <p>
  25       If you are using libvirt binaries from a Linux distribution
  26       check below for distribution specific bug reporting policies
  27       first.
  28     </p>
  29
  30     <h2><a id="general">General libvirt bug reports</a></h2>
  31
  32     <p>
  33       The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
  34       should be used to report bugs and request features in libvirt.
  35       Before submitting a ticket, check the existing tickets to see if
  36       the bug/feature is already tracked.
  37
  38       For general libvirt bug reports, from self-built releases, GIT snapshots
  39       and any other non-distribution supported builds, enter tickets under
  40       the <code>Virtualization Tools</code> product and the <code>libvirt</code>
  41       component.
  42     </p>
  43     <p>
  44       It's always a good idea to file bug reports, as the process of
  45       filing the report always makes it easier to describe the
  46       problem, and the bug number provides a quick way of referring to
  47       the problem.  However, not everybody in the community pays
  48       attention to bugzilla, so after you file a bug, asking questions
  49       and submitting patches on <a href="contact.html">the libvirt
  50       mailing lists</a> will increase your bug's visibility and
  51       encourage people to think about your problem.  Don't hesitate to
  52       ask questions on the list, as others may know of existing
  53       solutions or be interested in collaborating with you on finding
  54       a solution.  Patches are always appreciated, and it's likely
  55       that someone else has the same problem you do!
  56     </p>
  57     <p>
  58       If you decide to write code, though, before you begin please
  59       read the <a href="hacking.html">contributor guidelines</a>,
  60       especially the first point: "Discuss any large changes on the
  61       mailing list first. Post patches early and listen to feedback."
  62       Few development experiences are more discouraging than spending
  63       a bunch of time writing a patch only to have someone point out a
  64       better approach on list.
  65     </p>
  66
  67     <ul>
  68       <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Virtualization%20Tools">View libvirt tickets</a></li>
  69       <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&amp;component=libvirt">New libvirt ticket</a></li>
  70     </ul>
  71
  72     <h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
  73     <ul>
  74       <li>
  75         If you are using binaries from <strong>Fedora</strong>, enter
  76         tickets against the <code>Fedora</code> product and
  77         the <code>libvirt</code> component.
  78         <ul>
  79           <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Fedora">View Fedora libvirt tickets</a></li>
  80           <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&amp;component=libvirt">New Fedora libvirt ticket</a></li>
  81         </ul>
  82       </li>
  83       <li>
  84         <p>
  85           If you are using binaries from <strong>Red Hat Enterprise
  86           Linux</strong>, enter tickets against the Red Hat Enterprise
  87           Linux product that you're using (e.g., Red Hat Enterprise
  88           Linux 6) and the <code>libvirt</code> component.  Red Hat
  89           bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
  90           you are a Red Hat customer.
  91         </p>
  92       </li>
  93       <li>
  94         <p>
  95           If you are using binaries from another Linux distribution
  96           first follow their own bug reporting guidelines.
  97         </p>
  98       </li>
  99       <li>
 100         <p>
 101           Finally, if you are a contributor to another Linux
 102           distribution and would like to have your procedure for
 103           filing bugs mentioned here, please mail the libvirt
 104           development list.
 105         </p>
 106       </li>
 107     </ul>
 108
 109
 110     <h2><a id="quality">How to file high quality bug reports</a></h2>
 111
 112     <p>
 113       To increase the likelihood of your bug report being addressed it is
 114       important to provide as much information as possible. When filing
 115       libvirt bugs use this checklist to see if you are providing enough
 116       information:
 117     </p>
 118
 119     <ul>
 120       <li>The version number of the libvirt build, or SHA1 of the GIT
 121         commit</li>
 122       <li>The hardware architecture being used</li>
 123       <li>The name of the hypervisor (Xen, QEMU, KVM)</li>
 124       <li>The XML config of the guest domain if relevant</li>
 125       <li>For Xen hypervisor, the domain logfiles from /var/log/xen and
 126           /var/log/libvirt/libxl</li>
 127       <li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
 128     </ul>
 129
 130     <p>
 131       If the bug leads to a tool linked to libvirt crash, then the best
 132       is to provide a backtrace along with the scenario used to get the
 133       crash, the simplest is to run the program under gdb, reproduce the
 134       steps leading to the crash and then issue a gdb "bt -a" command to
 135       get the stack trace, attach it to the bug. Note that for the
 136       data to be really useful libvirt debug information must be present
 137       for example by installing libvirt debuginfo package on Fedora or
 138       Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
 139       to running gdb.</p>
 140     <p>
 141       It may also happen that the libvirt daemon itself crashes or gets stuck,
 142       in the first case run it (as root) under gdb, and reproduce the sequence
 143       leading to the crash, similarly to a normal program provide the
 144       "bt" backtrace information to where gdb will have stopped.<br/>
 145       But if libvirtd gets stuck, for example seems to stop processing
 146       commands, try to attach to the faulty daemon and issue a gdb command
 147       "thread apply all bt" to show all the threads backtraces, as in:</p>
 148       <pre> #  ps -o etime,pid `pgrep libvirt`
 149 ... note the process id from the output
 150 # gdb /usr/sbin/libvirtd
 151 .... some information about gdb and loading debug data
 152 (gdb) attach $the_daemon_process_id
 153 ....
 154 (gdb) thread apply all bt
 155 .... information to attach to the bug
 156 (gdb)
 157 </pre>
 158
 159   </body>
 160 </html>