Re: VM system name

[Rich Smrcina]

VM00 Name.

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 


> On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP)  wrote:
> 
> When I look at /proc/sysinfo, I can see the LPAR name but I don’t see the VM 
> system name.  Is there a place that the VM system name would be shown from 
> linux?
> 
> LPAR Number:  2
> LPAR Characteristics: Shared
> LPAR Name:PLB2
> LPAR Adjustment:  390
> LPAR CPUs Total:  32
> LPAR CPUs Configured: 32
> LPAR CPUs Standby:0
> LPAR CPUs Reserved:   0
> LPAR CPUs Dedicated:  0
> LPAR CPUs Shared: 32
> LPAR CPUs G-MTID: 0
> LPAR CPUs S-MTID: 1
> LPAR CPUs PS-MTID:1
> 
> VM00 Name:DMZLA004
> VM00 Control Program: z/VM6.4.0
> VM00 Adjustment:  15
> VM00 CPUs Total:  1
> VM00 CPUs Configured: 1
> VM00 CPUs Standby:0
> VM00 CPUs Reserved:   0
> 
> 
> 
> 
> Regards, Phil Tully
> 
> 
> --
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, notify the sender immediately by return 
> email and delete the message and any attachments from your system.
> 
> 
> --
> 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


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

Re: VM system name

[Rich Smrcina]

vmcp q userid ?

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 


> On Jul 8, 2020, at 11:23 AM, Tully, Phil (CORP)  wrote:
> 
> Rich, 
> That is the virtual machine name, not the VM system name.
> 
> Regards, Phil Tully
> Chief Architect-z/VM & z/Linux
> phil.tu...@adp.com 
> cell: 973-202-7427
> 1-800 377-0237,,5252697#
> 
> 
> 
> On 7/8/20, 12:16 PM, "Linux on 390 Port on behalf of Rich Smrcina" 
> mailto:LINUX-390@VM.MARIST.EDU> on behalf of 
> r...@velocitysoftware.com > wrote:
> 
> 
>WARNING: Do not click links or open attachments unless you recognize the 
> source of the email and know the contents are safe. 
> 
>**
>VM00 Name.
> 
>Rich Smrcina
>Sr. Systems Engineer
> 
>Velocity Software Inc.
>Main: (650) 964-8867
>Main: (877) 964-8867
>r...@velocitysoftware.com  
> >
> 
> 
>> On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP)  wrote:
>> 
>> When I look at /proc/sysinfo, I can see the LPAR name but I don’t see the VM 
>> system name.  Is there a place that the VM system name would be shown from 
>> linux?
>> 
>> LPAR Number:  2
>> LPAR Characteristics: Shared
>> LPAR Name:PLB2
>> LPAR Adjustment:  390
>> LPAR CPUs Total:  32
>> LPAR CPUs Configured: 32
>> LPAR CPUs Standby:0
>> LPAR CPUs Reserved:   0
>> LPAR CPUs Dedicated:  0
>> LPAR CPUs Shared: 32
>> LPAR CPUs G-MTID: 0
>> LPAR CPUs S-MTID: 1
>> LPAR CPUs PS-MTID:1
>> 
>> VM00 Name:DMZLA004
>> VM00 Control Program: z/VM6.4.0
>> VM00 Adjustment:  15
>> VM00 CPUs Total:  1
>> VM00 CPUs Configured: 1
>> VM00 CPUs Standby:0
>> VM00 CPUs Reserved:   0
>> 
>> 
>> 
>> 
>> Regards, Phil Tully
>> 
>> 
>> --
>> This message and any attachments are intended only for the use of the 
>> addressee and may contain information that is privileged and confidential. 
>> If the reader of the message is not the intended recipient or an authorized 
>> representative of the intended recipient, you are hereby notified that any 
>> dissemination of this communication is strictly prohibited. If you have 
>> received this communication in error, notify the sender immediately by 
>> return email and delete the message and any attachments from your system.
>> 
>> 
>> --
>> 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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
>>  
>> 
>>  
> 
> 
>--
>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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
>  
> 
>  
> 
> 
> 
> --
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, notify the sender immediately by return 
> email and delete the message and any attachments from your system.
> 
> 
> --

Re: VM system name

[Alan Altmark]

On Wednesday, 07/08/2020 at 04:12 GMT, "Tully, Phil (CORP)" 
 wrote:
> When I look at /proc/sysinfo, I can see the LPAR name but I don’t see 
the VM
> system name.  Is there a place that the VM system name would be shown 
from
> linux?
>
> LPAR Number:  2
> LPAR Characteristics: Shared
> LPAR Name:PLB2
> LPAR Adjustment:  390
> LPAR CPUs Total:  32
> LPAR CPUs Configured: 32
> LPAR CPUs Standby:0
> LPAR CPUs Reserved:   0
> LPAR CPUs Dedicated:  0
> LPAR CPUs Shared: 32
> LPAR CPUs G-MTID: 0
> LPAR CPUs S-MTID: 1
> LPAR CPUs PS-MTID:1
>
> VM00 Name:DMZLA004
> VM00 Control Program: z/VM6.4.0
> VM00 Adjustment:  15
> VM00 CPUs Total:  1
> VM00 CPUs Configured: 1
> VM00 CPUs Standby:0
> VM00 CPUs Reserved:   0

/proc/sysinfo provides you with the response from STORE SYSTEM INFORMATION 
(STSI) instruction.  It does not include the z/VM system ID.  The CP QUERY 
USERID command is the only API in the system that I'm aware of that 
returns (by design) the system ID.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


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

Re: VM system name

[Ronald van der Laan]

STore HYpervisor Information returns system name and ssi name of the top 3
levels of hypervisors.

Op wo 8 jul. 2020 om 18:42 schreef Alan Altmark 

> On Wednesday, 07/08/2020 at 04:12 GMT, "Tully, Phil (CORP)"
>  wrote:
> > When I look at /proc/sysinfo, I can see the LPAR name but I don’t see
> the VM
> > system name.  Is there a place that the VM system name would be shown
> from
> > linux?
> >
> > LPAR Number:  2
> > LPAR Characteristics: Shared
> > LPAR Name:PLB2
> > LPAR Adjustment:  390
> > LPAR CPUs Total:  32
> > LPAR CPUs Configured: 32
> > LPAR CPUs Standby:0
> > LPAR CPUs Reserved:   0
> > LPAR CPUs Dedicated:  0
> > LPAR CPUs Shared: 32
> > LPAR CPUs G-MTID: 0
> > LPAR CPUs S-MTID: 1
> > LPAR CPUs PS-MTID:1
> >
> > VM00 Name:DMZLA004
> > VM00 Control Program: z/VM6.4.0
> > VM00 Adjustment:  15
> > VM00 CPUs Total:  1
> > VM00 CPUs Configured: 1
> > VM00 CPUs Standby:0
> > VM00 CPUs Reserved:   0
>
> /proc/sysinfo provides you with the response from STORE SYSTEM INFORMATION
> (STSI) instruction.  It does not include the z/VM system ID.  The CP QUERY
> USERID command is the only API in the system that I'm aware of that
> returns (by design) the system ID.
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> IBM Systems Lab Services
> IBM Z Delivery Practice
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
>
>
> --
> 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
>
-- 
Ronald van der Laan

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

Re: VM system name

[Rogério Soares]

I use here https://github.com/openmainframeproject/qclib

return many cool info as well SYSTEM NAME, on layer 2 listing on field:
qc_layer_name


  = Layer 2: z/VM-hypervisor
=
 qc_layer_type [n/a]: z/VM-hypervisor
 qc_layer_category [n/a]: HOST
 qc_layer_type_num [n/a]: 3
 qc_layer_category_num [n/a]: 2
* qc_layer_name [  V]: Z01PROD1*




On Wed, Jul 8, 2020 at 1:15 PM Rich Smrcina 
wrote:

> VM00 Name.
>
> Rich Smrcina
> Sr. Systems Engineer
>
> Velocity Software Inc.
> Main: (650) 964-8867
> Main: (877) 964-8867
> r...@velocitysoftware.com 
>
>
> > On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP) 
> wrote:
> >
> > When I look at /proc/sysinfo, I can see the LPAR name but I don’t see
> the VM system name.  Is there a place that the VM system name would be
> shown from linux?
> >
> > LPAR Number:  2
> > LPAR Characteristics: Shared
> > LPAR Name:PLB2
> > LPAR Adjustment:  390
> > LPAR CPUs Total:  32
> > LPAR CPUs Configured: 32
> > LPAR CPUs Standby:0
> > LPAR CPUs Reserved:   0
> > LPAR CPUs Dedicated:  0
> > LPAR CPUs Shared: 32
> > LPAR CPUs G-MTID: 0
> > LPAR CPUs S-MTID: 1
> > LPAR CPUs PS-MTID:1
> >
> > VM00 Name:DMZLA004
> > VM00 Control Program: z/VM6.4.0
> > VM00 Adjustment:  15
> > VM00 CPUs Total:  1
> > VM00 CPUs Configured: 1
> > VM00 CPUs Standby:0
> > VM00 CPUs Reserved:   0
> >
> >
> >
> >
> > Regards, Phil Tully
> >
> >
> > --
> > This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
> >
> >
> > --
> > 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
>
>
> --
> 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
>

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

Re: VM system name

[Rogério Soares]

Ooops.. sorry in field   qc_cluster_name

= Layer 2: z/VM-hypervisor =
 qc_layer_type [n/a]: z/VM-hypervisor
 qc_layer_category [n/a]: HOST
 qc_layer_type_num [n/a]: 3
 qc_layer_category_num [n/a]: 2
 qc_layer_name [  V]: Z01PROD1
   qc_cluster_name [  V]: SSIPROD



