Where to put Z/VM tools and utilities
I have a small z/vm system which is used to run linux and z/os test systems (I work for an ISV). My z/vm knowledge is mainly limited to what I have picked up from the z/linux Redbooks and the Getting Started guide. I now want to install some tools from the VM downloads web pages. Is there a standard or commonly used convention for where such tools should be stored? I found some sample instructions for installing pipeddr where the code was installed on the MAINT 191 for instance. I would not expect that to be a suitable location. Also, does IBM provide a list of various MAINT minidisks and their functions ? Keith Gooding -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Where to put Z/VM tools and utilities
Keith, As you can tell, it's more art than science. My tendency matches Jay's; I create a NOLOG user called LCLTOOLS and place all my tools on its 191 disk. I then create a nickname called TOOLS and use VMLINK TOOLS to access that disk. To create a nickname file, see the NAMES command (with VMLINK option) help screens. Thanks, Sam Cohen Levi, Ray Shoup, Inc. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of kwg Sent: Monday, January 12, 2015 2:54 AM To: LINUX-390@VM.MARIST.EDU Subject: Where to put Z/VM tools and utilities I have a small z/vm system which is used to run linux and z/os test systems (I work for an ISV). My z/vm knowledge is mainly limited to what I have picked up from the z/linux Redbooks and the Getting Started guide. I now want to install some tools from the VM downloads web pages. Is there a standard or commonly used convention for where such tools should be stored? I found some sample instructions for installing pipeddr where the code was installed on the MAINT 191 for instance. I would not expect that to be a suitable location. Also, does IBM provide a list of various MAINT minidisks and their functions ? Keith Gooding -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Where to put Z/VM tools and utilities
On Monday, 01/12/2015 at 09:46 EST, Cohen, Sam sam.co...@lrs.com wrote: As you can tell, it's more art than science. My tendency matches Jay's; I create a NOLOG user called LCLTOOLS and place all my tools on its 191 disk. I then create a nickname called TOOLS and use VMLINK TOOLS to access that disk. To create a nickname file, see the NAMES command (with VMLINK option) help screens. I prefer to use an SFS filepool in an ISFC collection so that I can update from anywhere and see those updates everywhere. (Second choice is connectivity via IPGATE.) Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Where to put Z/VM tools and utilities
Mother's rule of z/VM Service number 1: Never change anything IBM sends you Mother's rule of z/VM Service number 2: Never mix your stuff with IBM's stuff. In my shop we create a user in the directory named after our department and set the PW to NOLOG. We give that new user a 191 disk and control access to it with a RACF group so we can give the admins access. This prevents our stuff from getting in the way of the VM Service process and keeps it nicely contained in one place. As we grow we can add more disks to this user to keep tooling organized into groups of things that are likely to be needed together, and to make it easy to hand out access to tool A without also getting access to tool B. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Where to put Z/VM tools and utilities
Hi Keith, Usually the VM tools, as well as your local tools, can be put on a general tools disk. For instance, we have a shared minidisk that contains a lot of tools from various sources. Our sysprog users have this disk as 192 so that it will be attached as filemode D during logon. So I would suggest to create a minidisk for the VM Tools components. You might give MAINT an 192 disk. Any other sysprog users then needs a link to that 192 disk. As for minidisks and their function, Dave Jones has created a NAMES file for that. You might want to check it out. Have a look at http://listserv.uark.edu/cgi-bin/wa?A2=ind1412L=IBMVMF=S=X=DEF64E8CA30CBA477FY=berry.vansleeuwen%40atos.netP=258431. (This links to the message from Dave in the IBMVM archives at uark.edu. You might want to subscribe to that list as well.) Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van Sleeuwen -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of kwg Sent: Monday, January 12, 2015 10:54 AM To: LINUX-390@vm.marist.edu Subject: Where to put Z/VM tools and utilities I have a small z/vm system which is used to run linux and z/os test systems (I work for an ISV). My z/vm knowledge is mainly limited to what I have picked up from the z/linux Redbooks and the Getting Started guide. I now want to install some tools from the VM downloads web pages. Is there a standard or commonly used convention for where such tools should be stored? I found some sample instructions for installing pipeddr where the code was installed on the MAINT 191 for instance. I would not expect that to be a suitable location. Also, does IBM provide a list of various MAINT minidisks and their functions ? Keith Gooding -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ 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. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request.
Re: Where to put Z/VM tools and utilities
On 01/12/2015 09:20 AM, Robert J Brenneman wrote: Mother's rule of z/VM Service number 1: Never change anything IBM sends you Mother's rule of z/VM Service number 2: Never mix your stuff with IBM's stuff. Amen! But see below for an exception. In my shop we create a user in the directory named after our department and set the PW to NOLOG. We give that new user a 191 disk ... This, plus what Sam said about using VMLINK. VMLINK is your friend. And when using VMLINK, you can selectively put some things on minidisk and other things into SFS (like Alan suggested) as needed, without having to be wholly in one mode or the other. As a help when servicing, I like to have an ID for each product (or tool or package). Lock it down, but allow logon-by for maint. For minidisk, there must be an ID (see prior paragraph) to own the storage. Rather than 191, I recommend v/r/m for three or four levels. This is fun, though less flexible than SFS. For example, my copy of Arty's IUCVTRAP is at FIX19. I could have a user IUCVTRAP with disk 019 or F19. People would link that disk. (Using 'VMLINK' of course!) For each dotted level, you get 0 to 15 (last six in hex). SFS is simpler. For z/OS people on your team (or if it's just you), SFS might feel more natural, and that's a plus. Exception to Mother's rule #1: At a previous site, we had a small (read that as easy to maintain) mod to SYSPROF EXEC to conditionally drive LCLPROF EXEC. The latter then did as little as possible, but arranged for our local stuff to be quickly on-hand without keeping everyone's private PROFILE EXEC in synch. Sounds like you have a small enough team (just you? or others too?) that you might be able to get by with just doing it in PROFILE EXEC. Repeating what Sam said: more art than science. You'll get a handle on it. -- Rick Troth Senior Software Developer Velocity Software Inc. Mountain View, CA 94041 Main: (877) 964-8867 Direct: (614) 594-9768 ri...@velocitysoftware.com mailto:ri...@velocitysoftware.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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
Thanks, Sam, Jay, Jim, Harley, and Mark (and anyone else who may have replied since I looked at the log), There are no LPAR-only Linux servers running here, only those running (RHEL) under z/VM. I suspected that cio_ignore was something related to security (perhaps an auditor fearing that an errant z/VM sysprog might attach a wrong device address to a guest, or poor security rules coupled with use of VMCP would let the wrong Linux user access the wrong devices), or performance. It appears that the performance issue was the culprit, but not one of concern for me with only z/VM guests. I've shared the suggestions with our zLinux admins, who will probably make dynamic updates for the few PoC guests currently running, and the next Golden Image(s). Have to love this list, thanks again! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
Mike, Until you get around to disabling cio_ignore you can run the following command to update the blacklist when you add a volume to Linux to enable it to be seen: cio_ignore -r 0.0.vdev Harley Linker -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mike Walter Sent: Monday, January 12, 2015 1:43 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: cio_ignore vs Linux in System z Thanks, Sam, Jay, Jim, Harley, and Mark (and anyone else who may have replied since I looked at the log), There are no LPAR-only Linux servers running here, only those running (RHEL) under z/VM. I suspected that cio_ignore was something related to security (perhaps an auditor fearing that an errant z/VM sysprog might attach a wrong device address to a guest, or poor security rules coupled with use of VMCP would let the wrong Linux user access the wrong devices), or performance. It appears that the performance issue was the culprit, but not one of concern for me with only z/VM guests. I've shared the suggestions with our zLinux admins, who will probably make dynamic updates for the few PoC guests currently running, and the next Golden Image(s). Have to love this list, thanks again! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ *** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
On 1/12/2015 at 02:48 PM, Linker Harley - hlinke harley.lin...@acxiom.com wrote: Until you get around to disabling cio_ignore you can run the following command to update the blacklist when you add a volume to Linux to enable it to be seen: cio_ignore -r 0.0.vdev Better yes, just cio_ignore -R which will wipe out the whole list and need no further action when new devices are added. Just make sure zipl.conf gets updated and zipl rerun so things won't go back to the status quo at the next reboot. 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
Mike, I don't have this problem with my SLES 11 SP3 systems on System z as cio-ignore was not enabled, by default, at installation time. I encountered this problem with SLES 12 on System z as cio-ignore is enabled by default. I was just playing with SLES 12 to make note of the changes from SLES 11 . When I install SLES 12 in non-play mode, I will disable this option as we only allow a guest to see the dasd volumes that it needs. Harley Linker Acxiom Corporation P.S. I may see you at the upcoming CAVMEN meeting. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mike Walter Sent: Monday, January 12, 2015 11:09 AM To: LINUX-390@VM.MARIST.EDU Subject: cio_ignore vs Linux in System z The cio_ignore table within Linux (at least in RHEL6.5) is used to restrict access devices, both real and virtual. Being new the Linux on System z, this has become an occasional stumbling block for our Linux admins; when we z/VM sysprogs attach a new virtual or real device and the guest cannot see it immediately. I'm told that on distributed x86 (at least x86 here), the servers can see all the hardware. Is there a good reason that on Linux on System z the default is to prevent access to all devices unless they are manually removed from the cio_ignore table? I understand that an authorized user could attach a wrong device to a zLinux guest, so let's accept that risk as having been minimized. Are there other reasons to prevent every guest from accessing whatever devices are given to it? Thanks! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. FWIW, I subscribe in digest mode - so my responses may be slightly delayed. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ *** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
On 1/12/2015 at 12:13 PM, Cohen, Sam sam.co...@lrs.com wrote: Mike, This is a RedHat feature; it isn't an issue with SuSE. It is an SUSE, please. (It's been 11 years now.) implementation choice by the distributor. Beginning with SLES12, a feature request from IBM means that (by _changeable_ default), cio_ignore=all,!ipldev,!condev will be added to the kernel parms at install time. As others have indicated this is primarily intended for LPAR installs. I personally see no significant benefit to using it in a virtual machine, whether z/VM or KVM. It does provide a very noticeable speed up in booting an LPAR with even a relatively small number of devices defined. This will almost certainly be included in SLES11 SP4 as well. You can avoid the problems/confusion it causes by setting blacklisting of devices to off during the install process. Either way, it can be easily turned on or off afterward. 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Where to put Z/VM tools and utilities
On Monday, 01/12/2015 at 10:58 EST, Rick Troth ri...@velocitysoftware.com wrote: Exception to Mother's rule #1: At a previous site, we had a small (read that as easy to maintain) mod to SYSPROF EXEC to conditionally drive LCLPROF EXEC. The latter then did as little as possible, but arranged for our local stuff to be quickly on-hand without keeping everyone's private PROFILE EXEC in synch. Sounds like you have a small enough team (just you? or others too?) that you might be able to get by with just doing it in PROFILE EXEC. I remember when SYSPROF was added and people began to add support for a local profile simply to minimize the local mod to SYSPROF. Someday I should go see how many people have opened RFEs for this function Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
Mike, This is a RedHat feature; it isn't an issue with SuSE. It is an implementation choice by the distributor. Thanks, Sam Cohen Levi, Ray Shoup, Inc. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mike Walter Sent: Monday, January 12, 2015 10:09 AM To: LINUX-390@VM.MARIST.EDU Subject: cio_ignore vs Linux in System z The cio_ignore table within Linux (at least in RHEL6.5) is used to restrict access devices, both real and virtual. Being new the Linux on System z, this has become an occasional stumbling block for our Linux admins; when we z/VM sysprogs attach a new virtual or real device and the guest cannot see it immediately. I'm told that on distributed x86 (at least x86 here), the servers can see all the hardware. Is there a good reason that on Linux on System z the default is to prevent access to all devices unless they are manually removed from the cio_ignore table? I understand that an authorized user could attach a wrong device to a zLinux guest, so let's accept that risk as having been minimized. Are there other reasons to prevent every guest from accessing whatever devices are given to it? Thanks! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. FWIW, I subscribe in digest mode - so my responses may be slightly delayed. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
It's there for when you bring Linux up in an LPAR with bajillions of devices defined, like an old z/OS LPAR for example. The IPL takes forever as udev enumerates all those devices in /sys and /dev, and then you're running a system that can touch all the devices which it should not have access to. If you're running under z/VM, you can disable the cio_ignore feature entirely by removing the cio_ignore statement from the kernel paramater in /etc/zipl.conf and rewriting the ipltest with the zipl command. If you're running under LPAR, you really ought to be removing non Linux devices from the IODF access list anyway, but it does allow you an additional layer of configurability if you decide you want it. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: cio_ignore vs Linux in System z
It's also about efficiency. Recall that there aren't many other processors out there whose I/O architecture is built on (sub)channels. If the cio_ignore data indicates that signals arriving from certain channels needn't be processed, then that's less work the kernel has to engage in. In cases where the assignment of devices has been done in an imprecise manner, cio_ignore can be a godsend, allowing you to blacklist all devices except those which you know your machine uses. If cio_ignore is bothering you, it's rather easily dealt with -- you just have to remember to do it. See https://www.mail-archive.com/linux-390@vm.marist.edu/msg61591.html for an earlier (brief) discussion of practical living with cio_ignore. If you don't have any devices worthy of blacklisting, then just set up your kernel parm line to omit the cio_ignore specification altogether. Regards, --Jim-- -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
cio_ignore vs Linux in System z
The cio_ignore table within Linux (at least in RHEL6.5) is used to restrict access devices, both real and virtual. Being new the Linux on System z, this has become an occasional stumbling block for our Linux admins; when we z/VM sysprogs attach a new virtual or real device and the guest cannot see it immediately. I'm told that on distributed x86 (at least x86 here), the servers can see all the hardware. Is there a good reason that on Linux on System z the default is to prevent access to all devices unless they are manually removed from the cio_ignore table? I understand that an authorized user could attach a wrong device to a zLinux guest, so let's accept that risk as having been minimized. Are there other reasons to prevent every guest from accessing whatever devices are given to it? Thanks! Mike Walter Aon Corporation The opinions expressed herein are mine alone, not necessarily those of my employer. FWIW, I subscribe in digest mode - so my responses may be slightly delayed. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
