On 29.09.2016 21:44, John Ferlan wrote:
On 09/29/2016 11:04 AM, Peter Krempa wrote:
On Thu, Sep 29, 2016 at 10:30:07 -0400, John Ferlan wrote:
On 09/20/2016 04:10 AM, Viktor Mihajlovski wrote:
[...]
So, I have a question based on a little bit of testing I did with one of my guests and reading up on the qemu qapi-schema.json which states:
# Notes: @halted is a transient state that changes frequently. By the time the # data is sent to the client, the guest may no longer be halted.
It seems "halted" is returned whenever a vCPU is not actively processing anything (or not scheduled), which I suppose is "expected" for idle guests; however, if I used the vcpuinfo command and saw:
As it was pointed out in the previous posting the "halted" state has different meaning on certain arches. On intel it states that the cpu is idle and waiting. On s390 it is supposed to mean that the guest did not start using it yet.
Hence the sly comment to document the various differences!
Seems it may be more of an "idle" or "active" detector for x86 and if it were to be added, then a new "stats" value would be created rather than sharing/using the existing State which is really a detector of vcpu running or offline for most hypervisors (xen added BLOCKED).
# virsh vcpuinfo $dom VCPU: 0 CPU: 7 State: halted CPU time: 84.8s CPU Affinity: yyyyyyyy
I was worried that this exact change would happen at least for x86. I don't think we should do this. This would become misleading to many users.
...
I might be concerned that it's not "running" or "running (active)" vs. "running (inactive)" (or paused or waiting or something to indicate not actively processing/scheduled). The halted state could be the "norm".
Would your concerns be somewhat relieved by using a different term like "idle" or "running (idle)" which is what the state means on x86 for all
"halted" as reported by QAPI is definitely a state indication and as such does qualify IMO to be represented in virVcpuInfo. And on s390x it basically means offline, in the sense it will not be used by the OS. A state should not be re-interpreted as metric value just because of its volatility (which is platform dependent). I partly understand the concerns about potential confusion, which could be remedied by proper documentation or better terminology. practical purposes? -- 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