On Wed, Jul 8, 2020 at 1:55 PM Rogério Soares 
wrote:

> I use here https://github.com/openmainframeproject/qclib
>
> return many cool info as well SYSTEM NAME, on layer 2 listing on field:
> qc_layer_name
>
>
>   = Layer 2: z/VM-hypervisor
> =
>  qc_layer_type [n/a]: z/VM-hypervisor
>  qc_layer_category [n/a]: HOST
>  qc_layer_type_num [n/a]: 3
>  qc_layer_category_num [n/a]: 2
> * qc_layer_name [  V]: Z01PROD1*
>
>
>
>
> On Wed, Jul 8, 2020 at 1:15 PM Rich Smrcina 
> wrote:
>
>> VM00 Name.
>>
>> Rich Smrcina
>> Sr. Systems Engineer
>>
>> Velocity Software Inc.
>> Main: (650) 964-8867
>> Main: (877) 964-8867
>> r...@velocitysoftware.com 
>>
>>
>> > On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP) 
>> wrote:
>> >
>> > When I look at /proc/sysinfo, I can see the LPAR name but I don’t see
>> the VM system name.  Is there a place that the VM system name would be
>> shown from linux?
>> >
>> > LPAR Number:  2
>> > LPAR Characteristics: Shared
>> > LPAR Name:PLB2
>> > LPAR Adjustment:  390
>> > LPAR CPUs Total:  32
>> > LPAR CPUs Configured: 32
>> > LPAR CPUs Standby:0
>> > LPAR CPUs Reserved:   0
>> > LPAR CPUs Dedicated:  0
>> > LPAR CPUs Shared: 32
>> > LPAR CPUs G-MTID: 0
>> > LPAR CPUs S-MTID: 1
>> > LPAR CPUs PS-MTID:1
>> >
>> > VM00 Name:DMZLA004
>> > VM00 Control Program: z/VM6.4.0
>> > VM00 Adjustment:  15
>> > VM00 CPUs Total:  1
>> > VM00 CPUs Configured: 1
>> > VM00 CPUs Standby:0
>> > VM00 CPUs Reserved:   0
>> >
>> >
>> >
>> >
>> > Regards, Phil Tully
>> >
>> >
>> > --
>> > This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and confidential.
>> If the reader of the message is not the intended recipient or an authorized
>> representative of the intended recipient, you are hereby notified that any
>> dissemination of this communication is strictly prohibited. If you have
>> received this communication in error, notify the sender immediately by
>> return email and delete the message and any attachments from your system.
>> >
>> >
>> > --
>> > 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
>>
>>
>> --
>> 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
>>
>

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

Re: VM system name

[Tully, Phil (CORP)]

Rich, 
That is the virtual machine name, not the VM system name.

Regards, Phil Tully
Chief Architect-z/VM & z/Linux
phil.tu...@adp.com
cell: 973-202-7427
1-800 377-0237,,5252697#



On 7/8/20, 12:16 PM, "Linux on 390 Port on behalf of Rich Smrcina" 
 wrote:

 
WARNING: Do not click links or open attachments unless you recognize the 
source of the email and know the contents are safe. 

**
VM00 Name.

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 


> On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP)  
wrote:
> 
> When I look at /proc/sysinfo, I can see the LPAR name but I don’t see the 
VM system name.  Is there a place that the VM system name would be shown from 
linux?
> 
> LPAR Number:  2
> LPAR Characteristics: Shared
> LPAR Name:PLB2
> LPAR Adjustment:  390
> LPAR CPUs Total:  32
> LPAR CPUs Configured: 32
> LPAR CPUs Standby:0
> LPAR CPUs Reserved:   0
> LPAR CPUs Dedicated:  0
> LPAR CPUs Shared: 32
> LPAR CPUs G-MTID: 0
> LPAR CPUs S-MTID: 1
> LPAR CPUs PS-MTID:1
> 
> VM00 Name:DMZLA004
> VM00 Control Program: z/VM6.4.0
> VM00 Adjustment:  15
> VM00 CPUs Total:  1
> VM00 CPUs Configured: 1
> VM00 CPUs Standby:0
> VM00 CPUs Reserved:   0
> 
> 
> 
> 
> Regards, Phil Tully
> 
> 
> --
> This message and any attachments are intended only for the use of the 
addressee and may contain information that is privileged and confidential. If 
the reader of the message is not the intended recipient or an authorized 
representative of the intended recipient, you are hereby notified that any 
dissemination of this communication is strictly prohibited. If you have 
received this communication in error, notify the sender immediately by return 
email and delete the message and any attachments from your system.
> 
> 
> --
> 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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
 


--
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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
 



--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.


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

Re: VM system name

[Tully, Phil (CORP)]

Which means to find out the name of the VM system they need access to VMCP ...

Regards, Phil Tully
Chief Architect-z/VM & z/Linux
phil.tu...@adp.com
cell: 973-202-7427
1-800 377-0237,,5252697#



On 7/8/20, 12:34 PM, "Linux on 390 Port on behalf of Rich Smrcina" 
 wrote:

 
WARNING: Do not click links or open attachments unless you recognize the 
source of the email and know the contents are safe. 

**
vmcp q userid ?

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com 


> On Jul 8, 2020, at 11:23 AM, Tully, Phil (CORP)  
wrote:
> 
> Rich, 
> That is the virtual machine name, not the VM system name.
> 
> Regards, Phil Tully
> Chief Architect-z/VM & z/Linux
> phil.tu...@adp.com 
> cell: 973-202-7427
> 1-800 377-0237,,5252697#
> 
> 
> 
> On 7/8/20, 12:16 PM, "Linux on 390 Port on behalf of Rich Smrcina" 
mailto:LINUX-390@VM.MARIST.EDU> on behalf of 
r...@velocitysoftware.com > wrote:
> 
> 
>WARNING: Do not click links or open attachments unless you recognize 
the source of the email and know the contents are safe. 
> 
>**
>VM00 Name.
> 
>Rich Smrcina
>Sr. Systems Engineer
> 
>Velocity Software Inc.
>Main: (650) 964-8867
>Main: (877) 964-8867
>r...@velocitysoftware.com  
>
> 
> 
>> On Jul 8, 2020, at 11:12 AM, Tully, Phil (CORP)  
wrote:
>> 
>> When I look at /proc/sysinfo, I can see the LPAR name but I don’t see 
the VM system name.  Is there a place that the VM system name would be shown 
from linux?
>> 
>> LPAR Number:  2
>> LPAR Characteristics: Shared
>> LPAR Name:PLB2
>> LPAR Adjustment:  390
>> LPAR CPUs Total:  32
>> LPAR CPUs Configured: 32
>> LPAR CPUs Standby:0
>> LPAR CPUs Reserved:   0
>> LPAR CPUs Dedicated:  0
>> LPAR CPUs Shared: 32
>> LPAR CPUs G-MTID: 0
>> LPAR CPUs S-MTID: 1
>> LPAR CPUs PS-MTID:1
>> 
>> VM00 Name:DMZLA004
>> VM00 Control Program: z/VM6.4.0
>> VM00 Adjustment:  15
>> VM00 CPUs Total:  1
>> VM00 CPUs Configured: 1
>> VM00 CPUs Standby:0
>> VM00 CPUs Reserved:   0
>> 
>> 
>> 
>> 
>> Regards, Phil Tully
>> 
>> 
>> --
>> This message and any attachments are intended only for the use of the 
addressee and may contain information that is privileged and confidential. If 
the reader of the message is not the intended recipient or an authorized 
representative of the intended recipient, you are hereby notified that any 
dissemination of this communication is strictly prohibited. If you have 
received this communication in error, notify the sender immediately by return 
email and delete the message and any attachments from your system.
>> 
>> 
>> --
>> 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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
 

 
> 
> 
>--
>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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=5EoI5NCVbuRUA6amNNG6vDgcZrGDXTqfd6eFMuhhWAg&s=TOoFiXT7w3-XIPjsHZ1hC1HNpoOCU2opdwAef_yMr4A&e=
 

Re: VM system name

[Alan Altmark]

On Wednesday, 07/08/2020 at 04:47 GMT, Ronald van der Laan 
 wrote:
> STore HYpervisor Information returns system name and ssi name of the top 
3
> levels of hypervisors.

Indeed, but arch/s390/kernel/sysinfo.c doesn't use it.  That's where the 
information you see in /proc/sysinfo comes from.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


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

Re: VM system name

[Marcy Cortes]

Late to the game, but I would probably make a .service file that did something 
like

ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname

and then anything could look at the file.

An LGR'd guest would be wrong, but I don't think you use that. 

Marcy

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

Re: VM system name

[Mark Post]

On 7/17/20 12:18 PM, Marcy Cortes wrote:
> Late to the game, but I would probably make a .service file that did 
> something like
>
> ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname
>
> and then anything could look at the file.
>
> An LGR'd guest would be wrong, but I don't think you use that.

Would people find it helpful if a command is introduced to the
s390-tools package that will return one or more of the following data
points:
1. z/VM or KVM Guest name
2. z/VM Host name
3. KVM Host name
4. LPAR name
5. CEC name

??

Mark Post

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

Re: VM system name

[Alan Ackerman]

Yes! I spent a fair amount of time writing EXECs to figure these things out 
when I worked for Bank of America. I put the results on a web page that listed 
all our VM systems. I’m retired so I don’t need it any more. 

Sent from my iPhone

On Jul 18, 2020, at 11:59 AM, Mark Post  wrote:

On 7/17/20 12:18 PM, Marcy Cortes wrote:
> Late to the game, but I would probably make a .service file that did 
> something like
> 
> ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname
> 
> and then anything could look at the file.
> 
> An LGR'd guest would be wrong, but I don't think you use that.

