On Tue, 4 Aug 2020 09:33:38 +0200 Stefan Raspl <[email protected]> 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? > > > 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? > > > 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?) (...) > > 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. ---------------------------------------------------------------------- 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
