Re: cio_ignore

2021-01-07 Thread Mark Post
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

2021-01-07 Thread Bill Head
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

2021-01-07 Thread Cohen, Sam
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

2021-01-07 Thread Viktor Mihajlovski

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

2021-01-07 Thread Bill Head
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

2021-01-07 Thread Dan Horák
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

2021-01-07 Thread Rinaldo Akio Uehara
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

2021-01-06 Thread Bill Head
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

2015-01-13 Thread Ingo Adlung
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

2015-01-12 Thread Mike Walter
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

2015-01-12 Thread Linker Harley - hlinke
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

2015-01-12 Thread Mark Post
 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

2015-01-12 Thread Linker Harley - hlinke
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

2015-01-12 Thread Mark Post
 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

2015-01-12 Thread Cohen, Sam
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

2015-01-12 Thread Robert J Brenneman
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

2015-01-12 Thread James Tison
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

2015-01-12 Thread Mike Walter
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

2012-04-02 Thread Alan Altmark
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

2012-03-31 Thread R P Herrold

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

2012-03-30 Thread Lee Stewart

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

2012-03-30 Thread Sebastian Ott
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

2012-03-30 Thread Mark Post
 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

2012-03-30 Thread Lee Stewart

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/