Reporting Bugs against Xen Project

How to Report a Bug Against the Xen Project Hypervisor

If you are having a problem with the Xen Project Hypervisor or tools then please consider initially posting to the xen-users mailing list (list info), in order to rule out common configuration issues and user errors. You should still include all of the information which is suggested here so that people can best advise you.

The primary location for reporting bugs against the hypervisor and associated bundled tools (e.g. against xen.git, xen-unstable.hg or xen-X.Y-testing.hg) is by posting to the xen-devel mailing list (list info). Please tag your subject line with a '[BUG]' prefix. Note that you do not need to be subscribed to the list to post (although non-subscribers are moderated this usually happens pretty quickly) and that list policy is to CC people so you shouldn't miss any replies.

If you think the bug might have a security impact then please report to security (at) xenproject (dot) org and not to xen-devel. This will allow us to conduct a responsible disclosure according to our Security Problem Response Process.

Please read the following before posting.

Although a bugzilla instance does exist it is not well maintained or widely used by developers. If you really want to file a bug in bugzilla you are strongly recommended to also post to the mailing list.

Issues with XCP and user questions are better addressed to the xen-api list rather than xen-users or xen-devel. See list info for more details. Also see Reporting Bugs against_XCP.

Before posting a bug report you are strongly encouraged to read Simon Tatham's excellent "How to Report Bugs Effectively". Please do not report Xen bugs to Simon Tatham!

Before posting you should check your favourite search engine, xen markmail or the list archives for both xen-users and xen-devel to see if your issue has been reported (and perhaps solved) already.

List Etiquette

xen-devel, like many open-source mailing lists, keeps to a set of conventions established in the '80s and '90s. They may seem a bit archaic these days, but breaking them is considered bad form and may cause people to skip over your bug report. There are a number of guides on the web, but some particular points that seem to show up on xen-devel are:

• Please post in plain text (i.e. not HTML), word-wrapped to somewhere around 72 characters.
• Please don't top-post.
• Please start a new thread for a new bug (don't just reply to a random email from the list).
• Please don't email bugs directly to xen developers. Keep the conversation on the list where other people (and search engines) can see it.

Bug Report Contents

The following contains suggestions of the sort of information, log files and command output you should consider providing as part of your bug report. If you are unsure then it is normally better to err on the side of providing too much information.

General

First and foremost please provide a clear description of the issue you are seeing. What exactly happened and what did you expect. Try to be as clear as you can, properly explaining your issue is key to us being able to help. See "How to Report Bugs Effectively" (which you have already read, right?) for examples of the sorts of bug reports which are not likely to garner a response from developers, as well as advice on how to produce a good bug report.

Also please always include the precise version of Xen you are running, i.e. a reference to the particular mercurial tree and a changeset number or the name of the distribution which provided the packages you are using along with the version of those packages.

Where possible, please include precise steps to reproduce the issue. An issue which can be reproduced by a developer is an order of magnitude more likely to get fixed quickly.

Be sure to also include any relevant domain configuration files.

In addition there are many log files which can contain useful information:

• /var/log/xen/xen-hotplug.log
• /var/log/xen/qemu-dm-${DOMNAME}.log

• Host console output (perhaps including hypervisor debug key output)
• Guest console output (often in /var/log/xen/console)

Finally various bits of system configuration can be found in:

• /etc/network/interfaces or /etc/sysconfig/network-scripts/*
• /etc/xen/*
• Network device configuration: ifconfig -a
• Network bridging configuration: brctl show
• Network routing configuration: route -vn
• PCI devices: lspci -vvv
• Xenstore contents: xenstore-ls -fp

xl specific

If you are using the xl toolstack then please consider running all xl commands with the global "-v" option e.g. xl -v create <create-options>. Also please include the output of the following commands:

• xl info

In addition you should include the logs from /var/log/xen/xl-${DOMNAME}.log

xend specific

If you are using the xend toolstack then there are several other log files which may be of interest.

• /var/log/xen/xend.log
• /var/log/xend-debug.log
• /var/log/xen/domain-builder-ng.log

Host console logs

Before capturing logs make sure you're using "loglvl=all guest_loglvl=all" Xen hypervisor (xen.gz) boot options in your bootloader (grub) settings! Reboot after making changes to bootloader settings.

It is often useful, especially with hypervisor or dom0 kernel bugs, to include a serial console log. If the bug does not result in a crash then these logs can be retrived using

xl dmesg > hypervisor.log
dmesg > dom0.log

However if the bug results in a crash then a serial console may be useful. Instructions on setting up a serial console can be found on the Xen Serial Console page.

If a serial console is not an option then adding noreboot to the hypervisor command line will cause the system to pause on crash allowing you to take a photo of the screen or to transcribe the error into an email.

Guest console logs

For issues with booting guests etc it can be useful to capture the guest's console log.

Logging of guest consoles can be enabled by setting:

   XENCONSOLED_TRACE=guest

in /etc/sysconfig/xencommons or /etc/defaults/xencommons (whichever is appropriate for your distro) or some by using some other appropriate distro specific option to add --log=guest to the xenconsoled command line.

After changing this configuration you will need to restart xenconsoled. After this any newly started guests will have their console logged in

• /var/log/xen/console/guest-${DOMNAME}

Linux paravirt ops kernel issues

You should also provide the information requested on the XenParavirtOpsHelp page.