Hi Ingo, On 2020-08-04 13:07, Ingo Adlung wrote: > This said, Stefan, would capacity group capping at the LPAR level show up > as 1.1? And how would you distinguish dedicated from shared capacity (at > any level)?
Yes, LPAR groups are supported and would show up between CEC and LPAR - I just left them out to keep things somewhat simple. No distinction between dedicated and shared engines so far - the initial request was about the virtualization layers/names, I just threw this in as a goodie as I know there was at least one guy internally who thought we should have something like that. However, I'm somewhat reluctant to add too much info there - it just gets very complicated very fast (SMT-2 anybone?!), and I'm not asking for trouble. Again, if somebody wants to have exotic content, I'd refer to the json output or qclib proper. Ciao, Stefan > Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 04/08/2020 11:54:37: > >> From: Stefan Raspl <ra...@linux.ibm.com> >> To: LINUX-390@VM.MARIST.EDU >> Date: 04/08/2020 11:54 >> Subject: [EXTERNAL] Re: [LINUX-390] VM system name >> Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> >> >> 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 nomenclatureis > 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.tgzand >> 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 >> https://urldefense.proofpoint.com/v2/url? >> > u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIFaQ&c=jf_iaSHvJObTbx- > >> siA1ZOg&r=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI- >> y49pWL0&m=1Vxel2ONYBkgqKqQQvGYAZDIthPDfj9u3am- >> j2FNoh0&s=ZV3OBBVUQ7aSoAbdY7qjxVJiIQwkIcWDdhfC6rrGadk&e= >> > > Mit freundlichem Gruß / Best regards > Ingo Adlung > > > > Ingo Adlung IBM Deutschland Research & > IBM Distinguished Engineer Development GmbH > Chief Architect, and CTO Vorsitzender des Aufsichtsrats: > IBM Z and LinuxONE Virtualization Gregor Pillen > & Linux Geschäftsführung: Dirk Wittkopp > mail: adl...@de.ibm.com Sitz der Gesellschaft: Böblingen > phone: +49-7031-16-4263 Registergericht: Amtsgericht > Stuttgart, HRB 243294 > IBM Privacy Statement > https://www.ibm.com/privacy/us/en/ > IBM Datenschutzerklärung > https://www.ibm.com/privacy/de/de/ > > > > > > > ---------------------------------------------------------------------- > 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 > -- 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