Would people find it helpful if a command is introduced to the
s390-tools package that will return one or more of the following data
points:
1. z/VM or KVM Guest name
2. z/VM Host name
3. KVM Host name
4. LPAR name
5. CEC name

??

Mark Post

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

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

Re: VM system name

[Mark Post]

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


Mark Post

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

Re: VM system name

[Stewart, Lee]

+1

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 ● 
lstew...@visa.com

-Original Message-
From: Linux on 390 Port  On Behalf Of Alan Ackerman
Sent: Saturday, July 18, 2020 2:13 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

Yes! I spent a fair amount of time writing EXECs to figure these things out 
when I worked for Bank of America. I put the results on a web page that listed 
all our VM systems. I’m retired so I don’t need it any more. 

Sent from my iPhone

On Jul 18, 2020, at 11:59 AM, Mark Post  wrote:

On 7/17/20 12:18 PM, Marcy Cortes wrote:
> Late to the game, but I would probably make a .service file that did 
> something like
> 
> ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > 
> /etc/vmsysname
> 
> and then anything could look at the file.
> 
> An LGR'd guest would be wrong, but I don't think you use that.

Would people find it helpful if a command is introduced to the s390-tools 
package that will return one or more of the following data
points:
1. z/VM or KVM Guest name
2. z/VM Host name
3. KVM Host name
4. LPAR name
5. CEC name

??

Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Clstewart%40visa.com%7C24812c4d36d14b16e7b108d82b570ba7%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C1%7C637307000165867342&sdata=puKgiyjBmtqDvytUM%2FCGSBjEWwS5qJsJAHOpyOwKP8Y%3D&reserved=0

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Clstewart%40visa.com%7C24812c4d36d14b16e7b108d82b570ba7%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C1%7C637307000165867342&sdata=puKgiyjBmtqDvytUM%2FCGSBjEWwS5qJsJAHOpyOwKP8Y%3D&reserved=0

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

Re: VM system name

[Hamilton, Robert]

Never going to retire. So count me and my +1.

Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
A Division of the American Chemical Society

-Original Message-
From: Linux on 390 Port  On Behalf Of Stewart, Lee
Sent: Monday, July 20, 2020 5:57 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [EXT] Re: VM system name

[Actual Sender is owner-linux-...@vm.marist.edu]

I wish I was a retiree.
And +1 each from the other guys doing zLinux here...

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 ● 
lstew...@visa.com


-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 1:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help the 
business case). Anyone else?


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Clstewart%40visa.com%7C3f9589ab43ef474bcb4508d82ce19756%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637308694699119474&sdata=3lbJpJlSG%2FJFbJhZJvKLSmBx2ROYjoDzLSVlRv28TMs%3D&reserved=0

--
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
Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from CAS, a division of the American Chemical Society ("ACS"). If you have 
received this transmission in error, be advised that any disclosure, copying, 
distribution, or use of the contents of this information is strictly 
prohibited. Please destroy all copies of the message and contact the sender 
immediately by either replying to this message or calling 614-447-3600.


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

Re: VM system name

[Doug]

I’m on the work till you die plan, count me a plus 1.
Best Regards,
Doug 

.

On Jul 20, 2020, at 18:11, Hamilton, Robert  wrote:

Never going to retire. So count me and my +1.

Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
A Division of the American Chemical Society

-Original Message-
From: Linux on 390 Port  On Behalf Of Stewart, Lee
Sent: Monday, July 20, 2020 5:57 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [EXT] Re: VM system name

[Actual Sender is owner-linux-...@vm.marist.edu]

I wish I was a retiree.
And +1 each from the other guys doing zLinux here...

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 ● 
lstew...@visa.com


-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 1:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

> On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help the 
business case). Anyone else?


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Clstewart%40visa.com%7C3f9589ab43ef474bcb4508d82ce19756%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637308694699119474&sdata=3lbJpJlSG%2FJFbJhZJvKLSmBx2ROYjoDzLSVlRv28TMs%3D&reserved=0

--
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
Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from CAS, a division of the American Chemical Society ("ACS"). If you have 
received this transmission in error, be advised that any disclosure, copying, 
distribution, or use of the contents of this information is strictly 
prohibited. Please destroy all copies of the message and contact the sender 
immediately by either replying to this message or calling 614-447-3600.


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

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

Re: VM system name

[Marcy Cortes]

+2

-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 12:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] VM system name

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


Mark Post

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

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

Re: VM system name

[Stewart, Lee]

I wish I was a retiree.
And +1 each from the other guys doing zLinux here...

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - +1-303-389-4601 ● 
lstew...@visa.com


-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 1:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help the 
business case). Anyone else?


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Clstewart%40visa.com%7C3f9589ab43ef474bcb4508d82ce19756%7C38305e12e15d4ee888b9c4db1c477d76%7C0%7C0%7C637308694699119474&sdata=3lbJpJlSG%2FJFbJhZJvKLSmBx2ROYjoDzLSVlRv28TMs%3D&reserved=0

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

Re: VM system name

[Tully, Phil (CORP)]

If you actually countingcan I get 1 for each lpar. + 60

Regards, Phil Tully
Chief Architect-z/VM & z/Linux
phil.tu...@adp.com
cell: 973-202-7427
1-800 377-0237,,5252697#



On 7/20/20, 7:07 PM, "Linux on 390 Port on behalf of Doug" 
 wrote:

 
WARNING: Do not click links or open attachments unless you recognize the 
source of the email and know the contents are safe. 

**
I’m on the work till you die plan, count me a plus 1.
Best Regards,
Doug 

.

On Jul 20, 2020, at 18:11, Hamilton, Robert  wrote:

Never going to retire. So count me and my +1.

Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
A Division of the American Chemical Society

-Original Message-
From: Linux on 390 Port  On Behalf Of Stewart, Lee
Sent: Monday, July 20, 2020 5:57 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [EXT] Re: VM system name

[Actual Sender is owner-linux-...@vm.marist.edu]

I wish I was a retiree.
And +1 each from the other guys doing zLinux here...

Lee Stewart ● VM System Support ● Visa ● Phone:  6(750)4601 - 
+1-303-389-4601 ● lstew...@visa.com


-Original Message-
From: Linux on 390 Port  On Behalf Of Mark Post
Sent: Monday, July 20, 2020 1:16 PM
To: LINUX-390@VM.MARIST.EDU
    Subject: Re: VM system name

> On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help the 
business case). Anyone else?


Mark Post

--
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=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww2.marist.edu-252Fhtbin-252Fwlvindex-253FLINUX-2D390-26amp-3Bdata-3D02-257C01-257Clstewart-2540visa.com-257C3f9589ab43ef474bcb4508d82ce19756-257C38305e12e15d4ee888b9c4db1c477d76-257C0-257C0-257C637308694699119474-26amp-3Bsdata-3D3lbJpJlSG-252FJFbJhZJvKLSmBx2ROYjoDzLSVlRv28TMs-253D-26amp-3Breserved-3D0&d=DwIFaQ&c=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=x1Wa93OFsZNurO4mmgMslkV4LYcC0uaHv39Li3Gee1Q&s=C5AhjsFcYK3waQ-8jIinrFoEn0cCCY6APeBmo009qwM&e=
 

--
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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=x1Wa93OFsZNurO4mmgMslkV4LYcC0uaHv39Li3Gee1Q&s=5yuOoVQHaA0DokBD305k75EmfU-ZOzLZJ0G1ewyCr_I&e=
 
Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from CAS, a division of the American Chemical Society ("ACS"). If you have 
received this transmission in error, be advised that any disclosure, copying, 
distribution, or use of the contents of this information is strictly 
prohibited. Please destroy all copies of the message and contact the sender 
immediately by either replying to this message or calling 614-447-3600.


--
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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=x1Wa93OFsZNurO4mmgMslkV4LYcC0uaHv39Li3Gee1Q&s=5yuOoVQHaA0DokBD305k75EmfU-ZOzLZJ0G1ewyCr_I&e=
 

--
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=xu_5lAfKHjInGFR3ndoZrw&r=YINhRQBnBpDTaiDeBIX-uouJy__emITEWU-E34BcxvU&m=x1Wa93OFsZNurO4mmgMslkV4LYcC0uaHv39Li3Gee1Q&s=5yuOoVQHaA0DokBD305k75EmfU-ZOzLZJ0G1ewyCr_I&e=
 



--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended r

Re: VM system name

[Stefan Raspl]

On 2020-07-18 22:12, Alan Ackerman wrote:
> Yes! I spent a fair amount of time writing EXECs to figure these things out 
> when I worked for Bank of America. I put the results on a web page that 
> listed all our VM systems. I’m retired so I don’t need it any more. 
> 
> Sent from my iPhone
> 
> On Jul 18, 2020, at 11:59 AM, Mark Post  wrote:
> 
> On 7/17/20 12:18 PM, Marcy Cortes wrote:
>> Late to the game, but I would probably make a .service file that did 
>> something like
>>
>> ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname
>>
>> and then anything could look at the file.
>>
>> An LGR'd guest would be wrong, but I don't think you use that.
> 
> Would people find it helpful if a command is introduced to the
> s390-tools package that will return one or more of the following data
> points:
> 1. z/VM or KVM Guest name
> 2. z/VM Host name
> 3. KVM Host name
> 4. LPAR name
> 5. CEC name

