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

>>> >>> 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...

> 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?

> 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?

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.

> John > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >