Codebase list libvirt / debian/0.9.8_rc2-2 docs / bugs.html.in
debian/0.9.8_rc2-2

Tree @debian/0.9.8_rc2-2 (Download .tar.gz)

bugs.html.in @debian/0.9.8_rc2-2raw · history · blame

<?xml version="1.0"?>
<html>
  <body>

    <h1>Bug reporting</h1>

    <ul id="toc"></ul>

    <h2><a name="bugzilla">Bug Tracking</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.
    </p>

    <h2><a name="general">General libvirt bug reports</a></h2>

    <p>
      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 <code>Virtualization Tools</code> product and the <code>libvirt</code>
      component.
    </p>

    <ul>
      <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Virtualization%20Tools">View libvirt tickets</a></li>
      <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&amp;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 official binaries from a <strong>Fedora distribution</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&amp;product=Fedora">View Fedora libvirt tickets</a></li>
          <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&amp;component=libvirt">New Fedora libvirt ticket</a></li>
        </ul>
      </li>
      <li>
        If you are using official binaries from <strong>Red Hat Enterprise Linux distribution</strong>,
        tickets against the <code>Red Hat Enterprise Linux 5</code> product and
        the <code>libvirt</code> component.
        <ul>
          <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Red%20Hat%20Enterprise%20Linux%205">View Red Hat Enterprise Linux libvirt tickets</a></li>
          <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&amp;component=libvirt">New Red Hat Enterprise Linux libvirt ticket</a></li>
        </ul>
      </li>
      <li>
        If you are using official binaries from another Linux distribution first
        follow their own bug reporting guidelines.
      </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" 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 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.<br/>
      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:</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>

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

  </body>
</html>