qclib, which was linked to earlier in the thread, offers all the info. As the
name implies, it is a library, but it comes with a sample program called qc_test
that is intended for debugging purposes. I did some work to provide a standalone
program based to provide the most commonly used data - at least the one *I*
figured might be popular - and which, of course, does not reflect any of the
fields requested above  LOL
It seems like there's a use for most of the data provided by qc_test, everybody
seems to find interest in some data. So I'm contemplating externalization of
qc_test output in some shape or form - but is that really consumable?
However, externalizing it is easier said than done, since some of the fields
require a lot of explanation, especially in virtualized environments.
So: Would the output below help, or should we rather have a separate tool with a
more comprehensible format?
Here's some sample output from a Linux guest running under z/VM on top of a z/VM
resource pool (qc_layer_name is the attribute that would reflect the values 1-5
above):

[raspl@jungle qclib]$ ./qc_test

We are running 5 layer(s)

  = Layer 0: CEC =
 qc_layer_type [n/a]: CEC
 qc_layer_category [n/a]: HOST
 qc_layer_type_num [n/a]: 1
 qc_layer_category_num [n/a]: 2
 qc_layer_name [F V]: X35
   qc_manufacturer [S V]: IBM
   qc_type [S V]: 2827
  qc_type_name [S  ]: IBM zEnterprise EC12
qc_type_family [S  ]: 0
 qc_model_capacity [S  ]: 703
  qc_model [S  ]: H66
  qc_sequence_code [S V]: 00089F25
 qc_lic_identifier [S  ]: 
  qc_plant [S V]: 02

 qc_num_core_total [S  ]: 68
qc_num_core_configured [S  ]: 3
   qc_num_core_standby [S  ]: 0
  qc_num_core_reserved [S  ]: 65
 qc_num_core_dedicated [ hV]: 2
qc_num_core_shared [ hV]: 61

   qc_num_cp_total [ HV]: 3
   qc_num_cp_dedicated [ hV]: 0
  qc_num_cp_shared [ hV]: 3
  qc_num_ifl_total [ HV]: 60
  qc_num_ifl_dedicated [ hV]: 2
 qc_num_ifl_shared [ hV]: 58
 qc_num_ziip_total [ HV]: 
 qc_num_ziip_dedicated [ hV]: 
qc_num_ziip_shared [ hV]: 

 qc_num_cp_threads [S  ]: 
qc_num_ifl_threads [S  ]: 
   qc_num_ziip_threads [S  ]: 

 qc_capability [S  ]: 552.00
   qc_secondary_capability [S  ]: 552.00
 qc_capacity_adjustment_indication [S  ]: 100
 qc_capacity_change_reason [S  ]: 0


= Layer 1: LPAR =
   qc_layer_type [n/a]: LPAR
   qc_layer_category [n/a]: GUEST
   qc_layer_type_num [n/a]: 2
   qc_layer_category_num [n/a]: 1
   qc_layer_name [S V]: MYLPAR2
  qc_layer_extended_name [S  ]: 
   qc_layer_uuid [S  ]: 
 qc_partition_number [S V]: 47
   qc_partition_char [S  ]: Shared
   qc_partition_char_num [S  ]: 2
   qc_adjustment [S  ]: 333
   qc_has_secure [F  ]: 
   qc_secure [F  ]: 

   qc_num_core_total [S  ]: 1
  qc_num_core_configured [S  ]: 1
 qc_num_core_standby [S  ]: 0
qc_num_core_reserved [S  ]: 0
   qc_num_core_dedicated [S  ]: 0
  qc_num_core_shared [S  ]: 1

 qc_

Re: VM system name

[Mark Post]

On 7/22/20 9:28 AM, Stefan Raspl wrote:

> qclib, which was linked to earlier in the thread, offers all the info.

Indeed, which is what I would have based anything I wrote on.

-snip-
> It seems like there's a use for most of the data provided by qc_test, 
> everybody
> seems to find interest in some data. So I'm contemplating externalization of
> qc_test output in some shape or form - but is that really consumable?

Not as is, today.

> However, externalizing it is easier said than done, since some of the fields
> require a lot of explanation, especially in virtualized environments.
> So: Would the output below help, or should we rather have a separate tool 
> with a
> more comprehensible format?

The latter. Please let me know if you're going to proceed with this. If
so, I won't start working on the limited command I already talked about.


Thanks,

Mark Post

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

Re: VM system name

[Alan Ackerman]

Humpf! I think my opinion still counts. I may never use it, but I think Bank of 
America probably will.

Alan Ackerman
alan.ackerma...@gmail.com



On Jul 20, 2020, at 12:16 PM, Mark Post  wrote:

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


Mark Post

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


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

Re: VM system name

[Mark Post]

On 7/22/20 4:37 PM, Alan Ackerman wrote:
> Humpf! I think my opinion still counts. I may never use it, but I think Bank 
> of America probably will.

Are they running SUSE Linux Enterprise Server?


Mark Post

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

Re: VM system name

[Alan Ackerman]

As far as I know they are running Red Hat. 

Why does that matter?

Alan Ackerman
alan.ackerma...@gmail.com



On Jul 20, 2020, at 12:16 PM, Mark Post  wrote:

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


Mark Post

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


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

Re: VM system name

[Mark Post]

On 7/22/20 4:44 PM, Alan Ackerman wrote:
> As far as I know they are running Red Hat.
>
> Why does that matter?

Because I work for SUSE, and any tools I write would be distributed by
SUSE in the s390-tools package. I doubt very much Red Hat would pick it
up for their distribution. But, you never know, I suppose.


Mark Post

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

Re: VM system name

[Stefan Raspl]

On 2020-07-22 19:27, Mark Post wrote:
> On 7/22/20 9:28 AM, Stefan Raspl wrote:
> 
>> qclib, which was linked to earlier in the thread, offers all the info.
> 
> Indeed, which is what I would have based anything I wrote on.
> 
> -snip-
>> It seems like there's a use for most of the data provided by qc_test, 
>> everybody
>> seems to find interest in some data. So I'm contemplating externalization of
>> qc_test output in some shape or form - but is that really consumable?
> 
> Not as is, today.
> 
>> However, externalizing it is easier said than done, since some of the fields
>> require a lot of explanation, especially in virtualized environments.
>> So: Would the output below help, or should we rather have a separate tool 
>> with a
>> more comprehensible format?
> 
> The latter. Please let me know if you're going to proceed with this. If
> so, I won't start working on the limited command I already talked about.

Give me 1-2 weeks to sort out some details. This shouldn't be a lot of effort,
but rather to get the format right. I could imagine writing a simplistic tool
that displays all virtualization levels down to the CEC, with the potential to
extend it in the future.


-- 

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

Re: VM system name

[Mark Post]

On 7/23/20 3:17 AM, Stefan Raspl wrote:
> I could imagine writing a simplistic tool
> that displays all virtualization levels down to the CEC, with the potential to
> extend it in the future.

Hi, Stefan,

I was thinking more in terms of command line switches that determine
what should be returned. For example:
cmdname --guest Would return the name of my running guest
cmdname --host  Would return the name of the z/VM or KVM host.
cmdname --lpar  Would return the name of the LPAR.
cmdname --cec   Would return the name of the CEC. Or CPC, since I think
that's the current IBM name.

And possibly, something like:
cmdname --all   Which would return the names of all these things, possible
as "name=value" pairs.

There's already the systemd-detect-virt command to tell you what
hypervisor is in use, so that wouldn't be needed. I can't say for sure
if many people would be interested in finding out they're running 6
layers of virtualization deep and what each of those is. If someone does
want that, they should speak up.

I believe something like this would allow for easy scripting by system
administrators. Of course, others may have differing opinions.


Mark Post

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

Re: VM system name

[Mauro Souza]

> people would be interested in finding out they're running 6 layers of
virtualization deep

Like having a partition with zVM, with a zVM second level, with a Linux
inside, running KVM, with a Linux on the KVM running a Docker container,
and a JVM inside the container, trying to benchmark Bcrypt on a JSP...

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.


Em qui., 23 de jul. de 2020 às 16:16, Mark Post  escreveu:

> On 7/23/20 3:17 AM, Stefan Raspl wrote:
> > I could imagine writing a simplistic tool
> > that displays all virtualization levels down to the CEC, with the
> potential to
> > extend it in the future.
>
> Hi, Stefan,
>
> I was thinking more in terms of command line switches that determine
> what should be returned. For example:
> cmdname --guest Would return the name of my running guest
> cmdname --host  Would return the name of the z/VM or KVM host.
> cmdname --lpar  Would return the name of the LPAR.
> cmdname --cec   Would return the name of the CEC. Or CPC, since I think
> that's the current IBM name.
>
> And possibly, something like:
> cmdname --all   Which would return the names of all these things, possible
> as "name=value" pairs.
>
> There's already the systemd-detect-virt command to tell you what
> hypervisor is in use, so that wouldn't be needed. I can't say for sure
> if many people would be interested in finding out they're running 6
> layers of virtualization deep and what each of those is. If someone does
> want that, they should speak up.
>
> I believe something like this would allow for easy scripting by system
> administrators. Of course, others may have differing opinions.
>
>
> Mark Post
>
> --
> 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
>

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

Re: VM system name

[Bruce Lightsey]

+whatever ( and we are on SuSE 15 as a bonus)


OK, that's one (sorry, but retirees who won't use the tool don't help the 
business case). Anyone else?


Mark Post

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

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


Bruce Lightsey
Database Manager
MS Department of Information Technology Services
601-432-8144 | www.its.ms.gov

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the system 
manager. This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited


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

Re: VM system name

[Stefan Raspl]

Hi Mark,

