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

The primary place for bug reports is 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 conventions common to open source projects:

  • Post in plain text, wrapped at around 72 characters.

  • Do not top-post. Reply below the relevant quoted text.

  • Start a new thread for each new bug. Do not reply to an unrelated message.

  • Keep the conversation on the list, not in private email to developers.