Re: cio_ignore
On 1/7/21 1:58 PM, Cohen, Sam wrote: > If you're running under z/VM with a class G (or lower) user, why use > cio_ignore at all? Your hypervisor will only allow you to see what should be > seen. Even without z/VM, you can limit the devices visible to the LPAR via > IOCDS statements. I don't have cio_ignore on the startup of any of my RHEL > guests (although I do use dasd.conf and zfcp.conf). I, and others, have been saying the same thing for years. This feature was initially implemented simply because when people were doing an installation in an LPAR, booting was taking too long. It was taking too long because many customers make all I/O devices available to all their LPARs, and those customers tend to have a *lot* of I/O devices. The kernel can take quite some time to probe them all. When SUSE first shipped that feature, we made the mistake of inserting cio_ignore into the kernel parms by default. That caused problems like this one, and we changed the installer so that installs performed in a virtualized environment did not insert cio_ignore. I.e., z/VM and KVM. That eliminated a large number of customer problems. 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: cio_ignore
Thank you Viktor!! Right you are, I should have used chzdev instead of znetconf -a. The devices are displaying as Pers YES with the lszdev command. I removed the devices from the /etc/dasd.conf file (temporarily added them there so they wouldn't be ignored), rebooted and they are active. Thank you, Bill Bill Head Lead Systems Engineer z/VM Mainframe Support IBM Global Technology Services-Solutions Humana: Contractor/Temporary Staff – IT Systems Technician /Office: (502) 262-7563 Email: bh...@humana.com bEmail: billh...@us.ibm.com -Original Message- From: Linux on 390 Port On Behalf Of Viktor Mihajlovski Sent: Thursday, January 7, 2021 4:02 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: cio_ignore [External Email: Use caution with links and attachments] On 1/7/21 4:41 AM, Bill Head wrote: > On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from > the blacklist but when I reboot they are exluded again: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > 0.0.1000-0.0.1002 > 0.0.2000-0.0.2002 > > After the reboot: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > > It's ignoring 1000-1002, and 2000-2002. > > cio_ignore settings are supposed to survive a boot, correct? > > [snip] That's not the case. Upon reboot, the kernel command line determines the devices seen by the operating system. In a next step the configured devices are been freed from the ignore list. In your example the console (0009), the boot disk (0150) and two QETH devices (0300-0302, 0700-0702) are removed from the ignore list. If you want 1000-1002 and 2000-2002 to be persistently available you should configure them, e.g. using chzdev(8). -- Kind Regards, Viktor -- 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.com/v3/__http://www2.marist.edu/htbin/wlvindex?LINUX-390__;!!IfVdvpvC!E5pGzxyHs8IlBGAvXegBzz1l_wiY6yiJRGV440a0u2bNoZlHzzmIOXihb-rW$ The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- 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: cio_ignore
If you're running under z/VM with a class G (or lower) user, why use cio_ignore at all? Your hypervisor will only allow you to see what should be seen. Even without z/VM, you can limit the devices visible to the LPAR via IOCDS statements. I don't have cio_ignore on the startup of any of my RHEL guests (although I do use dasd.conf and zfcp.conf). Thanks, Sam (217) 862-9227 (office) (602) 327-2134 (cell) -Original Message- From: Linux on 390 Port On Behalf Of Viktor Mihajlovski Sent: Thursday, January 7, 2021 02:02 To: LINUX-390@VM.MARIST.EDU Subject: Re: cio_ignore On 1/7/21 4:41 AM, Bill Head wrote: > On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from > the blacklist but when I reboot they are exluded again: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > 0.0.1000-0.0.1002 > 0.0.2000-0.0.2002 > > After the reboot: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > > It's ignoring 1000-1002, and 2000-2002. > > cio_ignore settings are supposed to survive a boot, correct? > > [snip] That's not the case. Upon reboot, the kernel command line determines the devices seen by the operating system. In a next step the configured devices are been freed from the ignore list. In your example the console (0009), the boot disk (0150) and two QETH devices (0300-0302, 0700-0702) are removed from the ignore list. If you want 1000-1002 and 2000-2002 to be persistently available you should configure them, e.g. using chzdev(8). -- Kind Regards, Viktor -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=04%7C01%7CSam.Cohen%40LRS.COM%7C4914a36e82ad41d989a708d8b33822e2%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C637456400978625526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JH%2BJPDl%2FX2Xgyhi%2BdOU0y%2Bk5RCcBeExuKMTTxupu324%3Dreserved=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: cio_ignore
On 1/7/21 4:41 AM, Bill Head wrote: On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from the blacklist but when I reboot they are exluded again: cio_ignore -L Devices that are not ignored: = 0.0.0009 0.0.0150 0.0.0300-0.0.0301 0.0.0700-0.0.0702 0.0.1000-0.0.1002 0.0.2000-0.0.2002 After the reboot: cio_ignore -L Devices that are not ignored: = 0.0.0009 0.0.0150 0.0.0300-0.0.0301 0.0.0700-0.0.0702 It's ignoring 1000-1002, and 2000-2002. cio_ignore settings are supposed to survive a boot, correct? [snip] That's not the case. Upon reboot, the kernel command line determines the devices seen by the operating system. In a next step the configured devices are been freed from the ignore list. In your example the console (0009), the boot disk (0150) and two QETH devices (0300-0302, 0700-0702) are removed from the ignore list. If you want 1000-1002 and 2000-2002 to be persistently available you should configure them, e.g. using chzdev(8). -- Kind Regards, Viktor -- 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: cio_ignore
That makes sense, thank you. The adapter that's configured to use the vswitch (enc700) is surviving a boot but the adapters configured to use dedicated devices are not. Which might explain why they are ignored after a boot. Until I can get this lined out I added them to the dasd configuration file and see if that will work, at least temporarily. Here's my problem: Running GDPS Proxy guests, which run xDR/SA MP. GDPS controlling software runs on z/OS and issues commands and reads in EREP data from LINUX Proxy guests running on each z/VM LPAR. Currently that's SuSE and I've been tasked to migrate the software to RHEL. I'm more familiar with SuSE but I spend most of my time now working on z/VM. Also, I'm going from a back level SuSE OS (SLES 11) to RHEL 8. GDPS requires using dedicated network adapters instead of VSWITCH setup as well as no V-Disk, nothing in memory so GDPS can successfully hyperswap all the DASD from one site to another in the event of a storage failure. I set this up on SuSE a couple of years ago and it works. I have one vswitch attached adapter that is working and is on VLAN 14, address enc700 (0.0.700, 0.0.701, 0.0.702). I'm using this to connect and configure the bonded network. I have the original SuSE guest down and I'm using its OSA device addresses and its IP address, which is on VLAN 10. I'm thinking that this guest can be configured on two different VLANs, if that's not possible then I'll need to configure by logging on as the guest and doing it from a 3270 session, which I'm trying to avoid. This are the statements in the users directory profile for both the vswitch attached adapter and the dedicated ones: * QDIO ADDRESS CHPID E5 --- DEDICATE 1000 03C8 DEDICATE 1001 03C9 DEDICATE 1002 03CA * QDIO ADDRESS CHPID E6 --- DEDICATE 2000 03D8 DEDICATE 2001 03D9 DEDICATE 2002 03DA * NICDEF 0700 TYPE QDIO LAN SYSTEM LVSQ01 PORTTYPE ACCESS NICDEF 0700 VLAN 14 * So, I have to set up a bonded network to two OSA adapters and use VLAN tagging. From the RHEL reference manual I've tried this: cio_ignore -r 0.0.1000,0.0.1001,0.0.1002 cio_ignore -r 0.0.2000,0.0.2001,0.0.2002 znetconf -u znetconf -a 1000 znetconf -a 2000 lszdev TYPE ID ON PERS NAMES dasd-eckd0.0.0150 yes nodasda qeth 0.0.0700:0.0.0701:0.0.0702 yes noenc700 qeth 0.0.1000:0.0.1001:0.0.1002 yes noenc1000 qeth 0.0.2000:0.0.2001:0.0.2002 yes noenc2000 generic-ccw 0.0.0009yes no nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup" nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname enc1000 master bond0 nmcli connection add type ethernet slave-type bond con-name bond0-port2 ifname enc2000 master bond0 nmcli con add type vlan con-name VLAN10 dev bond0 id 10 ip4 xxx.xxx.xxx.xxx/24 gw4 xxx.xxx.xxx.xxx Then I edited to add DNS servers, turn off IPV6, set MAC addresses, etc. I edited ifcfg-bond0 like so: BONDING_OPTS=mode=active-backup TYPE=Bond BONDING_MASTER=yes PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=static DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=no IPV6_DEFROUTE=no IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=bond0 UUID=5876e0bb-cce2-4241-8a0b-e60ad3fb6578 DEVICE=bond0 ONBOOT=yes Ifcfg-bond0-port1: TYPE=Ethernet NAME=bond0-port1 UUID=07f14ea9-dd07-47ac-a741-57e2c7bbe20d DEVICE=enc1000 ONBOOT=yes MASTER=bond0 SLAVE=yes LLADDR=02:00:00:00:01:CD Ifcfg-bond0-port2: TYPE=Ethernet NAME=bond0-port2 UUID=e46e478a-d98b-4ae2-af6e-9eb7d46216ed DEVICE=enc2000 ONBOOT=yes MASTER=bond0 SLAVE=yes LLADDR=02:00:00:00:01:DC Ifcfg-VLAN10 (IP addresses x'd out): VLAN=yes TYPE=Vlan PHYSDEV=bond0 VLAN_ID=10 REORDER_HDR=yes GVRP=no MVRP=no HWADDR= PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=xxx.xxx.xxx.xxx PREFIX=24 NETMASK=255.255.255.0 GATEWAY=xxx.xxx.xxx.xxx DNS1=xxx.xxx.xxx.xxx DNS2=xxx.xxx.xxx.xxx DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=no IPV6_DEFROUTE=no IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=VLAN10 UUID=a72d91e3-29bf-41d2-b406-a7583bc9eb41 ONBOOT=yes nmcli con reload nmcli con up VLAN10 I set enc700 to not start on boot. When I reboot I can't get to it from the network. I put the dedicated addresses in /etc/dasd.conf and I can see them logged on as the user
Re: cio_ignore
On Thu, 7 Jan 2021 03:41:07 + Bill Head wrote: > On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from > the blacklist but when I reboot they are exluded again: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > 0.0.1000-0.0.1002 > 0.0.2000-0.0.2002 > > After the reboot: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > > It's ignoring 1000-1002, and 2000-2002. > > cio_ignore settings are supposed to survive a boot, correct? the device id list to "un-ignore" is created dynamicaly during the boot based on the content of /etc/dasd.conf, /etc/zfcp.conf and the network interface configuration. Dan -- 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: cio_ignore
No. They are not persistent. You should add each address to /etc/dasd.conf Enviado do meu iPhone > Em 7 de jan. de 2021, à(s) 00:42, Bill Head escreveu: > > On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from > the blacklist but when I reboot they are exluded again: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > 0.0.1000-0.0.1002 > 0.0.2000-0.0.2002 > > After the reboot: > > cio_ignore -L > Devices that are not ignored: > = > 0.0.0009 > 0.0.0150 > 0.0.0300-0.0.0301 > 0.0.0700-0.0.0702 > > It's ignoring 1000-1002, and 2000-2002. > > cio_ignore settings are supposed to survive a boot, correct? > > > > > > > > The information transmitted is intended only for the person or entity to > which it is addressed > and may contain CONFIDENTIAL material. If you receive this > material/information in error, > please contact the sender and delete or destroy the material/information. > > Humana Inc. and its subsidiaries comply with applicable Federal civil rights > laws and > do not discriminate on the basis of race, color, national origin, ancestry, > age, disability, sex, > marital status, gender, sexual orientation, gender identity, or religion. > Humana Inc. and its subsidiaries do not > exclude people or treat them differently because of race, color, national > origin, ancestry, age, > disability, sex, marital status, gender, sexual orientation, gender identity, > or religion. > > English: ATTENTION: If you do not speak English, language assistance > services, free > of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). > > Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición > servicios > gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). > > 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 > 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 > > Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen > sèvis èd > pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). > > Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z > bezpłatnej > pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). > > 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 > 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. > > -- > 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
cio_ignore
On RHEL 8.2 I'm having a problem with cio_ignore. I can remove devices from the blacklist but when I reboot they are exluded again: cio_ignore -L Devices that are not ignored: = 0.0.0009 0.0.0150 0.0.0300-0.0.0301 0.0.0700-0.0.0702 0.0.1000-0.0.1002 0.0.2000-0.0.2002 After the reboot: cio_ignore -L Devices that are not ignored: = 0.0.0009 0.0.0150 0.0.0300-0.0.0301 0.0.0700-0.0.0702 It's ignoring 1000-1002, and 2000-2002. cio_ignore settings are supposed to survive a boot, correct? The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- 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: cio_ignore vs Linux in System z
Indeed, as pointed out by other folks this feature was introduced in our very early days, when clients started to install Linux into LPARs with possibly tens of thousands of devices they would need if IPLing z/OS into it. Not only did it take long to boot, but we initially only operated on the first 1024 devices found, and didn't have plugging rules yet. And other z/OS holding permanent RESERVEs on shared ECKD devices it owned didn't help much either. We'd discussed whether to introduce black lists or white lists addressing the challenges at hand and eventually implemented both. Much has changed since then and whether it should be a default or not is a valid discussion to have. You may consider it paranoia but its introduction served a purpose - and still does. If running under z/VM and/or if using Linux in LPAR with your IODF written in a way that only devices the LPAR is supposed to operate on are configured to it you can presumably safely turn it off. Best regards Ingo Ingo AdlungIBM Deutschland Research IBM Distinguished Engineer Development GmbH Chief Architect, System z Vorsitzender des Aufsichtsrats: Virtualization Linux Martina Koederitz mail: adl...@de.ibm.comGeschäftsführung: Dirk Wittkopp phone: +49-7031-16-4263Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 12.01.2015 20:43:00: From: Mike Walter mike.wal...@aon.com To: LINUX-390@VM.MARIST.EDU Date: 12.01.2015 20:43 Subject: Re: [LINUX-390] cio_ignore vs Linux in System z Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 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/ -- 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: 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/
Re: cio_ignore
On Friday, 03/30/2012 at 03:19 EDT, Lee Stewart lstewart.dsgr...@attglobal.net wrote: cio_ignore=all,!009 appears to be the default, at least on RH 6.2... Certainly not added by us... IMO, Linux should be willing to recognize 009 and 01F as consoles, by default. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training 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
On Fri, 30 Mar 2012, Mark Post wrote: On 3/30/2012 at 11:31 AM, Lee Stewart lstewart.dsgr...@attglobal.net wrote: I've been trying to think of any reason to ever have cio_ignore in a VM guest. I can see real use for it in an LPAR where you may have thousands of devices that have nothing to do with the Linux instance. But in a virtual machine I only give it the devices I want it to have in the first place. I'm guessing this is a Red Hat customer, correct? I see mention of it on slide 24 in Brad Hinson's (of Red Hat) presentation at: http://www.vm.ibm.com/education/lvc/lvc1215c.pdf which is part of a larger presentation on Red Hat's approach of a single unified code base for both virtualized and 'real' hardware (I too am not, nor have ever been an Red Hat employee, but my friend Google found the item for me) It would seem in a VM that one might want to disable devices that would otherwise be detected, for security reasons, and perhaps performance reasons -- Russ herrold 614 488 6954 -- 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
Hi all, I've been trying to think of any reason to ever have cio_ignore in a VM guest. I can see real use for it in an LPAR where you may have thousands of devices that have nothing to do with the Linux instance. But in a virtual machine I only give it the devices I want it to have in the first place. Teaching it to new comers, they can easily understand chccwdev -e as the logical equivalent of varying something online to VM or z/OS. With having to issue a cio_ignore -r then a chccwdev -e I keep getting asked why they have to vary it online twice. And I don't have any good answer... Thoughts? Insights? Thanks, Lee -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 996-7122 Email: lee.stew...@siriuscom.com Web: www.siriuscom.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
Lee, On Fri, 30 Mar 2012, Lee Stewart wrote: Hi all, I've been trying to think of any reason to ever have cio_ignore in a VM guest. I can see real use for it in an LPAR where you may have thousands of devices that have nothing to do with the Linux instance. But in a virtual machine I only give it the devices I want it to have in the first place. Teaching it to new comers, they can easily understand chccwdev -e as the logical equivalent of varying something online to VM or z/OS. With having to issue a cio_ignore -r then a chccwdev -e I keep getting asked why they have to vary it online twice. And I don't have any good answer... Thoughts? Insights? With cio_ignore you can modify the device blacklist. The reason you have to remove a device from the blacklist before you can use it is that you have added the device to the blacklist in the first place. So either you did a cio_ignore --add earlier or you have set the cio_ignore kernel parameter (most likely the latter). If you want linux to use all available device simply remove the cio_ignore kernel parameter. Regards, Sebastian Thanks, Lee -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 996-7122 Email: lee.stew...@siriuscom.com Web: www.siriuscom.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/ -- 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
On 3/30/2012 at 11:31 AM, Lee Stewart lstewart.dsgr...@attglobal.net wrote: I've been trying to think of any reason to ever have cio_ignore in a VM guest. I can see real use for it in an LPAR where you may have thousands of devices that have nothing to do with the Linux instance. But in a virtual machine I only give it the devices I want it to have in the first place. I'm guessing this is a Red Hat customer, correct? (I'm pretty sure we don't ship that as a default). I can't/won't speak for Red Hat, but like you I don't see a good reason to do that in a z/VM guest by default. Since the distribution provider can't know ahead of time what environment is going to be used for the install, it's not a bad default. LPAR customers tend to have thousands of devices genned, as you said. I think for a z/VM guest, it would be safe to remove it. 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
cio_ignore=all,!009 appears to be the default, at least on RH 6.2... Certainly not added by us... Lee On 3/30/2012 10:59 AM, Sebastian Ott wrote: Lee, On Fri, 30 Mar 2012, Lee Stewart wrote: Hi all, I've been trying to think of any reason to ever have cio_ignore in a VM guest. I can see real use for it in an LPAR where you may have thousands of devices that have nothing to do with the Linux instance. But in a virtual machine I only give it the devices I want it to have in the first place. Teaching it to new comers, they can easily understand chccwdev -e as the logical equivalent of varying something online to VM or z/OS. With having to issue a cio_ignore -r then a chccwdev -e I keep getting asked why they have to vary it online twice. And I don't have any good answer... Thoughts? Insights? With cio_ignore you can modify the device blacklist. The reason you have to remove a device from the blacklist before you can use it is that you have added the device to the blacklist in the first place. So either you did a cio_ignore --add earlier or you have set the cio_ignore kernel parameter (most likely the latter). If you want linux to use all available device simply remove the cio_ignore kernel parameter. Regards, Sebastian Thanks, Lee -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 996-7122 Email: lee.stew...@siriuscom.com Web: www.siriuscom.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/ -- 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/ -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 996-7122 Email: lee.stew...@siriuscom.com Web: www.siriuscom.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/
