Run <code>virt-install</code> using the <code>--debug</code> option to get detailed debug spew. 

Run <code>virt-install</code> using the <code>--debug</code> option to get detailed debug spew. 

−

In order to gain access to a serial console during the install, you can use <code>-x "console=ttyS0".  Using a serial console combined with a VNC install can be very useful for debugging e.g. <code>--nographics -x "console=ttyS0 vnc"</code>

+

In order to gain access to a serial console during the install, you can use <code>-x "console=ttyS0"</code>.  Using a serial console combined with a VNC install can be very useful for debugging e.g. <code>--nographics -x "console=ttyS0 vnc"</code>

Effective bug reporting

Reporting bugs effectively is an important skill for any Fedora user or developer. 

Narrowing down the possible causes of the bug and providing the right information in the bug report allows a bug to be resolved quickly.  Filing a bug report with little useful information can mean that your bug lays unresolved, possibly until it is closed automatically when the distribution version reaches "end of life". 

Virt Manager

Examine the log file and include any pieces that look like they might be useful in the bug report.  If in doubt, attach the whole file to the bug. 

You can also run virt-manager from the command line using virt-manager --no-fork and check whether any relevant messages were printed there. 

virt-install

Run virt-install using the --debug option to get detailed debug spew. 

In order to gain access to a serial console during the install, you can use -x "console=ttyS0".  Using a serial console combined with a VNC install can be very useful for debugging e.g. --nographics -x "console=ttyS0 vnc"

libvirt

Any program using libvirt can be debugged using the LIBVIRT_DEBUG=1 environment variable e.g.

kvm

The output of any qemu-kvm command run by libvirtd is stored in /var/log/libvirt/qemu/GuestName.log. 

xen

If a guest is crashing you can obtain a stack trace by doing the following:

Set "on_crash=preserve" in your domain config

Copy the guest kernel's System.map to the host

Once the guest has crashed, run /usr/lib/xen/bin/xenctx -s System.map <domid>

General Tips

System Log Files

Always look in dmesg, /var/log/messages etc.  for any useful information. 

strace

strace can often shed light on a bug - e.g. if you run virt-manager, or libvirtd or qemu-kvm under strace you can see what files they accessed, what commands they executed, what system calls they invoked etc.: 

$> strace -ttt -f libvirtd

If the program in question is already running, you can attach to it using strace -p. 

gdb

gdb can often be useful to trace the execution of a program.  However, in order to get useable information, you will need to install "debuginfo" packages.  See the StackTraces page for more information. 

SELinux

If you see "AVC denied" or "setroubleshoot" messages in /var/log/messages, your bug might be caused by an SELinux policy issue.  Try temporarily putting SELinux into "permissive" mode with:

$> setenforce 0

If this makes your bug go away that doesn't mean your bug is fixed, it just narrows down the cause!  You should include the AVC details in the bug report, or if the message includes a sealert -l command then include the details printed by the command.