Hi Conny, On 2020-08-04 10:32, Cornelia Huck wrote: > On Tue, 4 Aug 2020 09:33:38 +0200 > Stefan Raspl <ra...@linux.ibm.com> wrote: > >> Hi Tim, >> Thanks for your feedback, your thoughts are greatly appreciated! >> >> On 2020-08-04 07:56, Timothy Sipples wrote: >>> Would this readout make better sense? >>> >>> $ zhypinfo >>> No Layer Type Name IFL CP >>> ------------------------------------------------------------------ >>> 2.2 z/VM_Guest guest myguest 2 0 >>> 2.1 z/VM_Resource_Pool pool pooltest 3 0 >>> 2.0 z/VM hypervisor myzvm 8 0 >>> 1 partition guest S38LP43 10 0 >>> 0 machine host S38 34 10 >>> >>> Then you wouldn't need two columns of numbers. The levels are simply >>> embedded in the sequence numbers. Counting would be consistent with the -l >>> and -L outputs, of course. Omitting the second column of numbers also >>> frees up more space for the text or even another column. >> >> Yeah, I'm all for keeping things short and sweet! Using that float-notation >> would require folks to parse out the info (i.e. the '2' from the first 3 >> rows) >> once again, which I could imagine might make things a bit tedious. Maybe we >> really don't need that first column to begin with, just print the 'level' >> column >> instead! > > Actually, looking at this, I found the '2.2' notation for a guest > confusing anyway... what would a guest inside a guest look like?
Probably 3.x >>> Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they >>> for parsing?) >> >> Exactly: By eliminating spaces, someone processing the output can count >> fields >> instead of relying on columns starting at a certain offset - makes things >> more >> robust. >> >>> Or maybe you don't even need the "guest"/"resource pool" >>> additions in the Layer column when you've already got a Type column and >>> decimalized sequence numbers. >> >> I see your point. But for environments like zCX, the nomenclature is not as >> obvious. Plus one can use the generic monikers along with the level info to >> address/query output independent of the actual hypervisor in use. >> >>> And would it make sense to print the >>> hypervisor release level in the Layer column, e.g. "z/VM 7.2"? >> >> Hmmmm, that would be nice! Problem is that z/VM is one of the few >> environments >> where we have that kind of info available - KVM or zCX don't :/ > > Where is that information coming from? Diag 318? It depends. qclib uses a number of sources for its data, including STHYI, Diag 204, STSI et al. >>> I don't like unnecessary jargon, so I highly prefer "partition" and >>> "machine." I thought about "physical," but sometimes the machine/CEC/CPC >>> isn't physical (zPDT, QEMU). Or use "base" if you prefer. But, honestly, >>> we really don't need 58 questions per month about what a CEC is, which >>> seems inevitable, doesn't it? So let's avoid that. >> >> That 'CEC' comes from qclib which referred to it that way ever since. Yeah, I >> know, weak argument. I would argue that zPDT emulates a CEC, so it is still >> there, just virtual. And QEMU is just a component of KVM, so it would appear >> as >> a 'KVM hypervisor' alike 'z/VM hypervisor' in the example (with LPAR and CEC >> (...) beneath it). > > What would the output for QEMU/tcg look like? (Where does qclib get its > information from? If it is something like STSI that we emulate, we have > a chance of getting something reasonable.) In any case, there wouldn't > be any layers below 'hypervisor'.> (Not relevant for production systems at > all, but I like interfaces to > be consistent... do you have anything people can play with?) tcg hasn't been a focus of qclib at all so far. Try https://public.dhe.ibm.com/software/dw/linux390/ht_src/qclib-2.1.0.tgz and run 'make test', that should do. > > (...) > >>> If the machine is reporting back something beyond the known model >>> generations, then you could print ">z15" or "z15+" or "z16?" until >>> zhypinfo is updated. When zhypinfo is updated you then insert the model >>> generation without the question mark and update the question mark to be >>> "z17?" (for example). Loop, repeat. >> >> Some of these suggestions could be easily mistaken as actual model names >> (e.g. >> "z15+" or "z16") while they are not - a very delicate matter. Plus, for >> various >> reasons, the unidentified ID might turn out not to be a later generation >> model, >> in which case we would give false info. So we should probably resort to >> "unknown", or maybe "UFC" (Unidentified Flying CEC) - just kidding. > > I'd like to see a flying CEC, even if it is unidentified :) > > Another thing maybe to consider is QEMU cpu models. If a guest is > running on a z<n> host, but the cpu model used for the VM is z<n-1>, > displaying a model of z<n> while the guest actually sees a z<n-1> could > be confusing. So far, we're only considering the CPU model visible to the guest, so we should be OK in this scenario. -- 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 / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