On 2020-07-23 21:16, Mark Post wrote:
> On 7/23/20 3:17 AM, Stefan Raspl wrote:
>> I could imagine writing a simplistic tool
>> that displays all virtualization levels down to the CEC, with the potential 
>> to
>> extend it in the future.
> 
> Hi, Stefan,
> 
> I was thinking more in terms of command line switches that determine
> what should be returned. For example:
> cmdname --guest   Would return the name of my running guest
> cmdname --hostWould return the name of the z/VM or KVM host.
> cmdname --lparWould return the name of the LPAR.
> cmdname --cec Would return the name of the CEC. Or CPC, since I think
> that's the current IBM name.

The problem with that is that you will get into trouble as soon as you consider
2nd-level installs where you have multiple guests and hypervisors to
display/query. We'd need multiple switches to address the different levels of
guests, and things get ugly pretty fast. Any ideas how to address that?

> And possibly, something like:
> cmdname --all Which would return the names of all these things, possible
> as "name=value" pairs. 
> There's already the systemd-detect-virt command to tell you what
> hypervisor is in use, so that wouldn't be needed. I can't say for sure
> if many people would be interested in finding out they're running 6
> layers of virtualization deep and what each of those is. If someone does
> want that, they should speak up.
> 
> I believe something like this would allow for easy scripting by system
> administrators. Of course, others may have differing opinions.

I would argue that if you want to script, what you really want is a front-end in
qclib that can be accessed by scripts. Yes, querying qclib is certainly more
complicated than interacting with a command line tool like you layed out above,
but unless we come up with a smart way for that tool's cmdline switches, it will
likely not do what you need.

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

Re: VM system name

[Timothy Sipples]

Mark Post wrote:
>I was thinking more in terms of command line switches that determine
>what should be returned. For example:
>cmdname --guest Would return the name of my running guest
>cmdname --host  Would return the name of the z/VM or KVM host.
>cmdname --lpar  Would return the name of the LPAR.
>cmdname --cec   Would return the name of the CEC. Or CPC, since I 
think
>that's the current IBM name.

If I get a vote, I would prefer plain English, avoiding unnecessary 
jargon, even IBM's. :-) How about:

--guest
--hypervisor
--partition
--platform

The last one could report the IBM Z Personal Development Tool ("ZPDT") or 
QEMU, as notable examples, so sometimes the answer is non-physical. Hence 
CPC isn't universally applicable even if the jargon were acceptable. If 
platform isn't the right word then "base" and "server" are possible 
alternatives. "Host" clashes with popular terms such as "hostname," so 
it's not my favorite here.

If there are precedents that are also reasonably jargon free, they're 
probably fine.

>There's already the systemd-detect-virt command to tell you what
>hypervisor is in use, so that wouldn't be needed. I can't say for sure
>if many people would be interested in finding out they're running 6
>layers of virtualization deep and what each of those is. If someone does
>want that, they should speak up.

The following execution environment details are some of the ones useful to 
me, anyway: physical machine model and submodel (e.g. 8562-T02 Max13), 
capacity machine model (if any CPs are supplying any capacity, e.g. "G03"; 
otherwise "A00" or "400" would probably be reported)(*), machine serial 
number, whether CPACF is fully activated (i.e. whether Feature Code 3863 
is present), whether Secure Execution for Linux (Feature Code 0100) is 
present, Crypto Express features (lszcrypt shows these details), the SMT 
mode, whether the machine is in any significant state of distress 
(thermally throttled processors for example), whether it's Securely 
Booted, firmware (driver) details if knowable, temporary v. permanent 
capacity characteristics That's off the top of my head. These details 
are already available in many cases, but maybe some are missing.

(*) It could still be useful to know the machine's CP configuration even 
if CPs aren't currently involved in supplying capacity. It's very useful 
to know if they are, even a little, since CPs are available in subcapacity 
configurations.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

Re: VM system name

[Mark Post]

On 7/24/20 3:26 AM, Stefan Raspl wrote:
> Hi Mark,

Hi, Stefan,

> The problem with that is that you will get into trouble as soon as you 
> consider
> 2nd-level installs where you have multiple guests and hypervisors to
> display/query. We'd need multiple switches to address the different levels of
> guests, and things get ugly pretty fast. Any ideas how to address that?

I believe you're over-thinking this. Based on the origin of this thead
and the responses to it, I would argue that people aren't interested in
all that. They want to know:
- What's *my* name
- What's the name of the host system
- What LPAR am I running in
- What CPC am I running on

That's why I said this:
>> I can't say for sure
>> if many people would be interested in finding out they're running 6
>> layers of virtualization deep and what each of those is. If someone does
>> want that, they should speak up.
-snip-

> I would argue that if you want to script, what you really want is a front-end 
> in
> qclib that can be accessed by scripts. Yes, querying qclib is certainly more
> complicated than interacting with a command line tool like you layed out 
> above,
> but unless we come up with a smart way for that tool's cmdline switches, it 
> will
> likely not do what you need.

I would say that the limited program I'm suggesting would do exactly
what people want. Remember, I proposed this as a way for people to not
have to write all sorts of REXX execs and bash scripts to figure out
this small set of information. There may be others out there that are
interested in much more than this, but so far they haven't said so (on
this mailing list anyway).


Mark Post

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

Re: VM system name

[Stefan Raspl]

On 2020-07-24 17:29, Mark Post wrote:
> On 7/24/20 3:26 AM, Stefan Raspl wrote:
>> Hi Mark,
> 
> Hi, Stefan,
> 
>> The problem with that is that you will get into trouble as soon as you 
>> consider
>> 2nd-level installs where you have multiple guests and hypervisors to
>> display/query. We'd need multiple switches to address the different levels of
>> guests, and things get ugly pretty fast. Any ideas how to address that?
> 
> I believe you're over-thinking this. Based on the origin of this thead
> and the responses to it, I would argue that people aren't interested in
> all that. They want to know:
> - What's *my* name
> - What's the name of the host system
> - What LPAR am I running in
> - What CPC am I running on
> 
> That's why I said this:
>>> I can't say for sure
>>> if many people would be interested in finding out they're running 6
>>> layers of virtualization deep and what each of those is. If someone does
>>> want that, they should speak up.
> -snip-
> 
>> I would argue that if you want to script, what you really want is a 
>> front-end in
>> qclib that can be accessed by scripts. Yes, querying qclib is certainly more
>> complicated than interacting with a command line tool like you layed out 
>> above,
>> but unless we come up with a smart way for that tool's cmdline switches, it 
>> will
>> likely not do what you need.
> 
> I would say that the limited program I'm suggesting would do exactly
> what people want. Remember, I proposed this as a way for people to not
> have to write all sorts of REXX execs and bash scripts to figure out
> this small set of information. There may be others out there that are
> interested in much more than this, but so far they haven't said so (on
> this mailing list anyway).
Fair enough. So in case we detect 2nd or higher level guests, we could indiate
so and limit output to e.g. CEC and LPAR only - is that how you would handle 
things?


-- 

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

Re: VM system name

[Mark Post]

On 7/24/20 5:33 PM, Stefan Raspl wrote:
> Fair enough. So in case we detect 2nd or higher level guests, we could indiate
> so and limit output to e.g. CEC and LPAR only - is that how you would handle 
> things?

I might need a diagram to make sure I understand what you're saying, but
it sounds like we're (almost) on the same page.


Mark Post

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

Re: VM system name

[Alan Altmark]

In some sense you are creating a UUID for the container.

CPCname.LPAR.System_id.userid.system_id.userid

Having to handle second level systems and LPAR only, too.

Perhaps prefixed with nn, where nn tells you how many levels of VM. 01
means native LPAR.

Regards,
Alan Altmark
IBM

> On Jul 24, 2020, at 5:59 PM, Mark Post  wrote:
>
> On 7/24/20 5:33 PM, Stefan Raspl wrote:
>> Fair enough. So in case we detect 2nd or higher level guests, we could
indiate
>> so and limit output to e.g. CEC and LPAR only - is that how you would
handle things?
>
> I might need a diagram to make sure I understand what you're saying, but
> it sounds like we're (almost) on the same page.
>
>
> Mark Post
>
> --
> 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=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-vqLQGEWWoD4M&m=9tIfjLkNXY9ZysFukMm2-WNbUlIqKSRjHTNiV6ptlwU&s=YZ5v9EXypB-V55_GOBxIDRRjH7vFxawn9SpZ-eWFePM&e=

>

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

Re: VM system name

[Stefan Raspl]

On 2020-07-25 01:46, Alan Altmark wrote:
> In some sense you are creating a UUID for the container.
> 
> CPCname.LPAR.System_id.userid.system_id.userid
> 
> Having to handle second level systems and LPAR only, too.
> 
> Perhaps prefixed with nn, where nn tells you how many levels of VM. 01
> means native LPAR.

You mean just like /proc/sysinfo does? Yeah, there's a though, but Mark
suggested to have have support for paramters to select the output, e.g. '--lpar'
to get the LPAR name - but that won't work easily or in a non-ugly name for 2nd
level guests.
I'll be looking some more into this...maybe we'll inlude 2nd level and cut off
only after that - to be seen...


-- 

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

Re: VM system name

[David Boyes]

On 7/22/20, 9:29 AM, "Linux on 390 Port on behalf of Stefan Raspl" 
 wrote:
> Would people find it helpful if a command is introduced to the
> s390-tools package that will return one or more of the following data
> points:
> 1. z/VM or KVM Guest name
> 2. z/VM Host name
> 3. KVM Host name
> 4. LPAR name
> 5. CEC name

Some thoughts on this, in no particular order:

1. The output from qc_test you showed should require a --verbose option. Most 
uses for this data will programmatic, so something like 1 line per level, space 
delimited would be most useful. If you can parse it easily with classic Bourne 
shell, you got it right. 

Example: 

./qc_test without --verbose produces:

