Re: [libvirt] [PATCH V3 0/4] qemu: report actual vcpu state in virVcpuInfo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12.10.2016 14:42, Peter Krempa wrote:
On Wed, Oct 12, 2016 at 14:06:14 +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
[1]
> - extending the monitor 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).
>
> V2 is a rebase on top of Peter Krempa's CPU hotplug
> modernization.
>
> V3 tries to address the review comments by John and Peter.
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.
As I've already pointed out, this would be the most common state on
x86 so basically everybody would see it and we were reporting
"RUNNING" for
This is only true from a QEMU (x86) POV. Xen was always
capable of
reporting "blocked" (and, fwiw "offline") as well. If I interpret you
correctly, you are not inclined to accept anything other than
"running" for QEMU. Which makes it a pretty dull exercise to query the
value at all, no?
ages. I still think this should be added as a separate indicator
(if at all). One possibility would be to add in into the bulk stats
API since the current structure can't be extended.
If that should be the way, patches 2/4 and 3/4 would still be the core
of it and I would sincerely welcome a review of those.
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.
[...]
- --
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJX/jkiAAoJEIZFfh8x4fgda5UP/AorvKJFOOYSSkjZJ134bwvS
qGspiDcqCW84KNSIvFoaWBVFCZ0I6CUoUNgjC3/8HsAbyHIW43NP/cG5mkOfwJIH
XslGG2b77EcSP+Xa7DXAeTdJg9qR47KfTV0hY6wxVljyx/v9ITbWKdVCduycve8d
ia+oaiOI+GI4QNxR6K5na5sLRb0U2az0tR0QqpzRT0JJ6t89VJl1QC0nikCIdaRg
4uqQR1UxbhAcc/bAYNDhPEKDuKD9gkF80ETDd3UusalWhNWZGi8f0qwx3BtZEvrO
05XYRMHVKXoTaKyB6ki2XC6i9fE1EgnK+fCG2N+lnwUDNxdCr+cmW7tATFME3VAm
4JUj/TWDCwmsSJrfRrwiA4b5GR+mjeZ5JWYJBJ4nyOUWe7oqJNJY+0P3Ni7BplUP
LeX24AGmDUkOvA/X2ORpv24B8oxO/ROXjtnUJ9ajiMRJvPj5VJNZlN3wASK9TFmB
SFoSLmfydFh0sfl7RhIMFDWf0LSeVJheC/qHz901kGPRwAJ6CpFsDMWj3vOazGqg
hH9oBAJ7EnH9OdL0KJCIPHFaPtpFoNGmH9Q6t4q4l+/yos5g6KF9mQMiJrz5g2sc
3dLt+yOerPTcfKPAkrDetBlwd4xzTtBA5WrgsWbxjpaRs+fOMgX/pO5jncuW70cy
5NeFkJoGPxooGH1DXvHz
=AsM2
-----END PGP SIGNATURE-----