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" > <[email protected] on behalf of [email protected]> 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 <distance > 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: [email protected] ------------------------------------------------------------------------------------------------------------------------------------------- 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 / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