0 guest 5 1 GUEST43 off 0 0 undef undef 1 1 0 0 0 1 0 1 undef undef 
1 pool 4 3 pooltest 0 0 0 0 1 64467763 undef undef undef 
2 hyper 3 2 "MY_ZVM" undef "z/VM 6.3.0" 500 1 0 3 0 3 1 0 1 2 undef undef 
3 lpar 
4 cec .
.
etc on stdout. The --verbose version can show all the human friendly labels and 
formatting.

2. Most uses of this will be most interested in the layer closest to them, eg 
starting at the VM guest level and going outward (the reverse of how your 
example is formatted).

3. It might be useful to say "I'm not interested in data that is more than X 
levels from me" to reduce processing, ie something like --maxlevel . ./qc_test --maxlevel 2 from the example above would return data from 
guest, pool and hypervisor, but drop anything beyond.

4. An option to return only the number of virtualization levels present would 
be helpful to set loops, eg ./qc_test --levels in your example returns 5 as its 
only output.

5. a flag to test for multiple CPU types or not would be helpful (you can get 
what they are from the whole output, just a 1/0 flag to indicate the presence 
of a mixed LPAR), in a LPAR with both IFLs and standard engines ./qc_test 
--mixed would return 1 so you need to go look at the full data to find out the 
whole picture, or you could return the counts of processors of each type after 
the 1/0 if you felt like it.

6. (nit) in the verbose output, provide a way to provide a format string 
option, eg:

./qc_test --verbose --format="30:8.3" 

.
.
.
qc_capability [S ] : 552.000
qc_secondary_capability [S  ]  : 552.000
qc_capacity_adjustment_indication [S  ]: 100.000
qc_capacity_change_reason [S  ]:   0.000
.
.
.

I'd find a utility like that very useful indeed.

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

Re: VM system name

[Stefan Raspl]

Hi David,
Thanks for your considerations, greatly appreciated!

On 2020-07-30 02:28, David Boyes wrote:
> On 7/22/20, 9:29 AM, "Linux on 390 Port on behalf of Stefan Raspl" 
>  wrote:
>> Would people find it helpful if a command is introduced to the
>> s390-tools package that will return one or more of the following data
>> points:
>> 1. z/VM or KVM Guest name
>> 2. z/VM Host name
>> 3. KVM Host name
>> 4. LPAR name
>> 5. CEC name
> 
> Some thoughts on this, in no particular order:
> 
> 1. The output from qc_test you showed should require a --verbose option. Most 
> uses for this data will programmatic, so something like 1 line per level, 
> space delimited would be most useful. If you can parse it easily with classic 
> Bourne shell, you got it right. 
> 
> Example: 
> 
> ./qc_test without --verbose produces:
> 
> 0 guest 5 1 GUEST43 off 0 0 undef undef 1 1 0 0 0 1 0 1 undef undef 
> 1 pool 4 3 pooltest 0 0 0 0 1 64467763 undef undef undef 
> 2 hyper 3 2 "MY_ZVM" undef "z/VM 6.3.0" 500 1 0 3 0 3 1 0 1 2 undef undef 
> 3 lpar 
> 4 cec .
> .
> etc on stdout. The --verbose version can show all the human friendly labels 
> and formatting.

qc_test is not externalized so far and primarily intended as a debugging
aid/demo for the actual library. I was sort of testing the waters to see if
providing its format would have some merit - but it likely does not.
However, I like your idea, and I believe we could provide a more elaborate
output that could be used for scripting and further processing!
Not so sure about the format, though - the one above is hard to read, and I
would claim it might be prone to produce errors on all parties involved - e.g.
whenever we add further fields. Something that correlates the values to a field
name is preferable - maybe something like JSON could do the job here!

> 2. Most uses of this will be most interested in the layer closest to them, eg 
> starting at the VM guest level and going outward (the reverse of how your 
> example is formatted).

Yup, I agree.

> 3. It might be useful to say "I'm not interested in data that is more than X 
> levels from me" to reduce processing, ie something like --maxlevel  from me>. ./qc_test --maxlevel 2 from the example above would return data 
> from guest, pool and hypervisor, but drop anything beyond.

One could always do that by post-processing the output. Also, this would need
some semantics: We should likely count virtalization layers, not levels. Because
e.g. z/VM can or can not have a Resource Pool defined. As one does not know in
advance, it should not be counted. But then again, that makes it a bit more
complicated. I'd likely push that out as a future item.

> 4. An option to return only the number of virtualization levels present would 
> be helpful to set loops, eg ./qc_test --levels in your example returns 5 as 
> its only output.

Something like that is already available in the underlying library, although it
counts levels/layers, not _virtualization_ levels. Makes sense to keep it that 
way.

> 5. a flag to test for multiple CPU types or not would be helpful (you can get 
> what they are from the whole output, just a 1/0 flag to indicate the presence 
> of a mixed LPAR), in a LPAR with both IFLs and standard engines ./qc_test 
> --mixed would return 1 so you need to go look at the full data to find out 
> the whole picture, or you could return the counts of processors of each type 
> after the 1/0 if you felt like it.

There's a field like that available, but not in every layer. However, this is
really easy to derive from the output, so not sure if I'd want to add it...

> 6. (nit) in the verbose output, provide a way to provide a format string 
> option, eg:
> 
> ./qc_test --verbose --format="30:8.3" 
> 
> qc_capability [S ] : 552.000
> qc_secondary_capability [S  ]  : 552.000
> qc_capacity_adjustment_indication [S  ]: 100.000
> qc_capacity_change_reason [S  ]:   0.000

Uh, yeah, well, another 'future' I would say.

> I'd find a utility like that very useful indeed.

Thanks for your response, I'm pretty sure I'll come up with something in the not
too distant future!


-- 

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 / arc

Re: VM system name

[Stefan Raspl]

On 2020-07-18 20:58, Mark Post wrote:
> On 7/17/20 12:18 PM, Marcy Cortes wrote:
>> Late to the game, but I would probably make a .service file that did 
>> something like
>>
>> ExecStart= echo $(/sbin/vmcp q userid | awk '{print $3}') > /etc/vmsysname
>>
>> and then anything could look at the file.
>>
>> An LGR'd guest would be wrong, but I don't think you use that.
> 
> Would people find it helpful if a command is introduced to the
> s390-tools package that will return one or more of the following data
> points:
> 1. z/VM or KVM Guest name
> 2. z/VM Host name
> 3. KVM Host name
> 4. LPAR name
> 5. CEC name

OK, here's a shot at what this could look like:

  $ zhypinfo --help

 Usage: zhypinfo [OPTIONS]
 -j/--json   Export raw data in Json format
 -l/--layers Print number of layers
 -L/--levels Print number of virtualization levels


  $ zhypinfo
  NoLayer   Lvl  TypeName IFL CP
  --
  4 z/VM_Guest  1guest   myguest2  0
  3 z/VM_Resource_Pool  1poolpooltest   3  0
  2 z/VM1hypervisor  myzvm  8  0
  1 LPAR0guest   S38LP43   10  0
  0 CEC 0hostS38   34 10


  $ zhypinfo -l
  5


  $ zhypinfo -L
  2


  $ zhypinfo --json
  ... # dumps out _all_ info of qclib in json format


So this would be a rather simplistic approach, but hopefully addressing most
needs - bear with me:
- the format in the table should be comprehensible
- it should also be easy enough to parse in other scripts
- the fields 'Lvl' and 'Type' would help to make things addressable:
  'No' won't help much with scripting as one cannot know e.g. whether there's a
  z/VM resource pool present or not (which would shift the index accordingly).
  However, since there is only one guest/hypervisor/pool/etc. in each
  virtualization level, the combination of these two fields makes things
  adressable.
- I was actually wondering if column 'No' should be dropped...
- the json export is the catchall: It would export _all_ data made available by
  qclib, which is substantially more than printed in the table. There's tools
  like 'jq' that allow to filter out any given piece of data from json, so it
  would serve to fulfill any needs of folks who want to process the data and
  stop short of programming against qclib proper.
- The CPU counts (IFL and CP) do not distinguish between shared and dedicated.
  It is easy to get carried away with what data we provide. I'd refer folks with
  exotic requests to the '--json' option, and only think about expanding the
  format in case some piece of info is very popular/frequently requested.

All feedback appreciated!


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

Re: VM system name

[Timothy Sipples]

Would this readout make better sense?

$ zhypinfo
  NoLayer   TypeName IFL CP
  --
  2.2   z/VM_Guest  guest   myguest2  0
  2.1   z/VM_Resource_Pool  poolpooltest   3  0
  2.0   z/VMhypervisor  myzvm  8  0
  1 partition   guest   S38LP43   10  0
  0 machine hostS38   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.

Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they 
for parsing?) 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. And would it make sense to print the 
hypervisor release level in the Layer column, e.g. "z/VM 7.2"?

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. And how about a little 
more insight in the Type column for partition and machine?

What happens with SMT2 v. SMT1 in this readout? (Should something happen?)

Putting these suggestions all together except for the SMT2 one, plus some 
others, here's what you might end up with:

$ zhypinfo
  # Layer Type  NameIFLsCPs
  
  2.2   Linux 4.18guest myguest2  0
  2.1   z/VM 7.2  pool  pooltest   3  0
  2.0   z/VM 7.2  hypervisormyzvm  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.

"Fun" question: what should a z/OS Container Extensions readout look like?

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.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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

Re: VM system name

[Stefan Raspl]

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
>   NoLayer   TypeName IFL CP
>   --
>   2.2   z/VM_Guest  guest   myguest2  0
>   2.1   z/VM_Resource_Pool  poolpooltest   3  0
>   2.0   z/VMhypervisor  myzvm  8  0
>   1 partition   guest   S38LP43   10  0
>   0 machine hostS38   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"?

