Hi David,
Thanks for your considerations, greatly appreciated!
On 2020-07-30 02:28, David Boyes wrote:
> On 7/22/20, 9:29 AM, "Linux on 390 Port on behalf of Stefan Raspl"
> wrote:
>> Would people find it helpful if a command is introduced to the
>> s390-tools package that will return one or more of the following data
>> points:
>> 1. z/VM or KVM Guest name
>> 2. z/VM Host name
>> 3. KVM Host name
>> 4. LPAR name
>> 5. CEC name
>
> Some thoughts on this, in no particular order:
>
> 1. The output from qc_test you showed should require a --verbose option. Most
> uses for this data will programmatic, so something like 1 line per level,
> space delimited would be most useful. If you can parse it easily with classic
> Bourne shell, you got it right.
>
> Example:
>
> ./qc_test without --verbose produces:
>
> 0 guest 5 1 GUEST43 off 0 0 undef undef 1 1 0 0 0 1 0 1 undef undef
> 1 pool 4 3 pooltest 0 0 0 0 1 64467763 undef undef undef
> 2 hyper 3 2 "MY_ZVM" undef "z/VM 6.3.0" 500 1 0 3 0 3 1 0 1 2 undef undef
> 3 lpar
> 4 cec .
> .
> etc on stdout. The --verbose version can show all the human friendly labels
> and formatting.
qc_test is not externalized so far and primarily intended as a debugging
aid/demo for the actual library. I was sort of testing the waters to see if
providing its format would have some merit - but it likely does not.
However, I like your idea, and I believe we could provide a more elaborate
output that could be used for scripting and further processing!
Not so sure about the format, though - the one above is hard to read, and I
would claim it might be prone to produce errors on all parties involved - e.g.
whenever we add further fields. Something that correlates the values to a field
name is preferable - maybe something like JSON could do the job here!
> 2. Most uses of this will be most interested in the layer closest to them, eg
> starting at the VM guest level and going outward (the reverse of how your
> example is formatted).
Yup, I agree.
> 3. It might be useful to say "I'm not interested in data that is more than X
> levels from me" to reduce processing, ie something like --maxlevel from me>. ./qc_test --maxlevel 2 from the example above would return data
> from guest, pool and hypervisor, but drop anything beyond.
One could always do that by post-processing the output. Also, this would need
some semantics: We should likely count virtalization layers, not levels. Because
e.g. z/VM can or can not have a Resource Pool defined. As one does not know in
advance, it should not be counted. But then again, that makes it a bit more
complicated. I'd likely push that out as a future item.
> 4. An option to return only the number of virtualization levels present would
> be helpful to set loops, eg ./qc_test --levels in your example returns 5 as
> its only output.
Something like that is already available in the underlying library, although it
counts levels/layers, not _virtualization_ levels. Makes sense to keep it that
way.
> 5. a flag to test for multiple CPU types or not would be helpful (you can get
> what they are from the whole output, just a 1/0 flag to indicate the presence
> of a mixed LPAR), in a LPAR with both IFLs and standard engines ./qc_test
> --mixed would return 1 so you need to go look at the full data to find out
> the whole picture, or you could return the counts of processors of each type
> after the 1/0 if you felt like it.
There's a field like that available, but not in every layer. However, this is
really easy to derive from the output, so not sure if I'd want to add it...
> 6. (nit) in the verbose output, provide a way to provide a format string
> option, eg:
>
> ./qc_test --verbose --format="30:8.3"
>
> qc_capability [S ] : 552.000
> qc_secondary_capability [S ] : 552.000
> qc_capacity_adjustment_indication [S ]: 100.000
> qc_capacity_change_reason [S ]: 0.000
Uh, yeah, well, another 'future' I would say.
> I'd find a utility like that very useful indeed.
Thanks for your response, I'm pretty sure I'll come up with something in the not
too distant future!
--
Mit freundlichen Grüßen / Kind regards
Stefan Raspl
Linux on Z & Virtualization Development
---
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2177
E-Mail: stefan.ra...@de.ibm.com
---
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats:
Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
--
For LINUX-390 subscribe / signoff /
