Reporting Bugs

This page explains how to report a bug against the Xen Project hypervisor or its associated tools. A clear, well-structured bug report is the fastest route to a fix.

Note

If you think a bug might have a security impact, do not post it publicly. Email security@xenproject.org instead. See the Security Problem Response Process for details.

Where to report

If you are not certain the problem is a genuine bug rather than a local configuration issue, post to the xen-users mailing list first. Other users and developers there can help confirm whether the behaviour is expected.

Once you have confirmed it is a real bug, report it on the xen-devel mailing list. Use [BUG] as the first word of your subject line.

You do not need to be subscribed to post — non-subscriber messages are moderated but are usually approved quickly. Replies will be CC’d to you.

Tip

Before posting, search the mailing list archives to check whether the issue has already been reported.

For XCP-ng and XAPI issues, use the xen-api mailing list rather than xen-devel.

Feature requests are handled the same way: post to xen-devel describing what you would like and why. The mailing list is where bugs, feature requests, and the discussion around them all happen.

What to include

A good bug report gives developers enough information to reproduce and understand the problem without having to ask follow-up questions.

Always include:

  • A clear description — What exactly happened, and what did you expect to happen?

  • Xen version — The exact version number, or for git builds, the commit hash. For distribution packages, include the package name and version.

  • Steps to reproduce — Precise steps that cause the problem. A reproducible bug is much easier to fix.

  • Domain configuration — The relevant xl configuration files.

Useful log files:

  • /var/log/xen/xen-hotplug.log

  • /var/log/xen/qemu-dm-<domname>.log

  • Host console output (hypervisor debug key output)

  • Guest console output (often in /var/log/xen/console/)

System information that helps:

  • Network interface configuration: ifconfig -a

  • Network bridge configuration: brctl show

  • PCI devices: lspci -vvv

  • XenStore contents: xenstore-ls -fp

xl toolstack

If you are using xl, run commands with the -v flag (e.g. xl -v create) and include the output of xl info. Also attach /var/log/xen/xl-<domname>.log.

Host console logs

For crashes and hypervisor-level bugs, a host console log is often essential.

First, enable full logging by adding loglvl=all guest_loglvl=all to the Xen hypervisor boot options in your bootloader. Reboot after making this change.

For non-crashing bugs, retrieve logs with:

xl dmesg > hypervisor.log
dmesg > dom0.log

For crashes where the system does not survive, a serial console will capture the output. If a serial console is not available, add noreboot to the hypervisor command line to pause on crash, giving you time to photograph or transcribe the error.

Guest console logs

For guest boot issues, enable guest console logging by setting XENCONSOLED_TRACE=guest in /etc/sysconfig/xencommons or /etc/defaults/xencommons (whichever applies to your distribution). Restart xenconsoled after making this change. Console logs for new guests will appear in /var/log/xen/console/guest-<domname>.

Mailing list etiquette

The xen-devel list follows the same conventions as other developer lists — see Observe list etiquette (plain text wrapped at ~72 characters, no top-posting, one thread per topic, keep it on-list).