Scope

This page is intended to assist in two things:

• Help experienced users to improve bug reporting against libvirt/qemu by providing deeper insights on the first report

• Help packagers to maintain the libvirt and qemu packages

This is not meant to be a "how to use" guide and there is no need to rewrite the documentation here. There is good community and serverguide documentation for KVM available already. And from there you'll find more links to upstream guides on specific details.

• Ubuntu KVM Communuty Guide

• Serverguide Virtualization

Reporting Bugs

Apport tries to collect information already, but quite often there are a few common things which can help to lower the turnaround time on libvirt/qemu bugs. If you are willing to do so please consider adding the following to those bugs right away:

• Generic checks - it can be useful to check and add those to the bugs
  • virt-host-validate - a generic check of virtualization capabilities, and output of that can uncover the most common issues
  • virsh capabilities - this will list libvirts point of view on your host and can help to spot issues as well
• Debugging on your own

  • If you guest is crashing you could think about trying to track down its console output. There is an upstream page describing how to do so

  • If you want to attach a debugger consider monitor through libvirt. With that you can start a gdb session like virsh qemu-monitor-command --hmp <guestname> 'gdbserver'

• Help reproducers to match your case
  • Qemu Commandline - if you happened to run qemu directly please include the full commandline

  • Guest XML - if driven through libvirt (and that is also true for Openstack -> Libvirt -> Qemu) please consider attaching the XML describing the guest.

Maintenance of Qemu Debian/Ubuntu Packaging

Qemu is maintained together with Debian at qemu.git. There are various branches per Release, the last one at the moment being ubuntu-zesty-2.8.

Qemu mostly is a very normal package in regard to merging it, delta to Debian and so on.

Yet sometimes it isn't - so here is a list of things that might be unexpected or missed the first time working on it.

• control-in
  • There is no debian/control at all in git. If you downloaded via e.g. pull-lp-source please watch out, changes should always go to debian/control-in

    You can regenerate debian/control via ./debian/rules debian/control This applies a filter as debian/control-in holds multiple per-distro (::ubuntu::/::debian::) statements. Those are filtered out when regernating. Since zesty the created debian/control holds a warning and is read-only to avoid users editing the wrong file.

• enabling features
  • Usually done in debian/rules but since there are so many platform (and Distro) dependent options this is driven from debian/control-in.

    A line like "# --enable-foo" will get into the configure step as --enable-foo. On the other hand "# --enable-numa i386|amd64" will only enable it on certain architectures. This provides the ability to keep features and build dependencies close and changes per target.

• The final "complex" case on patches to Ubuntus qemu are around the Machine Type

  • There is a dedicated page for that at QemuKVMMigration. Also the related patches in debian/patches/ refer to that wiki page.

Maintenance of Libvirt Debian/Ubuntu Packaging

Libvirt is maintained in an Ubuntu git tree. We merge from Debian from their git.

As usual we strive to upstream any Delta to either Debian or Upstream itself - whatever applies. In the Libvirt case there are two major sources of Delta left which are low-prio wip to get rid of (everybody feel free to help - get in touch with smb/cpaelzer on IRC if you want).

• Handling on Xen in Ubuntu
  • Due to the different history our Xen support differs and thereby has some Deltas which are just not suited for Debian/Upstream that should be considered a heritage for now.
• Handling of Apparmor rules for libvirt
  • For Apparmor we are in the slow progress to use the upstream profiles.

    But due to the history of Apparmor and the fact that some versions are backported e.g. via the Cloud Archive we need to take care of using different version dependent rules. So at the moment on each merge we copy the current upstream rules to *.in files and modify those on build to match our needs. The related patches have howtos how to regenerate them easily in their dep3 headers since zesty.