H, 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  NameIFLsCPs
>   
>   2.2   Linux 4.18guest myguest2  0
>   2.1   z/VM 7.2  pool  pooltest   3  0
>   2.0   z/VM 7.2  hypervisormyzvm  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 giv

Re: VM system name

[van Sleeuwen, Berry]

I think the underscore would be required. If the output is processed by some 
script it's easier to select the word. If the underscore is omitted then word 5 
for instance is not always the number of IFLs.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Timothy Sipples
Sent: Tuesday, 4 August 2020 07:57
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Would this readout make better sense?

$ zhypinfo
  NoLayer   TypeName IFL CP
  --
  2.2   z/VM_Guest  guest   myguest2  0
  2.1   z/VM_Resource_Pool  poolpooltest   3  0
  2.0   z/VMhypervisor  myzvm  8  0
  1 partition   guest   S38LP43   10  0
  0 machine hostS38   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.

Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they for 
parsing?) 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. And would it make sense to print the hypervisor 
release level in the Layer column, e.g. "z/VM 7.2"?

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. And how about a little more insight in the Type column for 
partition and machine?

What happens with SMT2 v. SMT1 in this readout? (Should something happen?)

Putting these suggestions all together except for the SMT2 one, plus some 
others, here's what you might end up with:

$ zhypinfo
  # Layer Type  NameIFLsCPs
  
  2.2   Linux 4.18guest myguest2  0
  2.1   z/VM 7.2  pool  pooltest   3  0
  2.0   z/VM 7.2  hypervisormyzvm  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.

"Fun" question: what should a z/OS Container Extensions readout look like?

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.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7C991fdad0d7724869c05d08d8383b5db1%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637321174909186781&sdata=j1Q%2Ba2kLrzED%2BoxpX%2BGwUVIcJsPNV2OpIOCHxHGg5gU%3D&reserved=0

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
e

Re: VM system name

[Neale Ferguson]

What about a JSON output option?


 Original message 
From: "van Sleeuwen, Berry" 
Date: 8/4/20 18:04 (GMT+10:00)
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] VM system name

I think the underscore would be required. If the output is processed by some 
script it's easier to select the word. If the underscore is omitted then word 5 
for instance is not always the number of IFLs.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Timothy Sipples
Sent: Tuesday, 4 August 2020 07:57
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Would this readout make better sense?

$ zhypinfo
  NoLayer   TypeName IFL CP
  --
  2.2   z/VM_Guest  guest   myguest2  0
  2.1   z/VM_Resource_Pool  poolpooltest   3  0
  2.0   z/VMhypervisor  myzvm  8  0
  1 partition   guest   S38LP43   10  0
  0 machine hostS38   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.

Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they for 
parsing?) 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. And would it make sense to print the hypervisor 
release level in the Layer column, e.g. "z/VM 7.2"?

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. And how about a little more insight in the Type column for 
partition and machine?

What happens with SMT2 v. SMT1 in this readout? (Should something happen?)

Putting these suggestions all together except for the SMT2 one, plus some 
others, here's what you might end up with:

$ zhypinfo
  # Layer Type  NameIFLsCPs
  
  2.2   Linux 4.18guest myguest2  0
  2.1   z/VM 7.2  pool  pooltest   3  0
  2.0   z/VM 7.2  hypervisormyzvm  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.

"Fun" question: what should a z/OS Container Extensions readout look like?

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.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7C991fdad0d7724869c05d08d8383b5db1%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637321174909186781&sdata=j1Q%2Ba2kLrzED%2BoxpX%2BGwUVIcJsPNV2OpIOCHxHGg5gU%3D&reserved=0

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any d

Re: VM system name

[Cornelia Huck]

On Tue, 4 Aug 2020 09:33:38 +0200
Stefan Raspl  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
> >   NoLayer   TypeName IFL CP
> >   --
> >   2.2   z/VM_Guest  guest   myguest2  0
> >   2.1   z/VM_Resource_Pool  poolpooltest   3  0
> >   2.0   z/VMhypervisor  myzvm  8  0
> >   1 partition   guest   S38LP43   10  0
> >   0 machine hostS38   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"?
>
> H, 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 host, but the cpu model used for the VM is z,
displaying a model of z while the guest actually sees a z could
be confusing.

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

Re: VM system name

[van Sleeuwen, Berry]

Ah, didn't think of that. Stefan indeed already mentioned that.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Neale Ferguson
Sent: Tuesday, 4 August 2020 10:14
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

What about a JSON output option?


 Original message 
From: "van Sleeuwen, Berry" 
Date: 8/4/20 18:04 (GMT+10:00)
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] VM system name

I think the underscore would be required. If the output is processed by some 
script it's easier to select the word. If the underscore is omitted then word 5 
for instance is not always the number of IFLs.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Timothy Sipples
Sent: Tuesday, 4 August 2020 07:57
To: LINUX-390@VM.MARIST.EDU
Subject: Re: VM system name

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Would this readout make better sense?

$ zhypinfo
  NoLayer   TypeName IFL CP
  --
  2.2   z/VM_Guest  guest   myguest2  0
  2.1   z/VM_Resource_Pool  poolpooltest   3  0
  2.0   z/VMhypervisor  myzvm  8  0
  1 partition   guest   S38LP43   10  0
  0 machine hostS38   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.

Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they for 
parsing?) 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. And would it make sense to print the hypervisor 
release level in the Layer column, e.g. "z/VM 7.2"?

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. And how about a little more insight in the Type column for 
partition and machine?

What happens with SMT2 v. SMT1 in this readout? (Should something happen?)

Putting these suggestions all together except for the SMT2 one, plus some 
others, here's what you might end up with:

$ zhypinfo
  # Layer Type  NameIFLsCPs
  
  2.2   Linux 4.18guest myguest2  0
  2.1   z/VM 7.2  pool  pooltest   3  0
  2.0   z/VM 7.2  hypervisormyzvm  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.

"Fun" question: what should a z/OS Container Extensions readout look like?

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.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CBerry.vanSleeuwen%40atos.net%7Cf995c6394e9c4d45af5608d8384e7348%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C1%7C637321256889665657&sdata=FPZOXYm9oMfEdjoL8%2BHIaQ7rJcvC96nhA4EYxME5hY4%3D&reserved=

Re: VM system name

[Stefan Raspl]

Hi Berry,

On 2020-08-04 10:39, van Sleeuwen, Berry wrote:
> Ah, didn't think of that. Stefan indeed already mentioned that.

Yeah, so we would have both: The underscores to make the output easy to parse in
scripts (for simple needs), and the json output for power users that are short
of programming against qclib proper.



> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
> Berry van Sleeuwen
> Flight Forum 3000 5657 EW Eindhoven
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Neale Ferguson
> Sent: Tuesday, 4 August 2020 10:14
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: VM system name
> 
> Caution! External email. Do not open attachments or click links, unless this 
> email comes from a known sender and you know the content is safe.
> 
> What about a JSON output option?
> 
> 
>  Original message 
> From: "van Sleeuwen, Berry" 
> Date: 8/4/20 18:04 (GMT+10:00)
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] VM system name
> 
> I think the underscore would be required. If the output is processed by some 
> script it's easier to select the word. If the underscore is omitted then word 
> 5 for instance is not always the number of IFLs.
> 
> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
> Sleeuwen Flight Forum 3000 5657 EW Eindhoven
> 
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Timothy Sipples
> Sent: Tuesday, 4 August 2020 07:57
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: VM system name
> 
> Caution! External email. Do not open attachments or click links, unless this 
> email comes from a known sender and you know the content is safe.
> 
> Would this readout make better sense?
> 
> $ zhypinfo
>   NoLayer   TypeName IFL CP
>   --
>   2.2   z/VM_Guest  guest   myguest2  0
>   2.1   z/VM_Resource_Pool  poolpooltest   3  0
>   2.0   z/VMhypervisor  myzvm  8  0
>   1 partition   guest   S38LP43   10  0
>   0 machine hostS38   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.
> 
> Are the underscores necessary? Maybe "z/VM guest" instead? (Or are they for 
> parsing?) 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. And would it make sense to print the hypervisor 
> release level in the Layer column, e.g. "z/VM 7.2"?
> 
> 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. And how about a little more 
> insight in the Type column for partition and machine?
> 
> What happens with SMT2 v. SMT1 in this readout? (Should something happen?)
> 
> Putting these suggestions all together except for the SMT2 one, plus some 
> others, here's what you might end up with:
> 
> $ zhypinfo
>   # Layer Type  NameIFLsCPs
>   
>   2.2   Linux 4.18guest myguest2  0
>   2.1   z/VM 7.2  pool  pooltest   3  0
>   2.0   z/VM 7.2  hypervisormyzvm  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.
> 
> "Fun" question: what should a z/OS Container Extensions readout look like?
> 
> 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.

Re: VM system name

[Stefan Raspl]

Hi Conny,

On 2020-08-04 10:32, Cornelia Huck wrote:
> On Tue, 4 Aug 2020 09:33:38 +0200
> Stefan Raspl  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
>>>   NoLayer   TypeName IFL CP
>>>   --
>>>   2.2   z/VM_Guest  guest   myguest2  0
>>>   2.1   z/VM_Resource_Pool  poolpooltest   3  0
>>>   2.0   z/VMhypervisor  myzvm  8  0
>>>   1 partition   guest   S38LP43   10  0
>>>   0 machine hostS38   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"?
>>
>> H, 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 host, but the cpu model used for the VM is z,
> displaying a model of z while the guest actually sees a z could
> be confusing.

So far, we'r

Re: VM system name

