[libvirt] QMP fallback race in libvirt

[Ron]

Hi,

Eric asked me to move this here from #virt so it doesn't get forgotten.

I hit a weird bug in a new install of libvirt on Debian Jessie this week
where a vm could not be configured to use any CPU type except passthrough.

After much digging and headscratching, the immediate cause for that turns
out to be one of the (three) files in the qemu/capabilities cache being
generated wrongly the first time that libvirtd was started.  Instead of
being generated from the QMP queries, it appears to have fallen back to
the old method of scraping 'qemu -cpu help', and since the output of that
changed with qemu 2.0 it leads to things like:

<cpu name='SandyBridge  Intel Xeon E312xx (Sandy Bridge)                '/>

and hilarity then ensues when cpuModelIsAllowed() is called by x86Decode().

Since only one of the cache files there was corrupted like this, it would
appear libvirt either didn't wait long enough, or didn't try hard enough,
to get a connection to the monitor for the QMP query on what was probably
also the very first time qemu had been started on this host machine.

After nuking the cache files and restarting libvirtd they were then
correctly regenerated, and things began to work as expected.

This was all done on a new clean install of the host machine, so there
was nothing around from any earlier versions to get tangled up with,
and possibly means qemu had some first time init of its own to do which
took some time before it was ready to be queried.


I am also seeing bursts of several of these warnings in the logs:

libvirtd[26475]: This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous

Which I haven't confirmed as being related, but doesn't seem to be
obviously unrelated either, and at worst is a separate bug.

  Cheers,
  Ron