+++ This bug was initially created as a clone of Bug #1745005 +++

+++ This bug was initially created as a clone of Bug #1745003 +++

+++ This bug was initially created as a clone of Bug #1717359 +++

What?
-----

On all compute nodes, by default, enable the libvirt log filter
("1:qemu") to capture the QMP (QEMU Machine Protocol) traffic.  This
will show the QMP request and response flow between libvirt and QEMU.


Why?
----

Often times, when debugging issues that involve interactions between
Nova, libvirt and QEMU, we need to understand the precise requests that
libvirt is sending to QEMU, and the corresponding responses from QEMU.
Since we don't capture these interactions by default, we request them[*]
_after_ a bug is reported, at which point it might not be possible to
capture them for various reasons, or worse, the machine might no longer
be available.

Having this log filter enabled can be extremely useful in debugging a
range of scenarios: live migration (with shared and non-shared storage),
live snapshots, "volume migration", and anything that involves libvirt
sending QMP commands to QEMU.

Note that we're only selectively enabling a targetted log filter
("1:qemu").  It will slightly increase the log file size, but nothing
crazy.  This slight increase in log file size is acceptable, given the
benefits.


How?
----

When deploying compute nodes, make sure that TripleO sets the below two
configuration attributes in `/etc/libvirt/libvirtd.conf`.  The "1:qemu" 
log filter will capture the QMP traffic between libvirt and QEMU in the
specified log file, `libvirtd.log`:

    ...
    log_filters="1:qemu"
    log_outputs="1:file:/var/log/libvirt/libvirtd.log"
    ...


[*] https://kashyapc.fedorapeople.org/virt/openstack/request-nova-libvirt-qemu-debug-logs.txt