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

[Viktor Mihajlovski]

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).
> 
"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.
>>>
>>> # 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
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