[libvirt] [PATCH V3 0/4] qemu: report actual vcpu state in virVcpuInfo

[Viktor Mihajlovski]

On 13.10.2016 00:46, John Ferlan wrote:
[...]
>>>>
>>>> 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.
> 
>> I think the objection is for the vcpuinfo command which shouldn't need
>> to be CPU aware, but perhaps similar to how aware the hotplug code had
>> to be made for the differences between arch's, maybe the info code needs
>> that as well (as ugly as that could be). I'm just trying to throw some
>> suggestions out there to see if anything sticks.
> 
>> It's painful that the "halted" bit has multiple meanings, but I think
>> it's handle-able - we just have to find the right way to do it...
> 
I think it's not libvirt's task to interpret the meaning of halted as
reported by QEMU. That's why I added the new state in the first place
instead of reusing e.g. offline, which would have introduced
architecture depend code which I'd like to avoid where possible.
>> Another "thought" that strikes me is whether there's a "valid" scenario
>> where someone can halt a CPU from the guest and how that gets propagated
>> back - even on x86. OK it's a slight divergence...
> 
>> While I did suggest some sort of running (halted) output, does seeing
>> that on for a non x86 guest make sense for the state the CPU is in? In a
>> former job, I think we called it "running (idle)" mainly because
>> "halted" has a somewhat negative connotation.
> 
>> So another option might be to allow a vcpuinfo user to pass a new flag
>> that would allow that return of this more detailed state. Only if the
>> flag was set would we check/return the new state. I think that's what
>> we've done in the past for similar things where changing the "default"
>> return/display value could cause "issues" for those programs that rely
>> on the string being "running" without " (halted)" or " (idle)".  Does
>> this make sense?
>
In essence that would mean to implement a new API, which seems to be too
heavy a hammer for this small nail.
>> Then for the other (stats) output, returning the value of the "halted"
>> field could be an "additional" set of output/data to be added rather
>> than overloading the existing field. Does this make sense?
> 
> 
That's what I'll do, expect a new series soon...
[...]
> 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
> version.
> [...]
> 
>> I do like the adjustments made to virsh.pod.
> 
There you go...
>> John
> 
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
> 

-- 

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