[libvirt] [PATCH v3 0/7] extend virsh domstate to show additional information

[Bjoern Walk]

So, what's my course of action here?

Daniel P. Berrangé <berrange at redhat.com> [2019-04-04, 11:32AM +0100]:
> I guess the obvious extra thing to want to report is CPU registers, since
> the crash info is largely containing register and/or memory address info.

Sounds reasonable if we go with the virDomainGetCPUState API.

> QEMU has "info registers" but no QMP variant of it at this time.

Can I still implement my stuff with the proposed API without the actual
register information until this is implemented in QEMU? Meaning, just
reporting the relevant register information from the panic event. While
it is nice to have the full feature set available, implementing the QMP
command for this would be a bit out of the scope of this proposal.

> With this in mind though, the proposed API is not satisfactory. Specifically
> the  field
> 
>   # define VIR_DOMAIN_STATE_PARAM_TYPE "info_type"
> 
> As that assumes an either / or reporting need.  If we added register
> info, then we would potentially need to report crash info *and* register
> info at the same time.
> 
> I think this is easy to solve though - just delete the
> VIR_DOMAIN_STATE_PARAM_TYPE field as it is redundant. Apps can just
> look at whatever named parameters exist & use those they care about.

Sure, the type parameter was basically an easy way for the client to
figure out what data it has retrieved, especially when the parameter
space was that large with all the (potential) different states.

> The more critical thing is that in an SMP system, we'll need to report
> registers per CPU, but this API is a per-VM level reporting.
> 
> This is something we do with virDomainGetCPUStats().
> 
> So I think we need a design closer to that API, and perhaps call it
> "virDomainGetCPUState"  / virsh  domcpustate

Any hint how this API actually should look like? Exactly like
virDomainGetCPUStats with the per-CPU-dance or should we just report
back all available information?

In the case of a panicked domain, how should we report the relevant
information (crashed core/reason)?

> Regards,
> Daniel

Thanks for the discussion and suggestions.

Bjoern

-- 
IBM Systems
Linux on Z & Virtualization Development
--------------------------------------------------
IBM Deutschland Research & Development GmbH
Schönaicher Str. 220, 71032 Böblingen
Phone: +49 7031 16 1819
--------------------------------------------------
Vorsitzende des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 902 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190405/395add42/attachment-0001.sig>