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)?
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
