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! > 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 :/ > 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). > And how about a little more insight in the Type column for partition and > machine? I actually have a separate tool to give info on the machine generation - it's been close to ready for a while, but never got around to release it yet. I'd include it next to this tool. > What happens with SMT2 v. SMT1 in this readout? (Should something happen?) Each SMT2-enabled core will appear as 2 logical CPUs. That stuff gets pretty complicated - one of the reasons why I was quite reluctant to publish any further tooling so far. We might get a lot more questions about CPU counts than about what a CEC is :O > Putting these suggestions all together except for the SMT2 one, plus some > others, here's what you might end up with: > > $ zhypinfo > # Layer Type Name IFLs CPs > ---------------------------------------------------------------- > 2.2 Linux 4.18 guest myguest 2 0 > 2.1 z/VM 7.2 pool pooltest 3 0 > 2.0 z/VM 7.2 hypervisor myzvm 8 0 > 1 partition z/VM S38LP43 10 0 > 0 machine z14 S38 34 10 > > I like "#" a little better as a column label (or maybe "Seq."), and I've > pluralized IFL and CP. Heh, I was dropping the plural 's' to conserve some space - I'll add it back in. > "Fun" question: what should a z/OS Container Extensions readout look like? Well, it has a "z/OS-hypervisor", possibly a "z/OS-tenant-resource-group", and finally a "z/OS-guest". > 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. -- 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
