On Fri, 2 Feb 2018 15:54:15 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
The most important question I have is: does this solution satisfy the needs of upper management? That is, if we implement the solution suggested by Eduardo than the feature of automatically hotplugging more CPUs will only work for s390. Is this OK?
If yes, then I think this is the best solution. And the next question would be: Viktor, can you change this in libvirt while we fix query-cpus in QEMU?
The latest proposal was to use a flag for query-cpus (like full-state) which would control the set of properties queried and reported. If this is the way we decide to go, I can make the necessary changes in libvirt.
Regardless of whether we add that flag to query-cpus or not, we still have the general problem of solving the cross-architecture semantics to be more sane.
Let's the both then:
o Make qemuDomainRefreshVcpuHalted() s390-only in libvirt. This by itself fixes the original performance issue We are normally trying to avoid architecture-specific code in libvirt (not always successfully). We could omit the call, based on a QEMU Capability derived from the presence of said flag. This would change the
On 02.02.2018 17:01, Luiz Capitulino wrote: libvirt-client side default to not report halted. A client can the still request the value via a tbd libvirt flag. Which is what an s390-aware management app would have to do...
o Deprecate the "halted" field in query-cpus in QEMU. This fixes new instances of this same problem
That is probably OK, if we can get a replacement (e.g. a new state). -- Regards, Viktor Mihajlovski