Re: [libvirt] [PATCH 0/5] qemu: report actual vcpu state in virVcpuInfo
On Mon, Jul 18, 2016 at 07:56:36 +0200, Peter Krempa wrote:
On Thu, Jul 14, 2016 at 16:35:37 +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
> - adding a monitor function 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).
I'm going to pick this up in my work-in-progress series of adding vCPU
hot(un)plug using the new APIs in qemu and I'll let you know about the
issues once I see how well it integrates since it is touching the same
places.
So I was testing the data reported from the monitor while doing some
work on othe vCPU hotplug series and found that for x86 the halted state
is reported if the CPU is idle and thus halted. This state it therefore
almost always reported when the VM is idle.
Quoting conversation on previous version [1]:
> Could you please elaborat how you expect to use this info?
Dpending on the architecture, the halted state is an indication that the
virtual CPU is not in use. On s390x for example the halted state is only
reported if the CPU is stopped or in disabled wait, both indicating that
the virtual CPUs are not enabled for the operating system.
While for the s390 platform the state may reasonably express that the
vcpu is unused, other platforms have apparently different meaning.
Addditionally on x86_64 if the cpu is hotplugged but not grabbed by the
guest it is reporting non-halted state.
This information can be used by a libvirt client application for
hotplugging decisions, and this is in fact the intention.
Wouldn't it be possible for you to use the virDomainGetGuestVcpus [2]
API to determine this information more reliably using the guest agent?
I'm also a bit worried that the new state might cause problems with
older apps actually using the value for any reason.
Said that. I still keep the series in a branch and I'll post a updated
version including rebase on top of the oncomming vCPU hotplug series
once I finish it since it completely rewrites the exact part of the
monitor code requesting the information due to changes necessary to
detect hotpluggable cpus in recent qemu.
Peter
[1] https://www.redhat.com/archives/libvir-list/2016-July/msg00234.html
[2] http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetGuestVcpus