[libvirt] [PATCH] libvirt: qemu: Fix domain termination caused by query-hotpluggable-cpus not enabled

[Peter Krempa]

On Fri, Nov 25, 2016 at 14:25:33 +0100, Boris Fiuczynski wrote:
> On 11/25/2016 10:07 AM, Peter Krempa wrote:
> > On Fri, Nov 25, 2016 at 10:03:38 +0100, Peter Krempa wrote:
> > > On Fri, Nov 25, 2016 at 09:19:18 +0100, Boris Fiuczynski wrote:
> > 
> > [...]
> 
> Peter,
> looking at your commit message of 920bbe5c it reads as follows:
>     qemu: capabilities: Extract availability of new cpu hotplug for machine
> types
> 
>     QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
>     machine type. Extract and cache the information using the capability
>     cache.
> 
>     When copying the capabilities for a new start of qemu, mask out the
>     presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
>     doesn't support hotpluggable cpus.
> 
> The loaded XML has the 'query-hotpluggable-cpus' capability set since the
> qmp command exists in the list returned by the qmp command query-commands by
> the qemu binary.

In the global capabilities cache, the QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS
is set if the command is supported by qemu.

Once a VM is started we create a copy of the given capability set and
possibly filter out stuff that won't work and then store the filtered
capability set in the domain object.

> The machine type dependent masking of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS you
> are doing for a new start of qemu seems therefore also required to be done
> for reconnecting to this running qemu domain. Are you saying that this is

No. You can't do that at reconnect time. Once you start the VM you can
completely replace the original binary and thus you don't have data that
would allow to do such operation at reconnect time.

That is the main reason why we store the capabilities in the status XML
rather than reloading it from the cache.

> wrong and the machine type dependent masking result of the
> 'query-hotpluggable-cpus' capability should be stored in the XML?

Yes, exactly. As said, the capability set should not be re-detected for
the reasons stated above.

Said the above, there's something fishy going on. I compiled a qemu
binary that specifically doesn't support cpu hotplug and started a VM.
The status XML file does not show the flag:

# grep query-hotpluggable-cpus /var/run/libvirt/qemu/upstream.xml
#

But an attempt to restart libvirtd indeed ends up in the VM being
killed:

016-11-25 14:09:12.909+0000: 2610599: error :
qemuMonitorJSONCheckError:387 : internal error: unable to execute QEMU
command 'query-hotpluggable-cpus': The feature 'query-hotpluggable-cpus'
is not enabled

This means that the capabilities are not properly restored.

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161125/57a3a54f/attachment-0001.sig>