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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
