Re: [PATCH 0/9] extend virsh domstate to show additional information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Kletzander <mkletzan@xxxxxxxxxx> [2018-07-13, 10:50AM +0200]:
> I'm not very particularly opinionated on this, but I think APIs should be
> machine-readable and CLI tools can convert that to human-readable format.
> You'll never know when a program will like to access that and having to tell
> anyone in the future that they need to parse a string is ugly IMHO.

Ok, I can see the appeal for this. I agree that parsing the string is
not optimal, it just didn't occur to me that we maybe want to have this
information in other places as well.

So then I would model the new API function like Jiri suggested:

    int
    virDomainGetStateParams(virDomainPtr domain,
                            int *state,
                            int *reason,
                            virTypedParameterPtr *params,
                            int *nparams,
                            unsigned int flags)

where each parameter in params holds a piece of the additional
information, i.e VIR_DOMAIN_STATE_PARAMS_REASON_PSW_ADDR and so on on
s390x.

However, this raises the question how this would be handled on the
client, who now receives an unknown set of parameters. How would for
example virsh go on and reconstruct the info string? Just iterate of all
returned parameters? Or should it introspect the parameters and perform
an explicit formatting?

> Also from the monitor you can get that information only if there is any QEMU
> running.  I presume the state you are returning is saved somewhere along with
> the reason so that it can be provided later.

Yeah, in my QEMU-centric view I just assumed that this was an option.
For where this information is saved, if I understand you correctly, I am
not sure if I want to clutter this into the domain object where the
state and reasons (and, in this patch series, the info) is saved. I try
to find a way to retrieve this information from the hypervisor on the
fly.

I don't expect to much changes for the backend, so a general review of
the code if I am heading in the right direction.would be appreciated.

> --
> libvir-list mailing list
> libvir-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/libvir-list


-- 
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: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294 

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux