Description of problem:
Libvirt is spawning several qemu-kvm processes per guest, repeatedly gathering information such as 'qemu -help' output.  Caching this information will make libvirtd restarts faster.  Additionally, since this was one of the first patch series applied after upstream 0.10.2, and has a rather large refactoring effect on how qemu capabilities are managed, backporting the series now will make future backporting efforts easier to manage, as the upstream code base using capabilities will be similar to the RHEL 6.4 code base where fixes are being backported to.


Version-Release number of selected component (if applicable):
libvirt-0.10.2-1.el6

How reproducible:
100%

Steps to Reproduce:
1. start libvirtd with logging set to inspect all virCommand calls
2. start several guests running
3. notice how many times 'qemu-kvm -help' is executed
  
Actual results:
libvirt execs qemu-kvm several times per guest

Expected results:
qemu-kvm -help should be executed just once, at least until the qemu-kvm binary is updated

Additional info:
Backporting should pick up lots of danpb's patch series; for example, look at 'git log --oneline 1b21351b' for an idea of the patches in the series, which mixed two concepts of qemu-kvm capability caching and QMP capability determination.  We can't switch entirely to QMP parsing unless qemu also backports several new monitor commands, but Dan's code has been tested upstream to work even with older qemu.  So although it is not immediately obvious how easy it would be to disentangle the qemu capability caching from the interleaved commits related to dealing with the new monitor commands when present, it may make sense to backport even those patches that parse new monitor commands, even if that code isn't used on RHEL, just to minimize backport churn.