Sometimes you must be able to analyse Qemu more in-depth than the log files allow to.
For this, one can attach a <code>gdb</code> instance to a running Qemu process if it is started with the <code>-s</code> option.== Using GDB ==
For this, one can attach a [https://www.gnu.org/software/gdb/ GDB] instance to a running Qemu process as long as it is started with the <code>-s</code> option. To pass the required option from libvirt down to Qemu, one can use an additional namespace to pass along options to Qemu as descripted described [http://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-s in the libvirt wiki].
Simply replace at the beginning of the XML (for example when editing using <code>virsh edit</code>):
and then start the VM.
The [https://www.gnu.org/software/gdb/ GDB ] session then looks like thisto attach to the process and continue to run it until you hit a bug:
<pre>
Continuing.
</pre>
== Generate core dumps ==
<source lang='bash'>
mkdir -p /var/virtualization/core-dumps
chmod 1777 /var/virtualization/core-dumps
echo "/var/virtualization/core-dumps/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern
ulimit -c unlimited
/etc/init.d/libvirtd reload
</source>
... after that, all newly started Qemu processes will generate a (unique) core dump file in <code>/var/virtualization/core-dumps</code> in case they crash
[[Category:Snippets]]