Hash: SHA1

On 12.10.2016 14:42, Peter Krempa wrote:
> On Wed, Oct 12, 2016 at 14:06:14 +0200, Viktor Mihajlovski wrote:
>> Currently, the virVcpuInfo returned by virDomainGetVcpus() will
>> always report a state of VIR_VCPU_RUNNING for each defined domain
>> vcpu even if the vcpu is currently in the halted state.
>> As the monitor interface is in fact reporting the accurate state,
>> it is rather easy to transport this information with the existing
>> API.
>> This is done by - adding a new state of VIR_VCPU_HALTED
> [1]
>> - extending the monitor to pass back the halted state for the
>> vcpus - adding a new field to the private domain vcpu object
>> reflecting the halted state for the vcpu - modifying the driver
>> code to report the vcpu state based on the halted indicator -
>> extending virsh vcpuinfo to also display the halted state
>> The vcpu state is however not recorded in the internal XML
>> format, since the state can change asynchronously (without
>> notification).
>> V2 is a rebase on top of Peter Krempa's CPU hotplug
>> modernization.
>> V3 tries to address the review comments by John and Peter.
> Despite fixing user strings in this version to show the word
> 'running' the enum value [1] is still changed for the new one.
> Since the actual value is used by programs and not humans that may
> break and I'm not comfortable allowing such change in semantics.
Hm, really? From an API perspective up to now it was perfectly OK to
accept any of "offline", "running" and "blocked".
I maintain that it is valid to extend the state enumeration and virsh
shows how to handle previously unknown states.
> As I've already pointed out, this would be the most common state on
> x86 so basically everybody would see it and we were reporting
> "RUNNING" for
This is only true from a QEMU (x86) POV. Xen was always capable of
reporting "blocked" (and, fwiw "offline") as well. If I interpret you
correctly, you are not inclined to accept anything other than
"running" for QEMU. Which makes it a pretty dull exercise to query the
value at all, no?
> ages. I still think this should be added as a separate indicator
> (if at all). One possibility would be to add in into the bulk stats
> API since the current structure can't be extended.
If that should be the way, patches 2/4 and 3/4 would still be the core
of it and I would sincerely welcome a review of those.
And, if you find value in the virsh.pod update in 1/4, you can either
pick the parts you need or let me know and I can provide an abridged

- -- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

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

Version: GnuPG v2.0.22 (GNU/Linux)


libvir-list mailing list

Reply via email to