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

[Boris Fiuczynski]

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:
>
> [...]
>
>>>  src/qemu/qemu_process.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>>> index f8f379a..675f5b5 100644
>>> --- a/src/qemu/qemu_process.c
>>> +++ b/src/qemu/qemu_process.c
>>> @@ -3349,8 +3349,7 @@ qemuProcessReconnect(void *opaque)
>>>      /* If upgrading from old libvirtd we won't have found any
>>>       * caps in the domain status, so re-query them
>>
>> At reconnect the capabilities are taken from the status XML file, where
>> they are saved for every instance specifically. This code is supposed to
>> run
>
> only when a very old version of libvirt did not save the capability
> flags into the status XML. It's even explained in the comment above.
>
>>
>>>       */
>>> -    if (!priv->qemuCaps &&
>>> -        !(priv->qemuCaps = virQEMUCapsCacheLookupCopy(caps,
>>> +    if (!(priv->qemuCaps = virQEMUCapsCacheLookupCopy(caps,
>>>                                                        driver->qemuCapsCache,
>>>                                                        obj->def->emulator,
>>>                                                        obj->def->os.machine)))
>>
>> NACK, this certainly is not the right fix. Does the status XML have the
>> 'query-hotpluggable-cpus' capability set? If it's so then it was
>> probably mis-detected at start of the VM and should be fixed there.
>>
>> If there is no such capability, then the reconnect code is broken
>> somehow.
>>
>> At any rate we should not re-detect the capabilities if they were
>> reloaded properly from the XML.
>>
>> Peter

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.
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 wrong and the machine type dependent masking result of the 
'query-hotpluggable-cpus' capability should be stored in the XML?


-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294