[Ingo Adlung]

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  wrote on 04/08/2020 11:54:37:

> From: Stefan Raspl 
> 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 
>
> Hi Conny,
>
> On 2020-08-04 10:32, Cornelia Huck wrote:
> > On Tue, 4 Aug 2020 09:33:38 +0200
> > Stefan Raspl  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
> >>>   NoLayer   TypeName IFL CP
> >>>   --
> >>>   2.2   z/VM_Guest  guest   myguest2  0
> >>>   2.1   z/VM_Resource_Pool  poolpooltest   3  0
> >>>   2.0   z/VMhypervisor  myzvm  8  0
> >>>   1 partition   guest   S38LP43   10  0
> >>>   0 machine hostS38   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"?
> >>
> >> H, 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, f

Re: VM system name

[Stefan Raspl]

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  wrote on 04/08/2020 11:54:37:
> 
>> From: Stefan Raspl 
>> 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 
>>
>> Hi Conny,
>>
>> On 2020-08-04 10:32, Cornelia Huck wrote:
>>> On Tue, 4 Aug 2020 09:33:38 +0200
>>> Stefan Raspl  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
>   NoLayer   TypeName IFL CP
>   --
>   2.2   z/VM_Guest  guest   myguest2  0
>   2.1   z/VM_Resource_Pool  poolpooltest   3  0
>   2.0   z/VMhypervisor  myzvm  8  0
>   1 partition   guest   S38LP43   10  0
>   0 machine hostS38   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"?

 H, 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 co

Re: VM system name

[David Boyes]

> Not so sure about the format, though - the one above is hard to read, and I
> would claim it might be prone to produce errors on all parties involved - e.g.
> whenever we add further fields. Something that correlates the values to a 
> field
> name is preferable - maybe something like JSON could do the job here!

Which was kind of the point of the comment; most of the things that will 
consume the output of the command are not human, so readability isn't a concern 
unless you request the  extra icing of human-readable output via --verbose. 
Parsing simplicity is the paramount concern here.

I'm not a huge fan of JSON, but I can see that it would be a useful method;  
might also consider XML as well. The semantics of both XML and JSON processing 
would be expensive to generate (lots of wrapping/unwrapping involved). 
Awk-friendly is good. __

> One could always do that by post-processing the output. Also, this would need
> some semantics: We should likely count virtalization layers, not levels. 
> Because
> e.g. z/VM can or can not have a Resource Pool defined. As one does not know in
> advance, it should not be counted. But then again, that makes it a bit more
> complicated. I'd likely push that out as a future item.

Fair enough, was just an idea of some useful function. Since you have a record 
type field available, I had envisioned it as a kind of variant record that you 
parsed depending on what the record type is. If you keep the record type in 
each line of the output, expansion for new values wouldn't be a big deal.

> Something like that is already available in the underlying library, although 
> it
> counts levels/layers, not _virtualization_ levels. Makes sense to keep it 
> that way.

Ok. Since I can't see the capability of the code you've got to play with, that 
seems to be a good place to start.

> There's a field like that available, but not in every layer. However, this is
> really easy to derive from the output, so not sure if I'd want to add it...

Yeah, there's always that argument of what combinations of features merit 
packaging as a command-line option as a shortcut. I would find that number 
useful as a "feature", YMMV. 

> 6. (nit) in the verbose output, provide a way to provide a format string 
option, eg:
> 
> ./qc_test --verbose --format="30:8.3" 
> 
> qc_capability [S ] : 552.000
> qc_secondary_capability [S  ]  : 552.000
> qc_capacity_adjustment_indication [S  ]: 100.000
> qc_capacity_change_reason [S  ]:   0.000

> Uh, yeah, well, another 'future' I would say.

Yeah, ok. There are some libraries in the GNU world that provide this kind of 
function generically, but agree that it doesn't need to be there day 1. The 
idea was to make the output more useful/easier to parse in languages that have 
fixed format input records (eg COBOL or PL/1), but no matter. Works for me.

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

Re: VM system name

[Alan Ackerman]

I said:

Yes! I spent a fair amount of time writing EXECs to figure these things out 
when I worked for Bank of America. I put the results on a web page that listed 
all our VM systems. I’m retired so I don’t need it any more. 

Mark said:

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?

I think it's rude of you to post a question to a public forum and then tell me 
I have no say because I'm retired. 

I've been involved with VM for 46 years and I think my opinion has some value.

And I could have used your tool when I was working.

I don't want to get involved with Red Hat versus SUSE. I think if you release 
the tool for SUSE, it will be up to Red Hat what they decide to do, not me.

Alan Ackerman
alan.ackerma...@gmail.com



On Jul 20, 2020, at 12:16 PM, Mark Post  wrote:

On 7/20/20 1:09 PM, Stewart, Lee wrote:
> +1

OK, that's one (sorry, but retirees who won't use the tool don't help
the business case). Anyone else?


Mark Post

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


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

Re: VM system name

[Mark Post]

On 10/3/20 8:10 PM, Alan Ackerman wrote:
> I think it's rude of you to post a question to a public forum and then tell 
> me I have no say because I'm retired. 

It's been over two months, Alan. Have you been holding on to this that
whole time?

I participate in this mailing list for a variety of reasons. First, I
believe in the platform and want to see it succeed.
Second, I'm trying to give back to the community for all the help I
received when I needed it back in 2000 and later.
Third, I like helping people.
Fourth, I want to show people that SUSE takes an interest in this
platform, more so than any other distribution provider.
Fifth, to show that SLES is the superior Linux for Z distribution and
that we want to take good care of our customers.

I have a fair amount of leeway in how I spend my time on the mailing
list. I've never received any criticism from anyone at SUSE for helping
Red Hat customers, or those of any other non-SUSE distribution. My
management also views that as good for the platform, and so also good
for SUSE.

When it comes to spending a fair amount of time and company resources
developing a tool that may or may not be useful to my customers, I have
to be a bit more business minded. So, doing something just because I
think it might be a good idea is not something I do very often. I want
to hear from our customers about that. And I say it that way because as
much as I support the platform in general, over the years I've been
watching them, Red Hat has a definite tendency towards the "not invented
here" type of thinking. They have surprised me from time to time, but I
don't count on that.

So when I say your vote in favor didn't really count in my data
gathering process, it's not about you, per se. I needed to hear from
people currently working that might possibly use the tool because
they're familiar with how their installation does things such as
automation or reporting, etc. AND, that are actually our customers
because I know that whatever I put out there will indeed become
available to them, and be supported.

> I've been involved with VM for 46 years and I think my opinion has some value.

In a general sense, sure, but not necessarily to making a *business*
decision for SUSE.

> And I could have used your tool when I was working.

See above for why I have to discount that.

I try, as much as possible, to be honest and *direct* when dealing with
people, whether in my personal or professional life. Sometimes the
directness may be too direct. My intention is (rarely) ever to be rude
to anyone. If the way I worded things came across that way and caused
offense (as you say it has done) then I apologize for that. I will try
to avoid doing that again in the future.


Mark Post

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

Re: VM system name

[Alan Ackerman]

I’m sorry. A great deal of email on my Mac disappeared last summer and recently 
reappeared.  I’ m going back and trying to respond to old emails. I don’t know 
what happened. I installed the beta version on MacOSX Big Sur last summer and 
I’m guessing that caused email to disappear and when Apple fixed it the email 
reappeared. 

Perhaps I should include a disclaimer with all my replies. 

I didn’t know you were only offering this for SUSE. If I’d known I would not 
have replied. 

Sent from my iPhone

On Oct 4, 2020, at 11:02 AM, Mark Post  wrote:

On 10/3/20 8:10 PM, Alan Ackerman wrote:
> I think it's rude of you to post a question to a public forum and then tell 
> me I have no say because I'm retired. 

It's been over two months, Alan. Have you been holding on to this that
whole time?

I participate in this mailing list for a variety of reasons. First, I
believe in the platform and want to see it succeed.
Second, I'm trying to give back to the community for all the help I
received when I needed it back in 2000 and later.
Third, I like helping people.
Fourth, I want to show people that SUSE takes an interest in this
platform, more so than any other distribution provider.
Fifth, to show that SLES is the superior Linux for Z distribution and
that we want to take good care of our customers.

I have a fair amount of leeway in how I spend my time on the mailing
list. I've never received any criticism from anyone at SUSE for helping
Red Hat customers, or those of any other non-SUSE distribution. My
management also views that as good for the platform, and so also good
for SUSE.

When it comes to spending a fair amount of time and company resources
developing a tool that may or may not be useful to my customers, I have
to be a bit more business minded. So, doing something just because I
think it might be a good idea is not something I do very often. I want
to hear from our customers about that. And I say it that way because as
much as I support the platform in general, over the years I've been
watching them, Red Hat has a definite tendency towards the "not invented
here" type of thinking. They have surprised me from time to time, but I
don't count on that.

So when I say your vote in favor didn't really count in my data
gathering process, it's not about you, per se. I needed to hear from
people currently working that might possibly use the tool because
they're familiar with how their installation does things such as
automation or reporting, etc. AND, that are actually our customers
because I know that whatever I put out there will indeed become
available to them, and be supported.

> I've been involved with VM for 46 years and I think my opinion has some value.

In a general sense, sure, but not necessarily to making a *business*
decision for SUSE.

> And I could have used your tool when I was working.

See above for why I have to discount that.

I try, as much as possible, to be honest and *direct* when dealing with
people, whether in my personal or professional life. Sometimes the
directness may be too direct. My intention is (rarely) ever to be rude
to anyone. If the way I worded things came across that way and caused
offense (as you say it has done) then I apologize for that. I will try
to avoid doing that again in the future.


Mark Post

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

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