Re: Last Call: z/VM and Linux on z Systems Performance Class at Rutgers University 21st and 22nd of June
Traveling now. Can you give me the physical address for tomorrow's class? Regards, Scott Shumate Client Server Engineer IV Branch Banking & Trust Vice President DevEng Mainframe Support Mail Code: 100-99-09-10 Work: 252.246.2306 Cell: 252.373.6968 > On Jun 2, 2016, at 07:39, Magnelia Necoy wrote: > > Dear all, > > > Last chance to sign up for the Velocity Software Performance Class, we have > just a few seats left to fill! > Don’t miss out on this excellent training opportunity! > > Velocity Software Class: 21st & 22nd of June, Details: > http://velocitysoftware.com/rutgers.pdf > VM Workshop: 23rd-26th of June, Details: http://www.vmworkshop.org > > Best, > > > Magnelia Necoy > Managing Director > Global Sales and Marketing > > Velocity Software Inc. > 196-D Castro St > Mountain View, CA 94041 > > Office Main: (650) 964-8867 > Office Direct: (650 567-4300 > Cell: (303) 999-7646 > International: +49 1727671037 > Email: ne...@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/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission.
Parked IFLs on zVM 6.3
I'm running into something interesting and was wondering if anyone knows why? I have added to IFLs to my CEC and brought them online. The CEC is currently maxed out at 14 IFLs but IFLs 0E & 0F is parked. Why is the OS parking the IFLs when they should be in use since the CEC is maxed out? PROCESSOR 00 MASTER IFL PROCESSOR 0F PARKED IFL PROCESSOR 0E PARKED IFL PROCESSOR 0D ALTERNATE IFL PROCESSOR 0C ALTERNATE IFL PROCESSOR 01 ALTERNATE IFL PROCESSOR 02 ALTERNATE IFL PROCESSOR 03 ALTERNATE IFL PROCESSOR 04 ALTERNATE IFL PROCESSOR 05 ALTERNATE IFL PROCESSOR 06 ALTERNATE IFL PROCESSOR 07 ALTERNATE IFL PROCESSOR 08 ALTERNATE IFL PROCESSOR 09 ALTERNATE IFL PROCESSOR 0A ALTERNATE IFL PROCESSOR 0B ALTERNATE IFL Thanks Scott The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: DIRM problem
CONFIG99 DATADVH is committed out. /* PW_INTERVAL_FOR_GEN= 0 0 */ CONFIG DATADVH is not committed out. PW_INTERVAL_FOR_GEN= 0 0 Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, October 06, 2015 9:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem What does PW_INTERVAL_GEN have? The ultimate answer is to get the source for DVHSTPWC EXEC from MAINT630, run it through EXECUPDT, and then put traces in it. This is the program that issues the 3376 error. That's what I would do if I were on site. Alan Altmark Senior Managing Consultant IBM Systems Lab Services Shumate, Scott --- Re: [LINUX-390] DIRM problem --- From:"Shumate, Scott" To:"" Date:Tue, Oct 6, 2015 8:30 AMSubject:Re: [LINUX-390] DIRM problem I have 3 files. CONFIG DATADVH CONFIG99 DATADVH CONFIGSS DATADVH Out of the 3 files, 2 has PW_INTERVAL_FOR_SET= in it CONFIG DATADVH has it as PW_INTERVAL_FOR_SET= CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90 I committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC. It failed again with the following DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted. DVHPWU3376E Days can not exceed the current password expire value of 0 DVHPWU3376E for user LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC = DVHREQ2289E 3212. I restarted DIRMAINT and got the same results. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, October 06, 2015 2:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden wrote: > What do you have for all the configuration variables that start with > PW_ in > your CONFIG99 DATADVH file? The expire days should be set by > PW_INTERVAL_FOR_SET= according to the documentation. I'm guessing it > is not the default value or at least greater than zero. > > But - you say you also have RACF. In that case, forget all of the PW_ > settings because RACF is the one that will be managing the passwords. You > set the password change interval, etc. using the RAC SETROPTS (set > RACF > options) command. Nah. DIRMAINT still keeps track of when passwords were changed via DIRMAINT. Tearing the problem apart... DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG This error is because there is a problem with the PW_INTERVAL_FOR_SET statement. A DIRM ADD, CHNGID, or SETPW command (ADD, in this case) attempted to set the password validity interval to a value that is higher than the interval from the PW_INTERVAL_FOR_GEN statement (2nd value). The default is 97 days. There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is documented to have to values on it: The first value specifies the number of days a password is valid following one of the commands that set the password for a general user, the second value specifies the number of days a password is valid for a privileged user. The code doesn't do that. It assumes all users are general users as far as PW_INTERVAL_FOR_SET is concerned. I would do a DIRM CMS LISTFILE CONFIG* DATADVH * to see what configuration files are available. Then I would look in all of them for a PW_INTERVAL_FOR_SET statement. Not finding any, I would simply restart DIRMAINT. If you comment out a statement, RLDDATA won't always work since as far as it's concerned, nothing is overriding the existing value. You can just put a null value on it. PW_INTERVAL_FOR_SET= 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/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system with
Re: DIRM problem
But we are required to use RACF in our shop. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mauro Souza Sent: Tuesday, October 06, 2015 6:45 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem > I'm in the process of setting up DIRMAINT AND RACF to work together so > we can exploit SMAPI. If your goal is to exploit SMAPI, you don't need RACF. We use XCAT here, with SMAPI, without RACF, and works nicely. On Oct 6, 2015 03:23, "Alan Altmark" wrote: > On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden > wrote: > > What do you have for all the configuration variables that start with > > PW_ > in > > your CONFIG99 DATADVH file? The expire days should be set by > > PW_INTERVAL_FOR_SET= according to the documentation. I'm guessing > > it is not the default value or at least greater than zero. > > > > But - you say you also have RACF. In that case, forget all of the > > PW_ settings because RACF is the one that will be managing the passwords. > You > > set the password change interval, etc. using the RAC SETROPTS (set > > RACF > > options) command. > > Nah. DIRMAINT still keeps track of when passwords were changed via > DIRMAINT. > > Tearing the problem apart... > DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 > CONFIG > > This error is because there is a problem with the PW_INTERVAL_FOR_SET > statement. A DIRM ADD, CHNGID, or SETPW command (ADD, in this case) > attempted to set the password validity interval to a value that is > higher than the interval from the PW_INTERVAL_FOR_GEN statement (2nd > value). The default is 97 days. > > There is either a bug in the doc or a bug in the code. > PW_INTERVAL_FOR_GEN is documented to have to values on it: The first > value specifies the number of days a password is valid following one > of the commands that set the password for a general user, the second > value specifies the number of days a password is valid for a privileged user. > > The code doesn't do that. It assumes all users are general users as > far as PW_INTERVAL_FOR_SET is concerned. > > I would do a >DIRM CMS LISTFILE CONFIG* DATADVH * to see what configuration files > are available. Then I would look in all of them for a > PW_INTERVAL_FOR_SET statement. Not finding any, I would simply > restart DIRMAINT. If you comment out a statement, RLDDATA won't > always work since as far as it's concerned, nothing is overriding the > existing value. > > You can just put a null value on it. >PW_INTERVAL_FOR_SET= > > 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/ > -- 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 in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission.
Re: DIRM problem
I have 3 files. CONFIG DATADVH CONFIG99 DATADVH CONFIGSS DATADVH Out of the 3 files, 2 has PW_INTERVAL_FOR_SET= in it CONFIG DATADVH has it as PW_INTERVAL_FOR_SET= CONFIG99 DATADVH has it as PW_INTERVAL_FOR_SET= 90 I committed it out in CONFIG DATADVH did a DIRM RLDD & DIRM RLDC. It failed again with the following DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted. DVHPWU3376E Days can not exceed the current password expire value of 0 DVHPWU3376E for user LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC = DVHREQ2289E 3212. I restarted DIRMAINT and got the same results. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, October 06, 2015 2:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem On Monday, 10/05/2015 at 01:42 EDT, Bruce Hayden wrote: > What do you have for all the configuration variables that start with > PW_ in > your CONFIG99 DATADVH file? The expire days should be set by > PW_INTERVAL_FOR_SET= according to the documentation. I'm guessing it > is not the default value or at least greater than zero. > > But - you say you also have RACF. In that case, forget all of the PW_ > settings because RACF is the one that will be managing the passwords. You > set the password change interval, etc. using the RAC SETROPTS (set > RACF > options) command. Nah. DIRMAINT still keeps track of when passwords were changed via DIRMAINT. Tearing the problem apart... DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG This error is because there is a problem with the PW_INTERVAL_FOR_SET statement. A DIRM ADD, CHNGID, or SETPW command (ADD, in this case) attempted to set the password validity interval to a value that is higher than the interval from the PW_INTERVAL_FOR_GEN statement (2nd value). The default is 97 days. There is either a bug in the doc or a bug in the code. PW_INTERVAL_FOR_GEN is documented to have to values on it: The first value specifies the number of days a password is valid following one of the commands that set the password for a general user, the second value specifies the number of days a password is valid for a privileged user. The code doesn't do that. It assumes all users are general users as far as PW_INTERVAL_FOR_SET is concerned. I would do a DIRM CMS LISTFILE CONFIG* DATADVH * to see what configuration files are available. Then I would look in all of them for a PW_INTERVAL_FOR_SET statement. Not finding any, I would simply restart DIRMAINT. If you comment out a statement, RLDDATA won't always work since as far as it's concerned, nothing is overriding the existing value. You can just put a null value on it. PW_INTERVAL_FOR_SET= 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/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: DIRM problem
Yes. I reloaded code and data. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Monday, October 05, 2015 1:42 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: DIRM problem >>> On 10/5/2015 at 11:00 AM, "Shumate, Scott" wrote: > What am I missing? I did comment out PW_INTERVAL_FOR_GEN= 0 0 in my > config99 datadvh file but still get this error. Did you recycle Dirmaint after making that change? It may be something that gets evaluated at startup time only. 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/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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/
DIRM problem
I'm in the process of setting up DIRMAINT AND RACF to work together so we can exploit SMAPI. I'm using redbook The Virtualization Cookbook for IBM z Systems Volume 1: IBM z/VM 6.3 to configure it. I'm on section 8.3. When I run the command to add the server, I get the following error. DVHREQ2288I Your ADD request for LXTEST2 at * has been accepted. DVHPWU3376E Days can not exceed the current password expire value of 0 DVHPWU3376E for user LXTEST2. DVHADD3212E Unexpected RC= 3376, from: EXEC DVHSTPWC ADD LXTEST2 CONFIG DVHREQ2289E Your ADD request for LXTEST2 at * has failed; with RC = DVHREQ2289E 3212. What am I missing? I did comment out PW_INTERVAL_FOR_GEN= 0 0 in my config99 datadvh file but still get this error. Thanks Scott The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: Losing SAN Adapters with RHEL5 servers after patching
This is how we do the patching: Yes, we do patch using YUM. The custom script that we use for RHEL patch has already mkinitrd with ‘zfcp’ module loaded along with scsi_mod & sd_mod modules for SAN attached servers. 1. YUM upgrade 2. mkinitrd -v --with=scsi_mod --with=zfcp --with=sd_mod initrd-$NEWKERN.img $NEWKERN 3. zipl 4. Server reboot Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Offer Baruch Sent: Monday, June 22, 2015 12:12 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Losing SAN Adapters with RHEL5 servers after patching It sounds like that the initrd being build by the patch is missing the zfcp module... How are you patching? Yum? I think that it might help to add the zfcp module to the /etc/sysconfig/kernel file. There should be a parameter to state which modules should be added to the initrd file automatically. Something like INITRD_MODULES=... Just add the zfcp module. I would also verify you have it in /etc/modprobe.conf Hope this helps... Offer Baruch -- 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 in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission.
Re: Losing SAN Adapters with RHEL5 servers after patching
Here is the output. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Offer Baruch Sent: Sunday, June 21, 2015 11:42 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Losing SAN Adapters with RHEL5 servers after patching Hi Is it possible that the zfcp module is not being loaded after the reboot? Can you issue this command after the reboot: lsmod | grep fcp Can you also make sure this udev rule is in place and send it content: /etc/udev/rules.d/56-zfcp.rules Good luck Offer Baruch On Jun 22, 2015 12:38 AM, "Shumate, Scott" wrote: > I was wondering if anyone out there is experiencing the same problem > we are facing. Our linux team is constantly losing SAN adapters after > they patch and reboot a RHEL5 server. The FCP adapters are still > attached to the guest but do not exist on the server side. If they > issue command lscss -t 1732/03,1732/04, nothing displays. I had our > linux team use the following commands to get the adapters back. Any > ideas to prevent this from happening? Any help would be greatly appreciated. > > 1) verify new adapters with command lscss -t 1732/03,1732/04 > 2) bring new adapters online with command chccwdev -e > 0.0.d500,0.0.d600,0.0.d700,0.0.f400 > 3) verify adapters with command lszfcp -D > 4) attach new luns with zfcpconf.sh script (script to attach wwpns to > the adpaters and add the luns to the adapters). > 5) run mkinitrd and zipl > > Here is the output for q fcp from the servers. > > for lxd10042 cmd q fcp > LXD10042 : FCP D500 ON FCP D50F CHPID 99 SUBCHANNEL = 0001 > LXD10042 : D500TOKEN = 003663C14A00 > LXD10042 : D500 DEVTYPE FCP VIRTUAL CHPID 99 FCP REAL CHPID 99 > LXD10042 : D500 QDIO ACTIVE QIOASSIST ACTIVEQEBSM > LXD10042 : D500 > LXD10042 : D500 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 > UNAVAIL = 000 > LXD10042 : D500 BYTES = > LXD10042 : D500 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 > UNAVAIL = 000 > LXD10042 : D500 BYTES = 0013D5E8 > LXD10042 : D500 DATA ROUTER ELIGIBLE > LXD10042 : FCP D600 ON FCP D60F CHPID 9A SUBCHANNEL = 0002 > LXD10042 : D600TOKEN = 003663C14080 > LXD10042 : D600 DEVTYPE FCP VIRTUAL CHPID 9A FCP REAL CHPID 9A > LXD10042 : D600 QDIO ACTIVE QIOASSIST ACTIVEQEBSM > LXD10042 : D600 > LXD10042 : D600 INP + 01 IOCNT = 0241 ADP = 128 PROG = 000 > UNAVAIL = 000 > LXD10042 : D600 BYTES = > LXD10042 : D600 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 > UNAVAIL = 000 > LXD10042 : D600 BYTES = 0013D5E8 > LXD10042 : D600 DATA ROUTER ELIGIBLE > LXD10042 : FCP D700 ON FCP D70F CHPID 9B SUBCHANNEL = 0003 > LXD10042 : D700TOKEN = 003663C14980 > LXD10042 : D700 DEVTYPE FCP VIRTUAL CHPID 9B FCP REAL CHPID 9B > LXD10042 : D700 QDIO ACTIVE QIOASSIST ACTIVEQEBSM > LXD10042 : D700 > LXD10042 : D700 INP + 01 IOCNT = 00048862 ADP = 128 PROG = 000 > UNAVAIL = 000 > LXD10042 : D700 BYTES = > LXD10042 : D700 OUT + 01 IOCNT = 00049718 ADP = 000 PROG = 128 > UNAVAIL = 000 > LXD10042 : D700 BYTES = 1E189688 > LXD10042 : D700 DATA ROUTER ELIGIBLE > LXD10042 : FCP F400 ON FCP F40F CHPID 98 SUBCHANNEL = > LXD10042 : F400TOKEN = 003663C14400 > LXD10042 : F400 DEVTYPE FCP VIRTUAL CHPID 98 FCP REAL CHPID 98 > LXD10042 : F400 QDIO ACTIVE QIOASSIST ACTIVEQEBSM > LXD10042 : F400 > LXD10042 : F400 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 > UNAVAIL = 000 > LXD10042 : F400 BYTES = > LXD10042 : F400 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 > UNAVAIL = 000 > LXD10042 : F400 BYTES = 0013D5E8 > LXD10042 : F400 DATA ROUTER ELIGIBLE > LXD10042 : HCPFOR069I Command Complete. CP return code = . > > Thanks > Scott > > > > The information in this transmission may contain proprietary and > non-public information of BB&T or its affiliates and may be subject to > protection under the law. The message is intended for the sole use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are notified that any use, distribution or > copying of the message is strictly prohibited. If you received this > message in error, please delete the material from your system without > reading the content
Re: Losing SAN Adapters with RHEL5 servers after patching
It fixes the issue permanently. But this has happened three times after OS patching. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Offer Baruch Sent: Monday, June 22, 2015 12:02 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Losing SAN Adapters with RHEL5 servers after patching Maybe i didn't understand you correctly... Did your procedure fix the problem permanently or just until the next reboot? Thanks Offer Baruch On Jun 22, 2015 6:42 AM, "Offer Baruch" wrote: > Hi > > Is it possible that the zfcp module is not being loaded after the reboot? > Can you issue this command after the reboot: > lsmod | grep fcp > Can you also make sure this udev rule is in place and send it content: > /etc/udev/rules.d/56-zfcp.rules > > Good luck > Offer Baruch > On Jun 22, 2015 12:38 AM, "Shumate, Scott" wrote: > >> I was wondering if anyone out there is experiencing the same problem >> we are facing. Our linux team is constantly losing SAN adapters >> after they patch and reboot a RHEL5 server. The FCP adapters are >> still attached to the guest but do not exist on the server side. If >> they issue command lscss -t 1732/03,1732/04, nothing displays. I had >> our linux team use the following commands to get the adapters back. >> Any ideas to prevent this from happening? Any help would be greatly >> appreciated. >> >> 1) verify new adapters with command lscss -t 1732/03,1732/04 >> 2) bring new adapters online with command chccwdev -e >> 0.0.d500,0.0.d600,0.0.d700,0.0.f400 >> 3) verify adapters with command lszfcp -D >> 4) attach new luns with zfcpconf.sh script (script to attach wwpns to >> the adpaters and add the luns to the adapters). >> 5) run mkinitrd and zipl >> >> Here is the output for q fcp from the servers. >> >> for lxd10042 cmd q fcp >> LXD10042 : FCP D500 ON FCP D50F CHPID 99 SUBCHANNEL = 0001 >> LXD10042 : D500TOKEN = 003663C14A00 >> LXD10042 : D500 DEVTYPE FCP VIRTUAL CHPID 99 FCP REAL CHPID >> 99 >> LXD10042 : D500 QDIO ACTIVE QIOASSIST ACTIVEQEBSM >> LXD10042 : D500 >> LXD10042 : D500 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 >> UNAVAIL = 000 >> LXD10042 : D500 BYTES = >> LXD10042 : D500 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 >> UNAVAIL = 000 >> LXD10042 : D500 BYTES = 0013D5E8 >> LXD10042 : D500 DATA ROUTER ELIGIBLE >> LXD10042 : FCP D600 ON FCP D60F CHPID 9A SUBCHANNEL = 0002 >> LXD10042 : D600TOKEN = 003663C14080 >> LXD10042 : D600 DEVTYPE FCP VIRTUAL CHPID 9A FCP REAL CHPID >> 9A >> LXD10042 : D600 QDIO ACTIVE QIOASSIST ACTIVEQEBSM >> LXD10042 : D600 >> LXD10042 : D600 INP + 01 IOCNT = 0241 ADP = 128 PROG = 000 >> UNAVAIL = 000 >> LXD10042 : D600 BYTES = >> LXD10042 : D600 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 >> UNAVAIL = 000 >> LXD10042 : D600 BYTES = 0013D5E8 >> LXD10042 : D600 DATA ROUTER ELIGIBLE >> LXD10042 : FCP D700 ON FCP D70F CHPID 9B SUBCHANNEL = 0003 >> LXD10042 : D700TOKEN = 003663C14980 >> LXD10042 : D700 DEVTYPE FCP VIRTUAL CHPID 9B FCP REAL CHPID >> 9B >> LXD10042 : D700 QDIO ACTIVE QIOASSIST ACTIVEQEBSM >> LXD10042 : D700 >> LXD10042 : D700 INP + 01 IOCNT = 00048862 ADP = 128 PROG = 000 >> UNAVAIL = 000 >> LXD10042 : D700 BYTES = >> LXD10042 : D700 OUT + 01 IOCNT = 00049718 ADP = 000 PROG = 128 >> UNAVAIL = 000 >> LXD10042 : D700 BYTES = 1E189688 >> LXD10042 : D700 DATA ROUTER ELIGIBLE >> LXD10042 : FCP F400 ON FCP F40F CHPID 98 SUBCHANNEL = >> LXD10042 : F400TOKEN = 003663C14400 >> LXD10042 : F400 DEVTYPE FCP VIRTUAL CHPID 98 FCP REAL CHPID >> 98 >> LXD10042 : F400 QDIO ACTIVE QIOASSIST ACTIVEQEBSM >> LXD10042 : F400 >> LXD10042 : F400 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 >> UNAVAIL = 000 >> LXD10042 : F400 BYTES = >> LXD10042 : F400 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 >> UNAVAIL = 000 >> LXD10042 : F400 BYTES = 0013D5E8 >> LXD10042 : F400 DATA ROUTER ELIGIBLE >> LXD100
Losing SAN Adapters with RHEL5 servers after patching
I was wondering if anyone out there is experiencing the same problem we are facing. Our linux team is constantly losing SAN adapters after they patch and reboot a RHEL5 server. The FCP adapters are still attached to the guest but do not exist on the server side. If they issue command lscss -t 1732/03,1732/04, nothing displays. I had our linux team use the following commands to get the adapters back. Any ideas to prevent this from happening? Any help would be greatly appreciated. 1) verify new adapters with command lscss -t 1732/03,1732/04 2) bring new adapters online with command chccwdev -e 0.0.d500,0.0.d600,0.0.d700,0.0.f400 3) verify adapters with command lszfcp -D 4) attach new luns with zfcpconf.sh script (script to attach wwpns to the adpaters and add the luns to the adapters). 5) run mkinitrd and zipl Here is the output for q fcp from the servers. for lxd10042 cmd q fcp LXD10042 : FCP D500 ON FCP D50F CHPID 99 SUBCHANNEL = 0001 LXD10042 : D500TOKEN = 003663C14A00 LXD10042 : D500 DEVTYPE FCP VIRTUAL CHPID 99 FCP REAL CHPID 99 LXD10042 : D500 QDIO ACTIVE QIOASSIST ACTIVEQEBSM LXD10042 : D500 LXD10042 : D500 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 UNAVAIL = 000 LXD10042 : D500 BYTES = LXD10042 : D500 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 UNAVAIL = 000 LXD10042 : D500 BYTES = 0013D5E8 LXD10042 : D500 DATA ROUTER ELIGIBLE LXD10042 : FCP D600 ON FCP D60F CHPID 9A SUBCHANNEL = 0002 LXD10042 : D600TOKEN = 003663C14080 LXD10042 : D600 DEVTYPE FCP VIRTUAL CHPID 9A FCP REAL CHPID 9A LXD10042 : D600 QDIO ACTIVE QIOASSIST ACTIVEQEBSM LXD10042 : D600 LXD10042 : D600 INP + 01 IOCNT = 0241 ADP = 128 PROG = 000 UNAVAIL = 000 LXD10042 : D600 BYTES = LXD10042 : D600 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 UNAVAIL = 000 LXD10042 : D600 BYTES = 0013D5E8 LXD10042 : D600 DATA ROUTER ELIGIBLE LXD10042 : FCP D700 ON FCP D70F CHPID 9B SUBCHANNEL = 0003 LXD10042 : D700TOKEN = 003663C14980 LXD10042 : D700 DEVTYPE FCP VIRTUAL CHPID 9B FCP REAL CHPID 9B LXD10042 : D700 QDIO ACTIVE QIOASSIST ACTIVEQEBSM LXD10042 : D700 LXD10042 : D700 INP + 01 IOCNT = 00048862 ADP = 128 PROG = 000 UNAVAIL = 000 LXD10042 : D700 BYTES = LXD10042 : D700 OUT + 01 IOCNT = 00049718 ADP = 000 PROG = 128 UNAVAIL = 000 LXD10042 : D700 BYTES = 1E189688 LXD10042 : D700 DATA ROUTER ELIGIBLE LXD10042 : FCP F400 ON FCP F40F CHPID 98 SUBCHANNEL = LXD10042 : F400TOKEN = 003663C14400 LXD10042 : F400 DEVTYPE FCP VIRTUAL CHPID 98 FCP REAL CHPID 98 LXD10042 : F400 QDIO ACTIVE QIOASSIST ACTIVEQEBSM LXD10042 : F400 LXD10042 : F400 INP + 01 IOCNT = 0239 ADP = 128 PROG = 000 UNAVAIL = 000 LXD10042 : F400 BYTES = LXD10042 : F400 OUT + 01 IOCNT = 0255 ADP = 000 PROG = 128 UNAVAIL = 000 LXD10042 : F400 BYTES = 0013D5E8 LXD10042 : F400 DATA ROUTER ELIGIBLE LXD10042 : HCPFOR069I Command Complete. CP return code = . Thanks Scott The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: device-mapper: reload ioctl on failed
We found the problem. After working with RedHat, it appears that the lvm system was not using the read_only mounts options properly so adding the proper flag fixed it. I've asked the same question about NFS but that was the way our linux team set it up years ago. Our middleware guys wanted to share the binaries for applying maintenance to their WAS servers. It has worked great for them in the past, and this is how they wanted it going forward. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, November 18, 2014 10:50 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed I just realized that I was in a different situation that you are in. We had multiple Linux users sharing a disk on an LVM R/O, but what you have is one R/W and multiple R/O. If the system with R/W makes change, the R/O system's file system will not have means to sync up. So even if you manage to solve your current problems, you could still end up with IO errors on the Linux that's linking R/O. Is there a particular reason why you need to share Linux data via minidisk links? Could a NFS share do the same job? Tomas -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Shumate, Scott Sent: Tuesday, November 18, 2014 3:56 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed Thanks for the reply Thomas. I'm going to pass this on to our Linux guys, this is their arena. I'm trying to help them trouble shoot. I'm not keen on making the disk mw. I'm with you on that one. It should work by linking it r/o and mount the volume group r/o on the linux side. Works fine in our QA environment. Just fails on our test environment. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, November 18, 2014 2:27 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed > It works if I attach the mini-disk was multi-write. This is not what we want > but it works. Any ideas? A lot of speculation on my part follows. Again I will point to Red Hat as the more informed party. The bug I dealt with before seems very similar to what you are experiencing. There were functions in the LVM code used for volume initialization that came in two variants: the read write variant would write metadata to the volume during initialization while the read only variant would not try to write anything. The cause of the bug was that someone forgot to call the RO variant when the disk was linked RO and the RW variant tried to write to the disk and failed which in turn caused the whole initialization to fail and the volume was not brought online. If your case is similar, then linking the minidisk MW would allow the initialization logic on the disk that is supposed to read to write to the disk. I assume that you are using an ext type file system and I am also assuming that Linux does not support the RESERVE/RELEASE function there (if there is someone who knows better please correct me). This means that the two Linuxes sharing the disk can write to the disk at the same time. You may get lucky and this will work or you may end up with corrupted LVM metadata or worse. Before you proceed with this check how important the data on those disks are, what are your skills regarding recovery of LVM disks with corrupted metadata and whether you have usable backups. Even if the data on those disks are not valuable, corrupted LVM metadata could make debugging your original problem more complicated. The safe rule of MW is to never use it unless you have a very good idea about what you are doing. HTH, Tomas -- 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 in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- For LINUX-390 subscribe / signoff / arch
Re: device-mapper: reload ioctl on failed
Thanks for the reply Thomas. I'm going to pass this on to our Linux guys, this is their arena. I'm trying to help them trouble shoot. I'm not keen on making the disk mw. I'm with you on that one. It should work by linking it r/o and mount the volume group r/o on the linux side. Works fine in our QA environment. Just fails on our test environment. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Tuesday, November 18, 2014 2:27 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed > It works if I attach the mini-disk was multi-write. This is not what we want > but it works. Any ideas? A lot of speculation on my part follows. Again I will point to Red Hat as the more informed party. The bug I dealt with before seems very similar to what you are experiencing. There were functions in the LVM code used for volume initialization that came in two variants: the read write variant would write metadata to the volume during initialization while the read only variant would not try to write anything. The cause of the bug was that someone forgot to call the RO variant when the disk was linked RO and the RW variant tried to write to the disk and failed which in turn caused the whole initialization to fail and the volume was not brought online. If your case is similar, then linking the minidisk MW would allow the initialization logic on the disk that is supposed to read to write to the disk. I assume that you are using an ext type file system and I am also assuming that Linux does not support the RESERVE/RELEASE function there (if there is someone who knows better please correct me). This means that the two Linuxes sharing the disk can write to the disk at the same time. You may get lucky and this will work or you may end up with corrupted LVM metadata or worse. Before you proceed with this check how important the data on those disks are, what are your skills regarding recovery of LVM disks with corrupted metadata and whether you have usable backups. Even if the data on those disks are not valuable, corrupted LVM metadata could make debugging your original problem more complicated. The safe rule of MW is to never use it unless you have a very good idea about what you are doing. HTH, Tomas -- 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 in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: device-mapper: reload ioctl on failed
Yes I agree. Its shared binaries used to apply maintenance. We don't want it this way that is why we are trying to figure out why the linux os can't mount them r/o. The only way we can get it to work is link the disk mw then turn around and mount them r/o on the linux os. That is the only way the linux OS can mount them r/o. To make things even weirder, I can use another RHEL5 server and link it r/o and mount the file system r/o on the same RHEL6 server. Make me think there is something different in the RHEL5 server and not the RHEL6 server, but I can't see it. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Sunday, November 16, 2014 10:56 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed Hmm.. what's providing the sharing of the underlying filesystem?LINK MW allows more then one guest to link read/write... when you attach, then it's not a minidisk any more, and only the guest that attached it can use it. MW usually isn't recommended unless there is some kind of reserve/release to ensure only one guest writes at a time.. (MWV provides virtual reserve/release for fullpack minidisks). What's running on these guests (middleware/application) and using these disks? What you're showing looks dangerous.. Scott Rohling On Sun, Nov 16, 2014 at 3:50 PM, Shumate, Scott wrote: > It's a shared mini-disk. > > LINK LXD20069 0707 0707 MW > LINK LXD20069 0708 0708 MW > LINK LXD20069 0709 0709 MW > LINK LXD20069 070A 070A MW > > Sorry for the confusion. > > Thanks > Scott > > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Scott Rohling > Sent: Friday, November 14, 2014 10:55 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: device-mapper: reload ioctl on failed > > Need to reword after 'It works if...' not sure what you are saying.. > are these fullpack minidisks? Did you have them linked as MW or MWV > before? ATTACH doesn't allow multiwrite... It is no longer a minidisk > available to the system because the volume is attached to your guest. > > But please re - explain -- :-)A directory entry showing the MDISKs > might help too.. i'm not clear on your disk setup.. > > Scott Rohling > > On Fri, Nov 14, 2014 at 7:46 AM, Shumate, Scott > wrote: > > > We have it in the new servers. I have another interesting fact. It > > works if I attach the mini-disk was multi-write. This is not what > > we want but it works. Any ideas? > > > > Thanks > > Scott > > > > > > -Original Message- > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf > > Of Agblad Tore > > Sent: Friday, November 14, 2014 3:48 AM > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: device-mapper: reload ioctl on failed > > > > You might have mismatch in zipl.conf, missing some disks that is > > used by root lvm. > > All disks used in a lvm for / must be specified in zipl.conf. > > I spent some hours finding that error. > > > > BR /Tore Agblad Volvo IT > > > > -Original Message- > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf > > Of Shumate, Scott > > Sent: den 14 november 2014 3:53 > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: device-mapper: reload ioctl on failed > > > > More errors: > > > > device-mapper: table: 253:18: linear: dm-linear: Device lookup > > failed > > device-mapper: ioctl: error adding target to table > > device-mapper: table: 253:19: linear: dm-linear: Device lookup > > failed > > device-mapper: ioctl: error adding target to table > > device-mapper: table: 253:1: linear: dm-linear: Device lookup failed > > device-mapper: ioctl: error adding target to table > > device-mapper: table: 253:2: linear: dm-linear: Device lookup failed > > device-mapper: ioctl: error adding target to table > > > > Thanks > > Scott > > > > -Original Message- > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf > > Of Dan Horák > > Sent: Thursday, November 13, 2014 11:43 AM > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: device-mapper: reload ioctl on failed > > > > On Thu, 13 Nov 2014 15:58:42 + > > "Pavelka, Tomas" wrote: > > > > > > lvm2-2.02.100-8.el6.s390x > > > > > > When I was dealing with this I had a version that had the bug > > > fixed and I think it was older than 2.02.100. It was 2.02.9x > > > somethin
Re: device-mapper: reload ioctl on failed
It's a shared mini-disk. LINK LXD20069 0707 0707 MW LINK LXD20069 0708 0708 MW LINK LXD20069 0709 0709 MW LINK LXD20069 070A 070A MW Sorry for the confusion. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Friday, November 14, 2014 10:55 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed Need to reword after 'It works if...' not sure what you are saying.. are these fullpack minidisks? Did you have them linked as MW or MWV before? ATTACH doesn't allow multiwrite... It is no longer a minidisk available to the system because the volume is attached to your guest. But please re - explain -- :-)A directory entry showing the MDISKs might help too.. i'm not clear on your disk setup.. Scott Rohling On Fri, Nov 14, 2014 at 7:46 AM, Shumate, Scott wrote: > We have it in the new servers. I have another interesting fact. It > works if I attach the mini-disk was multi-write. This is not what we > want but it works. Any ideas? > > Thanks > Scott > > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Agblad Tore > Sent: Friday, November 14, 2014 3:48 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: device-mapper: reload ioctl on failed > > You might have mismatch in zipl.conf, missing some disks that is used > by root lvm. > All disks used in a lvm for / must be specified in zipl.conf. > I spent some hours finding that error. > > BR /Tore Agblad Volvo IT > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Shumate, Scott > Sent: den 14 november 2014 3:53 > To: LINUX-390@VM.MARIST.EDU > Subject: Re: device-mapper: reload ioctl on failed > > More errors: > > device-mapper: table: 253:18: linear: dm-linear: Device lookup failed > device-mapper: ioctl: error adding target to table > device-mapper: table: 253:19: linear: dm-linear: Device lookup failed > device-mapper: ioctl: error adding target to table > device-mapper: table: 253:1: linear: dm-linear: Device lookup failed > device-mapper: ioctl: error adding target to table > device-mapper: table: 253:2: linear: dm-linear: Device lookup failed > device-mapper: ioctl: error adding target to table > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Dan Horák > Sent: Thursday, November 13, 2014 11:43 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: device-mapper: reload ioctl on failed > > On Thu, 13 Nov 2014 15:58:42 + > "Pavelka, Tomas" wrote: > > > > lvm2-2.02.100-8.el6.s390x > > > > When I was dealing with this I had a version that had the bug fixed > > and I think it was older than 2.02.100. It was 2.02.9x something. I > > would guess that your problem is LVM related but not the same that I > > had. Red Hat would give you better advice than I do. > > yes, Scott, please open a support request, the support guys will ask > for sosreport and I think appending a strace output for the lvchange > call would be also helpful > > > 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://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > > > The information in this transmission may contain proprietary and > non-public information of BB&T or its affiliates and may be subject to > protection under the law. The message is intended for the sole use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are notified that any use, distribution or > copying of the message is strictly prohibited. If you received this > message in error, please delete the material from your system without > reading the content and notify the sender immediately of the inadvertent > transmission. > > -- > 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: device-mapper: reload ioctl on failed
We have it in the new servers. I have another interesting fact. It works if I attach the mini-disk was multi-write. This is not what we want but it works. Any ideas? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Agblad Tore Sent: Friday, November 14, 2014 3:48 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed You might have mismatch in zipl.conf, missing some disks that is used by root lvm. All disks used in a lvm for / must be specified in zipl.conf. I spent some hours finding that error. BR /Tore Agblad Volvo IT -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Shumate, Scott Sent: den 14 november 2014 3:53 To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed More errors: device-mapper: table: 253:18: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:19: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:1: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:2: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dan Horák Sent: Thursday, November 13, 2014 11:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed On Thu, 13 Nov 2014 15:58:42 + "Pavelka, Tomas" wrote: > > lvm2-2.02.100-8.el6.s390x > > When I was dealing with this I had a version that had the bug fixed > and I think it was older than 2.02.100. It was 2.02.9x something. I > would guess that your problem is LVM related but not the same that I > had. Red Hat would give you better advice than I do. yes, Scott, please open a support request, the support guys will ask for sosreport and I think appending a strace output for the lvchange call would be also helpful 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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/ -- 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: device-mapper: reload ioctl on failed
More errors: device-mapper: table: 253:18: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:19: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:1: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table device-mapper: table: 253:2: linear: dm-linear: Device lookup failed device-mapper: ioctl: error adding target to table Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Dan Horák Sent: Thursday, November 13, 2014 11:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed On Thu, 13 Nov 2014 15:58:42 + "Pavelka, Tomas" wrote: > > lvm2-2.02.100-8.el6.s390x > > When I was dealing with this I had a version that had the bug fixed > and I think it was older than 2.02.100. It was 2.02.9x something. I > would guess that your problem is LVM related but not the same that I > had. Red Hat would give you better advice than I do. yes, Scott, please open a support request, the support guys will ask for sosreport and I think appending a strace output for the lvchange call would be also helpful 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://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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: device-mapper: reload ioctl on failed
Yes we have a case opened with redhat. I'll double check with our linux admins to see if they supplied that information to the vendor. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka, Tomas Sent: Thursday, November 13, 2014 10:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed > lvm2-2.02.100-8.el6.s390x When I was dealing with this I had a version that had the bug fixed and I think it was older than 2.02.100. It was 2.02.9x something. I would guess that your problem is LVM related but not the same that I had. Red Hat would give you better advice than I do. Tomas The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission.
Re: device-mapper: reload ioctl on failed
Server trying to share and receiving errors:
rpm -qa |grep lvm lvm2-libs-2.02.100-8.el6.s390x lvm2-2.02.100-8.el6.s390x
Owning server:
-bash-3.2$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.10 (Tikanga)
-bash-3.2$ hostname
wil-zwasmstrtst01.bbtnet.com
-bash-3.2$ rpm -qa |grep lvm
lvm2-2.02.88-12.el5
system-config-lvm-1.1.5-14.el5
Thanks
Scott
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Pavelka,
Tomas
Sent: Thursday, November 13, 2014 3:45 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: device-mapper: reload ioctl on failed
What version of the lvm RPM are you running? We have run into a problem on a
CentOS 6 installation where LVM would not put online disks that were read only.
The bug started at a version that I unfortunately forgot and was fixed in a
newer version that I forgot as well. But I managed to find one of the versions
that was wrong, which was lvm2-2.02.87-6. At that time we were on CentOS and
did not have support contract with Red Hat so we just rolled a custom RPM with
a patch which I was able to find:
--- ./lib/device/dev-io.c.orig 2012-08-31 03:45:14.0 -0400
+++ ./lib/device/dev-io.c 2012-08-31 03:46:22.0 -0400
@@ -282,7 +282,7 @@ static int _dev_read_ahead_dev(struct de
return 1;
}
- if (!dev_open(dev))
+ if (!dev_open_readonly(dev))
return_0;
if (ioctl(dev->fd, BLKRAGET, &read_ahead_long) < 0) {
The project where we needed this got cancelled so I have not followed up
whether Red Hat fixed it or not, but this should give you some leads.
HTH,
Tomas
The information in this transmission may contain proprietary and non-public
information of BB&T or its affiliates and may be subject to protection under
the law. The message is intended for the sole use of the individual or entity
to which it is addressed. If you are not the intended recipient, you are
notified that any use, distribution or copying of the message is strictly
prohibited. If you received this message in error, please delete the material
from your system without reading the content and notify the sender immediately
of the inadvertent transmission.
Re: device-mapper: reload ioctl on failed
They are causing the volumes unusable on the server. To my point, the same disk can be mounted successfully s r/o and usable on the old RHEL5 servers. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Wednesday, November 12, 2014 3:27 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: device-mapper: reload ioctl on failed I'm not sure -- but am wondering if the errors prevent the volume group from being used? Are these just informational or are they causing the volumes to be unusable? Scott Rohling On Wed, Nov 12, 2014 at 12:09 PM, Shumate, Scott wrote: > Hi everyone, > > I'm running into an interesting situation that I have not seen before. > We currently have an environment running RHEL5 servers. One of the > servers have a set of mini-disk mounted r/w (703 thru 706) and other > RHEL5 servers mounted r/o (703 thru 706). It works great. > > The problem we are running into is we have created new RHEL6 servers. > We are trying to attach to the same mini-disk (703 thru 706) to these > servers as r/o. I can successfully attach the disk to the guest as > read-only and do chccwdev to get them online. > > We do a vgscan --ignorelockingfailure > Then we do a vgchange -a y --ignorelockingfailure VolGroup01 > > We get the following error: > > 2 logical volume(s) in volume group "VolGroup01" now active > device-mapper: reload ioctl on failed: Invalid argument > device-mapper: reload ioctl on failed: Invalid argument > > Any ideas why we are getting these errors? > > Thanks > Scott > > > > The information in this transmission may contain proprietary and > non-public information of BB&T or its affiliates and may be subject to > protection under the law. The message is intended for the sole use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are notified that any use, distribution or > copying of the message is strictly prohibited. If you received this > message in error, please delete the material from your system without > reading the content and notify the sender immediately of the inadvertent > transmission. > -- 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 in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- 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/
device-mapper: reload ioctl on failed
Hi everyone, I'm running into an interesting situation that I have not seen before. We currently have an environment running RHEL5 servers. One of the servers have a set of mini-disk mounted r/w (703 thru 706) and other RHEL5 servers mounted r/o (703 thru 706). It works great. The problem we are running into is we have created new RHEL6 servers. We are trying to attach to the same mini-disk (703 thru 706) to these servers as r/o. I can successfully attach the disk to the guest as read-only and do chccwdev to get them online. We do a vgscan --ignorelockingfailure Then we do a vgchange -a y --ignorelockingfailure VolGroup01 We get the following error: 2 logical volume(s) in volume group "VolGroup01" now active device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument Any ideas why we are getting these errors? Thanks Scott The information in this transmission may contain proprietary and non-public information of BB&T or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission.
ooREXX documentation
I've installed ooREXX on my zLinux RHEL6 server. Does anyone know where I can find some good documentation for ooREXX? Thanks Scott -- 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: Issues using VMUR
Sorry for the confusion. I got it installed and is working. Thanks for everyone's help. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:59 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Whatever the name of the file is you copied to your system. Your previous post showed you doing: gunzip netdatax.gz, so I assumed you still had access to that file. Alternatively, the result of the gunzip can be processed with the tar -xf command now. Just do a "tar -tf netdatax" to see what's in the tarball. On 3/5/13 3:53 PM, "Shumate, Scott" wrote: > [root@wil-zvmdb01 tmp]# tar -xzf netdata.gz tar (child): netdata.gz: > Cannot open: No such file or directory tar (child): Error is not > recoverable: exiting now > tar: Child returned status 2 > tar: Error is not recoverable: exiting now > [root@wil-zvmdb01 tmp]# -- 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: Issues using VMUR
[root@wil-zvmdb01 tmp]# tar -xzf netdata.gz tar (child): netdata.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now [root@wil-zvmdb01 tmp]# Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:46 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR tar -xzf netdata.gz On 3/5/13 3:41 PM, "Shumate, Scott" wrote: > When I use command, > > gunzip netdatax.gz > > It produces this file: > > -rw-r--r--. 1 root root 61440 Mar 5 15:40 netdatax > > No netdatax.tar file > > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > David Boyes > Sent: Tuesday, March 05, 2013 3:20 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: Issues using VMUR > > That's the front of a tarball archive header. Are you sure you unpacked it? > > Eg: > > gunzip netdatax.gt > tar xvf netdatax.tar . > >>> [root@wil-zvmdb01 bin]# head -1 `which netdatax` >>> netdatax-1.0/77576476400011671701005014220 >> 5ustar >>> dataformatdataformatnetdatax- >> 1.0/netdatax.help644764764000 >>> 7707 >>> 11671466421016725 0ustar dataformatdataformat netdatax syntax > > -- > 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/ -- 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: Issues using VMUR
When I use command, gunzip netdatax.gz It produces this file: -rw-r--r--. 1 root root 61440 Mar 5 15:40 netdatax No netdatax.tar file Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David Boyes Sent: Tuesday, March 05, 2013 3:20 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR That's the front of a tarball archive header. Are you sure you unpacked it? Eg: gunzip netdatax.gt tar xvf netdatax.tar . > > [root@wil-zvmdb01 bin]# head -1 `which netdatax` > > netdatax-1.0/77576476400011671701005014220 > 5ustar > > dataformatdataformatnetdatax- > 1.0/netdatax.help644764764000 > > 7707 > > 11671466421016725 0ustar dataformatdataformat netdatax syntax -- 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: Issues using VMUR
Yes I did. I'm going to resend it and try again. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Peter Webb, Toronto Transit Commission Sent: Tuesday, March 05, 2013 3:18 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Hi Scott, That doesn't look right at all. Did you unpack the .tgz file? Peter -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Shumate, Scott Sent: March 5, 2013 3:05 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR [root@wil-zvmdb01 bin]# head -1 `which netdatax` netdatax-1.0/77576476400011671701005014220 5ustar dataformatdataformatnetdatax-1.0/netdatax.help6447647640 00770711671466421016725 0ustar dataformatdataformat netdatax syntax [root@wil-zvmdb01 bin]# which netdatax /usr/bin/netdatax [root@wil-zvmdb01 bin]# Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:02 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR file /usr/bin/netdatax which netdatax head -1 `which netdatax` On 3/5/13 2:56 PM, "Shumate, Scott" wrote: > [root@wil-zvmdb01 bin]# ls -l netdatax -rwxr-xr-x. 1 root root 61440 > Mar 5 14:12 netdatax -- 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/ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner. -- 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: Issues using VMUR
[root@wil-zvmdb01 bin]# file /usr/bin/netdatax /usr/bin/netdatax: POSIX tar archive (GNU) [root@wil-zvmdb01 bin]# Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:15 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR No use the file command which will tell you what type of file Linux thinks it is: file /usr/bin/netdatax On 3/5/13 3:09 PM, "Shumate, Scott" wrote: > [root@wil-zvmdb01 bin]# which netdatax /usr/bin/netdatax -- 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: Issues using VMUR
[root@wil-zvmdb01 bin]# which netdatax /usr/bin/netdatax Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR What about file `which netdatax`? On 3/5/13 3:04 PM, "Shumate, Scott" wrote: > [root@wil-zvmdb01 bin]# head -1 `which netdatax` > netdatax-1.0/77576476400011671701005014220 5ustar > dataformatdataformatnetdatax-1.0/netdatax.help644764764000 > 7707 > 11671466421016725 0ustar dataformatdataformat netdatax syntax > [root@wil-zvmdb01 bin]# which netdatax /usr/bin/netdatax > [root@wil-zvmdb01 bin]# -- 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: Issues using VMUR
[root@wil-zvmdb01 bin]# head -1 `which netdatax` netdatax-1.0/77576476400011671701005014220 5ustar dataformatdataformatnetdatax-1.0/netdatax.help644764764000770711671466421016725 0ustar dataformatdataformat netdatax syntax [root@wil-zvmdb01 bin]# which netdatax /usr/bin/netdatax [root@wil-zvmdb01 bin]# Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 3:02 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR file /usr/bin/netdatax which netdatax head -1 `which netdatax` On 3/5/13 2:56 PM, "Shumate, Scott" wrote: > [root@wil-zvmdb01 bin]# ls -l netdatax -rwxr-xr-x. 1 root root 61440 > Mar 5 14:12 netdatax -- 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: Issues using VMUR
[root@wil-zvmdb01 bin]# ls -l netdatax -rwxr-xr-x. 1 root root 61440 Mar 5 14:12 netdatax Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 05, 2013 2:45 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR ls -l /usr/bin/netdatax Is the "x" permission set? On 3/5/13 2:40 PM, "Shumate, Scott" wrote: > This is what I get. > > [root@wil-zvmdb01 tmp]# netdatax -h > -bash: /usr/bin/netdatax: cannot execute binary file > [root@wil-zvmdb01 tmp]# -- 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: Issues using VMUR
This is what I get. [root@wil-zvmdb01 tmp]# netdatax -h -bash: /usr/bin/netdatax: cannot execute binary file [root@wil-zvmdb01 tmp]# Thanks Scott -Original Message- From: Shumate, Scott Sent: Tuesday, March 05, 2013 2:37 PM To: 'Linux on 390 Port' Subject: RE: Issues using VMUR Ok I've installed REXX and downloaded the netdatax.gz file. I unpacked it. Is there any examples on how to run it? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Tuesday, March 05, 2013 2:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR >>> On 3/5/2013 at 02:26 PM, "Shumate, Scott" wrote: > I'm doing this from Linux side. Can this be done from the linux side? Yes. That's where the REXX scripts Peter Webb pointed you to are running. 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/ -- 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: Issues using VMUR
Ok I've installed REXX and downloaded the netdatax.gz file. I unpacked it. Is there any examples on how to run it? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Tuesday, March 05, 2013 2:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR >>> On 3/5/2013 at 02:26 PM, "Shumate, Scott" wrote: > I'm doing this from Linux side. Can this be done from the linux side? Yes. That's where the REXX scripts Peter Webb pointed you to are running. 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/ -- 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: Issues using VMUR
I'm doing this from Linux side. Can this be done from the linux side? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David Boyes Sent: Tuesday, March 05, 2013 12:10 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR > When I read the file in, its in NETDATA format. > How do I convert it to ASCII? Look at the comments in DMSDDL ASSEMBLE on MAINT after doing a VMFSETUP CMS (replace with the name of the $PPF file for your release of VM). The netdata format is documented there (AFAIK, that's the only place it's ever been documented - I don't think it's in the NJE manuals, although it should be). You'll need to write a program to reassemble the records from the netdata format. It's not hard, but... -- 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: Issues using VMUR
Yes that was the issue, 0.0.0009 was there twice, (my fat finger). I fixed that. Have another question. When you receive the file with VMUR, to comes across with NETDATA format. How can I convert that to ASCII? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Malcolm Beattie Sent: Tuesday, March 05, 2013 11:01 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Shumate, Scott writes: > Contents of /etc/zipl.conf [...] > parameters="root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 > rd_DASD=0.0.0700 rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD > KEYTABLE=us cio_ignore=all,!0.0.0009,!0.0.000c rd_LVM_LV=VolGroup00/lv_root > SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup00/lv_swap > rd_NO_DM" That shows the !0.0.000c and looks fine so 00c should be available after the next reboot, provided zipl is run after the edit and before rebooting. > Output from cat/proc/cmdline (I don't see !0.0.000c) > > [root@wil-zvmdb01 ~]# cat /proc/cmdline > root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 rd_DASD=0.0.0700 > rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us > cio_ignore=all,!0.0.0009,!0.0.0009 rd_LVM_LV=VolGroup00/lv_root > SYSFONT=latarcyrheb-sun16 crashkernel=auto > rd_LVM_LV=VolGroup00/lv_swap rd_NO_DM BOOT_IMAGE=0 This shows two copies of !0.0.0009 in place for the current boot. Since the original was cio_ignore=all,!0.0.0009 it looks as though an additional 0.0.0009 had been added giving cio_ignore=all,!0.0.0009,!0.0.0009 instead of the second one being !0.0.000c. I've just tried on an RHEL62 system with the exact same kernel as yours and !0.0.000c works fine for me. Any chance the second !0.0.0009 was added, then zipl run (which writes the change to the boot block) and only then was it noticed and changed to !0.0.000c without then rerunning zipl and rebooting? > Ouput from cio_ignore -l > > Ignored devices: > = > 0.0.-0.0.0008 > 0.0.000a-0.0.000b > 0.0.000d-0.0.06ff This, though, shows that 00c is not being ignored and should be usable at the moment. Given that it isn't in the kernel cmdline shown above for the current boot, it must have dynamically set via a cio_ignore command done directly or indirectly. RedHat uses various scripts triggered from udev hot-plug rules to fiddle with cio_ignore for things like dasd but I hadn't thought they'd done anything as polished for vmur. > Output from zipl > > [root@wil-zvmdb01 ~]# zipl > Using config file '/etc/zipl.conf' > Run /lib/s390-tools/zipl_helper.device-mapper /boot/ Building bootmap > in '/boot/' > Building menu 'rh-automatic-menu' > Adding #1: IPL section 'linux-2.6.32-220.el6.s390x' (default) > Preparing boot device: dasdb. > Done. Running zipl doesn't just tell you the current configuration, it writes the current zipl.conf settings into the boot block to be used for the next reboot. It looks as though maybe some of the various steps and tests (dynamic cio_ignore, editing zipl.conf, running zipl, rebooting, seeing /proc/cmdline and the current cio_ignore table and accessing the device) weren't in the intended order. If (1) zipl.conf really does have the !0.0.000c in it as shows (2) and zipl has been run after that change was made then you should find that after the next reboot you see the newly stamped setting via /proc/cmdline and the corresponding omission of 0.0.000c in the output from cio_ignore -l. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- 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: Issues using VMUR
I reran the zipl and rebooted. It works now. Have another question regarding VMUR. When I read the file in, its in NETDATA format. How do I convert it to ASCII? Reader file 0014 has NETDATA format Thanks Scott -Original Message- From: Shumate, Scott Sent: Tuesday, March 05, 2013 10:26 AM To: 'Linux on 390 Port' Subject: RE: Issues using VMUR Contents of /etc/zipl.conf [root@wil-zvmdb01 ~]# cat /etc/zipl.conf [defaultboot] timeout=5 default=linux-2.6.32-220.el6.s390x target=/boot/ [linux-2.6.32-220.el6.s390x] image=/boot/vmlinuz-2.6.32-220.el6.s390x ramdisk=/boot/initramfs-2.6.32-220.el6.s390x.img parameters="root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 rd_DASD=0.0.0700 rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us cio_ignore=all,!0.0.0009,!0.0.000c rd_LVM_LV=VolGroup00/lv_root SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup00/lv_swap rd_NO_DM" Output from cat/proc/cmdline (I don't see !0.0.000c) [root@wil-zvmdb01 ~]# cat /proc/cmdline root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 rd_DASD=0.0.0700 rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us cio_ignore=all,!0.0.0009,!0.0.0009 rd_LVM_LV=VolGroup00/lv_root SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup00/lv_swap rd_NO_DM BOOT_IMAGE=0 [root@wil-zvmdb01 ~]# Ouput from cio_ignore -l Ignored devices: = 0.0.-0.0.0008 0.0.000a-0.0.000b 0.0.000d-0.0.06ff 0.0.0704-0.0.08ff 0.0.0902-0.0.094f 0.0.0951-0.0.fb03 0.0.fb07-0.0. 0.1.-0.1. 0.2.-0.2. 0.3.-0.3. [root@wil-zvmdb01 ~]# Output from zipl [root@wil-zvmdb01 ~]# zipl Using config file '/etc/zipl.conf' Run /lib/s390-tools/zipl_helper.device-mapper /boot/ Building bootmap in '/boot/' Building menu 'rh-automatic-menu' Adding #1: IPL section 'linux-2.6.32-220.el6.s390x' (default) Preparing boot device: dasdb. Done. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Malcolm Beattie Sent: Tuesday, March 05, 2013 6:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Shumate, Scott writes: > That worked, but I'm having issues with making it perm. I added it to > /etc/zipl.conf and reran zipl. I rebooted but it was still on the black > list. Have a look at the output of # cat /proc/cmdline and check the syntax closely. For example, there must be no spaces within the cio_ignore= value, there must be an exclamation mark to remove the device number rather than add it, the !0.0.000c has to appear after the all not before and I can imagine that the device number may have to be spelled out in the full canonical form of "zero dot zero dot four hex digits". Also check you edited the zipl.conf stanza for the kernel you then actually booted. Since the contents of /proc/cmdline show the information from the current boot, you'd be able to tell if it's the wrong stanza because it wouldn't have your edits in place. Send the output (along with the output of "cio_ignore -l" and "lscss" for good measure) if it's still not clear. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- 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: Issues using VMUR
Contents of /etc/zipl.conf [root@wil-zvmdb01 ~]# cat /etc/zipl.conf [defaultboot] timeout=5 default=linux-2.6.32-220.el6.s390x target=/boot/ [linux-2.6.32-220.el6.s390x] image=/boot/vmlinuz-2.6.32-220.el6.s390x ramdisk=/boot/initramfs-2.6.32-220.el6.s390x.img parameters="root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 rd_DASD=0.0.0700 rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us cio_ignore=all,!0.0.0009,!0.0.000c rd_LVM_LV=VolGroup00/lv_root SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup00/lv_swap rd_NO_DM" Output from cat/proc/cmdline (I don't see !0.0.000c) [root@wil-zvmdb01 ~]# cat /proc/cmdline root=/dev/mapper/VolGroup00-lv_root rd_DASD=0.0.0701 rd_DASD=0.0.0700 rd_NO_LUKS rd_DASD=0.0.0702 LANG=en_US.UTF-8 rd_NO_MD KEYTABLE=us cio_ignore=all,!0.0.0009,!0.0.0009 rd_LVM_LV=VolGroup00/lv_root SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup00/lv_swap rd_NO_DM BOOT_IMAGE=0 [root@wil-zvmdb01 ~]# Ouput from cio_ignore -l Ignored devices: = 0.0.-0.0.0008 0.0.000a-0.0.000b 0.0.000d-0.0.06ff 0.0.0704-0.0.08ff 0.0.0902-0.0.094f 0.0.0951-0.0.fb03 0.0.fb07-0.0. 0.1.-0.1. 0.2.-0.2. 0.3.-0.3. [root@wil-zvmdb01 ~]# Output from zipl [root@wil-zvmdb01 ~]# zipl Using config file '/etc/zipl.conf' Run /lib/s390-tools/zipl_helper.device-mapper /boot/ Building bootmap in '/boot/' Building menu 'rh-automatic-menu' Adding #1: IPL section 'linux-2.6.32-220.el6.s390x' (default) Preparing boot device: dasdb. Done. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Malcolm Beattie Sent: Tuesday, March 05, 2013 6:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Shumate, Scott writes: > That worked, but I'm having issues with making it perm. I added it to > /etc/zipl.conf and reran zipl. I rebooted but it was still on the black > list. Have a look at the output of # cat /proc/cmdline and check the syntax closely. For example, there must be no spaces within the cio_ignore= value, there must be an exclamation mark to remove the device number rather than add it, the !0.0.000c has to appear after the all not before and I can imagine that the device number may have to be spelled out in the full canonical form of "zero dot zero dot four hex digits". Also check you edited the zipl.conf stanza for the kernel you then actually booted. Since the contents of /proc/cmdline show the information from the current boot, you'd be able to tell if it's the wrong stanza because it wouldn't have your edits in place. Send the output (along with the output of "cio_ignore -l" and "lscss" for good measure) if it's still not clear. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- 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: Issues using VMUR
That worked, but I'm having issues with making it perm. I added it to /etc/zipl.conf and reran zipl. I rebooted but it was still on the black list. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Malcolm Beattie Sent: Monday, March 04, 2013 6:01 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Shumate, Scott writes: > I'm having issues wondering if someone could help me out. I'm trying to > receive files from my reader. I'm currently running RHEL6. [...] > I list the rdr with vmur > [root@wil-zvmdb01 dev]# vmur li > ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIST > RSCS 0007 B PUN 0006 001 NONE 03/04 16:11:39 SCOTT EXEC > SYSPROG > RSCS 0008 B PUN 0006 001 NONE 03/04 17:19:44 SCOTT EXEC > SYSPROG > LXP10001 0004 T CON 0744 001 NONE 02/26 17:04:46 > LXP10001 This works because listing the contents of the reader is done via a DIAG call rather than Linux prodding the device itself. > I try to bring rdr online > [root@wil-zvmdb01 dev]# chccwdev -e 000c Device 0.0.000c not found This is because RedHat defaults to ignoring all devices via the cio_ignore blacklist and only enabling those that are explicitly removed from the blacklist. To do this dynamically, do: # cio_ignore -r 00c You can then bring it online with chccwdev. You can ensure that the device is not ignored at the next boot by modifying the cio_ignore parameter in the kernel command line in /etc/zipl.conf and rerunning zipl. For example, you could change cio_ignore=all,!0.0.0009 to cio_ignore=all,!0.0.0009,!0.0.000c or getting rid of the cio_ignore blacklist and allowing all the virtual machine's devices to be seen. --Malcolm -- Malcolm Beattie Mainframe Systems and Software Business, Europe IBM UK -- 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: Issues using VMUR
This is what I get. [root@wil-zvmdb01 ~]# vmcp def rdr 00c HCPDFN092E Device 000C not defined; reader 000C already defined Error: non-zero CP response for command 'DEF RDR 00C': #92 [root@wil-zvmdb01 ~]# Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Richard Troth Sent: Monday, March 04, 2013 5:38 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Issues using VMUR Scott -- You probably just need to define the virtual card reader. It's not surprising that a Linux guest would be profiled without one. vmcp def rdr 00c Then retry the rest of your VMUR work. On Mon, Mar 4, 2013 at 5:29 PM, Shumate, Scott wrote: > > Hi everyone, > > I'm having issues wondering if someone could help me out. I'm trying to > receive files from my reader. I'm currently running RHEL6. > > > I begin console spooling: > [root@wil-zvmdb01 dev]# vmcp sp cons start > > I close the spool > [root@wil-zvmdb01 dev]# vmcp sp cons clo \* rdr > > I list the rdr with vmur > [root@wil-zvmdb01 dev]# vmur li > ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIST > RSCS 0007 B PUN 0006 001 NONE 03/04 16:11:39 SCOTT EXEC > SYSPROG > RSCS 0008 B PUN 0006 001 NONE 03/04 17:19:44 SCOTT EXEC > SYSPROG > LXP10001 0004 T CON 0744 001 NONE 02/26 17:04:46 > LXP10001 > > I try to bring rdr online > [root@wil-zvmdb01 dev]# chccwdev -e 000c Device 0.0.000c not found > > I try to receive a file > > [root@wil-zvmdb01 dev]# vmur re 7 > vmur: Unable to get status for '/dev/vmrdr-0.0.000c': No such file or > directory > vmur: Please check if device is online! > [root@wil-zvmdb01 dev]# > > > > Thanks Scott > -- > 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/ -- -- R; Rick Troth Velocity Software http://www.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/ -- 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/
Issues using VMUR
Hi everyone, I'm having issues wondering if someone could help me out. I'm trying to receive files from my reader. I'm currently running RHEL6. I begin console spooling: [root@wil-zvmdb01 dev]# vmcp sp cons start I close the spool [root@wil-zvmdb01 dev]# vmcp sp cons clo \* rdr I list the rdr with vmur [root@wil-zvmdb01 dev]# vmur li ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIST RSCS 0007 B PUN 0006 001 NONE 03/04 16:11:39 SCOTT EXEC SYSPROG RSCS 0008 B PUN 0006 001 NONE 03/04 17:19:44 SCOTT EXEC SYSPROG LXP10001 0004 T CON 0744 001 NONE 02/26 17:04:46LXP10001 I try to bring rdr online [root@wil-zvmdb01 dev]# chccwdev -e 000c Device 0.0.000c not found I try to receive a file [root@wil-zvmdb01 dev]# vmur re 7 vmur: Unable to get status for '/dev/vmrdr-0.0.000c': No such file or directory vmur: Please check if device is online! [root@wil-zvmdb01 dev]# Thanks Scott -- 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: RHEL54 zLinux running TSA
Yes that's what I was missing. Thanks for the update. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Friday, June 29, 2012 10:27 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: RHEL54 zLinux running TSA On Friday, 06/29/2012 at 09:19 EDT, "Shumate, Scott" wrote: > Has anyone implemented TSA (Tivioli System Automation) on RHEL54? We are > trying to use ECKD disk for our quorum disk. We are running into this error: > > Initializing ECKD tie-breaker (.v DEVICE=/dev/dasdd) Reserving > tie-breaker (.v DEVICE=/dev/dasdd) eckd_reserve is boxed, busy, or in > error tb_reserve status DENIED(1) (errno=2) > > The disk is setup per IBM's recommendations. It requirements are: 1) The disk must be a full-pack minidisk (0-END or DEVNO) 2) The minidisk must be defined with link mode MWV 3) The volume must be defined as SHARED It sounds like you are missing #2. 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/ -- 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: RHEL54 zLinux running TSA
Scott, That worked. I appreciate your help. This was driving me crrraazy. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Friday, June 29, 2012 9:38 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: RHEL54 zLinux running TSA Only thing I can think of -- are disks linked MWV on each side? I'm not sure what the recommendation is.. but I know that if you share a RACF DB disk you specify MWV so virtual reserve/release is respected.. would think this is similar to prevent disk clobbering? Scott Rohling On Fri, Jun 29, 2012 at 7:16 AM, Shumate, Scott wrote: > Has anyone implemented TSA (Tivioli System Automation) on RHEL54? We > are trying to use ECKD disk for our quorum disk. We are running into > this > error: > > Initializing ECKD tie-breaker (.v DEVICE=/dev/dasdd) Reserving > tie-breaker (.v DEVICE=/dev/dasdd) eckd_reserve is boxed, busy, or in > error tb_reserve status DENIED(1) (errno=2) > > The disk is setup per IBM's recommendations. > > Here is the display on VMD1. You can see the address B02F is defined > as DEVNO and SHARED. It is linked to LXD10111 as device number 703 > and it is in WRITE mode. > > q b02f > DASD B02F CP SYSTEM DEVNO1 SHARED > Ready; T=0.01/0.01 17:50:12 > q sys B02f > > DASD B02F ATTACHED SYSTEM 0001 LXDQ02 > LXD10111 0703 R/W > Ready; T=0.01/0.01 17:50:26 > > Here is the same definition on the other system - VMD2 > > q b02f > DASD B02F CP SYSTEM DEVNO1 SHARED > Ready; T=0.01/0.01 17:52:37 > q sys b02f > > DASD B02F ATTACHED SYSTEM 0001 LXDQ02 > LXD20112 0703 R/W > Ready; T=0.01/0.01 17:52:41 > > Anyone's help would be greatly appreciated. > > > Thanks > Scott > > -- > 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/ -- 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/
RHEL54 zLinux running TSA
Has anyone implemented TSA (Tivioli System Automation) on RHEL54? We are trying to use ECKD disk for our quorum disk. We are running into this error: Initializing ECKD tie-breaker (.v DEVICE=/dev/dasdd) Reserving tie-breaker (.v DEVICE=/dev/dasdd) eckd_reserve is boxed, busy, or in error tb_reserve status DENIED(1) (errno=2) The disk is setup per IBM's recommendations. Here is the display on VMD1. You can see the address B02F is defined as DEVNO and SHARED. It is linked to LXD10111 as device number 703 and it is in WRITE mode. q b02f DASD B02F CP SYSTEM DEVNO1 SHARED Ready; T=0.01/0.01 17:50:12 q sys B02f DASD B02F ATTACHED SYSTEM 0001 LXDQ02 LXD10111 0703 R/W Ready; T=0.01/0.01 17:50:26 Here is the same definition on the other system - VMD2 q b02f DASD B02F CP SYSTEM DEVNO1 SHARED Ready; T=0.01/0.01 17:52:37 q sys b02f DASD B02F ATTACHED SYSTEM 0001 LXDQ02 LXD20112 0703 R/W Ready; T=0.01/0.01 17:52:41 Anyone's help would be greatly appreciated. Thanks Scott -- 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: lsscsi issue with RHEL5
Yep, that was my issue. Thanks for your help. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond Higgs Sent: Friday, December 16, 2011 1:45 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: lsscsi issue with RHEL5 Scott, Did you run mkinitrd? That should include your changes in the initial ram disk that linux uses to boot. Regards, Ray Higgs System z FCP Firmware Development Bld. 706, B42 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 rayhi...@us.ibm.com Linux on 390 Port wrote on 12/15/2011 10:51:40 PM: > From: "Shumate, Scott" > To: LINUX-390@vm.marist.edu > Date: 12/15/2011 10:58 PM > Subject: Re: lsscsi issue with RHEL5 > Sent by: Linux on 390 Port > > Can you tell me why it loses the way I set it up manually? > > I did update /etc/zfcp.conf with the following: > > [root@wil-zstsintgdbprdbu01 by-path]# cat /etc/zfcp.conf > 0.0.dc00 0x50060e800571f006 0x0020 > 0.0.dd00 0x50060e800571f016 0x0020 > 0.0.de00 0x50060e800571f007 0x0020 > 0.0.df00 0x50060e800571f017 0x0020 > 0.0.dc000x50060e800571f006 0x0026 > > When I readded the scsi disk it looks like this > > [root@wil-zstsintgdbprdbu01 by-path]# lszfcp -D > 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 > 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 > 0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1 > 0.0.de00/0x50060e800571f007/0x0020 2:0:0:1 > 0.0.df00/0x50060e800571f017/0x0020 3:0:0:1 > > But when I reboot, it looks like this: > > [root@wil-zstsintgdbprdbu01 by-path]# lszfcp -D > 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 > 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 > 0.0.df00/0x50060e800571f017/0x0020 2:0:0:1 > > Does /etc/zfcp.conf control what it connects or is there another place > I need to look? > > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Steffen Maier > Sent: Thursday, December 15, 2011 8:03 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: lsscsi issue with RHEL5 > > On 12/15/2011 11:47 PM, Shumate, Scott wrote: > > I have an issue with zfcp luns. I 2 luns 1 100GB lun and 1 1GB lun. > > The 100GB lun has 4 paths /dev/sda, /dev/sdb, /dev/sdd, and /dev/sde. > > The 1GB lun has one path /dev/sdc. I want paths /dev/sda thru > > /dev/sdd for the 100GB lun and /dev/sde for the 1GB lun. Is there > > anything I can do to make this happen? I've manually removed the > > scsi > > disk and rebooted, but it still has the same issue. What am I doing wrong? > > No issue here. /dev/sdX are kernel device names allocated by no > particular rule a user can rely on. Therefore, udev provides > persistent device names implemented by means of symbolic links under > /dev. For storage, those can be found under /dev/disk/by-.../... > For those cases where I really need to refer to an individual path of > a zfcp attached SCSI disk, I usually rely on /dev/disk/by-path/ > ccw--zfcp-:. > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/ > Online_Storage_Reconfiguration_Guide/persistent_naming.html > and also the Section "SCSI device nodes" in the zfcp chapter in the > "Device Drivers, Features, and Commands" book on > http://www.ibm.com/developerworks/linux/linux390/ > documentation_red_hat.html#rhel5 > > Just curious: Having configured multiple paths I presume you use > device-mapper multipathing on top which doesn't care about the device > names of individual paths. > What do you need device names of underlying physical paths for? > > > [root@wil-zstsintgdbprdbu01 ~]# cat /etc/zfcp.conf > > 0.0.dc000x50060e800571f006 0x0020 > > 0.0.dd000x50060e800571f016 0x0020 > > 0.0.de000x50060e800571f007 0x0020 > > 0.0.df000x50060e800571f017 0x0020 > > This only contains persistent configuration for four paths to your > presumable 1GB LUN. However, where does the config for the one path to > the 100GB LUN come from? > > > [root@wil-zstsintgdbprdbu01 ~]# lszfcp -D > > 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 > > 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 > > 0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1 > > 0.0.de00/0x50060e800571f007/0x0020 2:0:0:1 > > 0.0.df00/0x50060e800571f017/0x0020 3:0:0:1 > > > &g
Re: lsscsi issue with RHEL5
Can you tell me why it loses the way I set it up manually? I did update /etc/zfcp.conf with the following: [root@wil-zstsintgdbprdbu01 by-path]# cat /etc/zfcp.conf 0.0.dc00 0x50060e800571f006 0x0020 0.0.dd00 0x50060e800571f016 0x0020 0.0.de00 0x50060e800571f007 0x0020 0.0.df00 0x50060e800571f017 0x0020 0.0.dc000x50060e800571f006 0x0026 When I readded the scsi disk it looks like this [root@wil-zstsintgdbprdbu01 by-path]# lszfcp -D 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1 0.0.de00/0x50060e800571f007/0x0020 2:0:0:1 0.0.df00/0x50060e800571f017/0x0020 3:0:0:1 But when I reboot, it looks like this: [root@wil-zstsintgdbprdbu01 by-path]# lszfcp -D 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 0.0.df00/0x50060e800571f017/0x0020 2:0:0:1 Does /etc/zfcp.conf control what it connects or is there another place I need to look? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Steffen Maier Sent: Thursday, December 15, 2011 8:03 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: lsscsi issue with RHEL5 On 12/15/2011 11:47 PM, Shumate, Scott wrote: > I have an issue with zfcp luns. I 2 luns 1 100GB lun and 1 1GB lun. > The 100GB lun has 4 paths /dev/sda, /dev/sdb, /dev/sdd, and /dev/sde. > The 1GB lun has one path /dev/sdc. I want paths /dev/sda thru > /dev/sdd for the 100GB lun and /dev/sde for the 1GB lun. Is there > anything I can do to make this happen? I've manually removed the scsi > disk and rebooted, but it still has the same issue. What am I doing wrong? No issue here. /dev/sdX are kernel device names allocated by no particular rule a user can rely on. Therefore, udev provides persistent device names implemented by means of symbolic links under /dev. For storage, those can be found under /dev/disk/by-.../... For those cases where I really need to refer to an individual path of a zfcp attached SCSI disk, I usually rely on /dev/disk/by-path/ccw--zfcp-:. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html and also the Section "SCSI device nodes" in the zfcp chapter in the "Device Drivers, Features, and Commands" book on http://www.ibm.com/developerworks/linux/linux390/documentation_red_hat.html#rhel5 Just curious: Having configured multiple paths I presume you use device-mapper multipathing on top which doesn't care about the device names of individual paths. What do you need device names of underlying physical paths for? > [root@wil-zstsintgdbprdbu01 ~]# cat /etc/zfcp.conf > 0.0.dc000x50060e800571f006 0x0020 > 0.0.dd000x50060e800571f016 0x0020 > 0.0.de000x50060e800571f007 0x0020 > 0.0.df000x50060e800571f017 0x0020 This only contains persistent configuration for four paths to your presumable 1GB LUN. However, where does the config for the one path to the 100GB LUN come from? > [root@wil-zstsintgdbprdbu01 ~]# lszfcp -D > 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 > 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 > 0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1 > 0.0.de00/0x50060e800571f007/0x0020 2:0:0:1 > 0.0.df00/0x50060e800571f017/0x0020 3:0:0:1 > > [root@wil-zstsintgdbprdbu01 ~]# lsscsi > [0:0:0:1]diskHITACHI OPEN-V 6008 /dev/sda > [0:0:0:2]diskHITACHI OPEN-V 6008 /dev/sdc > [1:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdd > [2:0:0:1]diskHITACHI OPEN-V 6008 /dev/sde > [3:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdb Looks perfectly good to me. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://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
lsscsi issue with RHEL5
I have an issue with zfcp luns. I 2 luns 1 100GB lun and 1 1GB lun. The 100GB lun has 4 paths /dev/sda, /dev/sdb, /dev/sdd, and /dev/sde. The 1GB lun has one path /dev/sdc. I want paths /dev/sda thru /dev/sdd for the 100GB lun and /dev/sde for the 1GB lun. Is there anything I can do to make this happen? I've manually removed the scsi disk and rebooted, but it still has the same issue. What am I doing wrong? [root@wil-zstsintgdbprdbu01 ~]# cat /etc/zfcp.conf 0.0.dc000x50060e800571f006 0x0020 0.0.dd000x50060e800571f016 0x0020 0.0.de000x50060e800571f007 0x0020 0.0.df000x50060e800571f017 0x0020 [root@wil-zstsintgdbprdbu01 ~]# lszfcp -D 0.0.dc00/0x50060e800571f006/0x0020 0:0:0:1 0.0.dc00/0x50060e800571f006/0x0026 0:0:0:2 0.0.dd00/0x50060e800571f016/0x0020 1:0:0:1 0.0.de00/0x50060e800571f007/0x0020 2:0:0:1 0.0.df00/0x50060e800571f017/0x0020 3:0:0:1 [root@wil-zstsintgdbprdbu01 ~]# lsscsi [0:0:0:1]diskHITACHI OPEN-V 6008 /dev/sda [0:0:0:2]diskHITACHI OPEN-V 6008 /dev/sdc [1:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdd [2:0:0:1]diskHITACHI OPEN-V 6008 /dev/sde [3:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdb Thanks Scott -- 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: zFCP issue with RHEL5
Thanks Rafael, I'll check it out. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Rafael Godinez Perez Sent: Wednesday, December 14, 2011 2:31 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP issue with RHEL5 El 13/12/11 20:43, Mark Post escribió: >>>> On 12/13/2011 at 02:22 PM, "Shumate, Scott" wrote: >> Im trying to remove a LUN from an adapter on my RHEL5 server. It >> fails with this error -bash: echo: write error: No such device or >> address >> >> >> Any ideas what I'm doing wrong? > You first have to tell the SCSI layer to delete the LUN from use. Underneath > the directory you were in, you'll see a subdirectory of "host?" where ? is > the host number of the HBA. Under that will be one or more rport* > directories. Under those will be one or more target* directories, and under > those will be one or more directories that look like the numbers at the end > of the lszfcp -D display: > 0:0:0:1 > 0:0:0:2 > 2:0:0:2 > etc. > > In those directories, you'll see a pseudo file named "delete". You have to > echo a 1 into that before trying to do the echo to unit_remove. SUSE has > zfcp_disk_configure, which we wrote for our customers. I don't know if Red > Hat has a tool to figure all that out for you or not. Check the contents of > the s390-tools RPM (I think Red Hat renames that though) and see if something > similar is there. > > > Mark Post > Hello Scott, Mark gave good advise here for manual actions required to remove a block device . For a complete description of SCSI block devices management in RHEL 5 you can find the "Online Storage Reconfiguration Guide" available online or for downloading at: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/pdf/Online_Storage_Reconfiguration_Guide/Red_Hat_Enterprise_Linux-5-Online_Storage_Reconfiguration_Guide-en-US.pdf The chapter that describes block devices removal is online at: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Online_Storage_Reconfiguration_Guide/index.html#removing_devices It's also handy for LUN automated detection/removal the utility rescan-scsi-bus.sh . Description is in the same manual, at: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Online_Storage_Reconfiguration_Guide/index.html#rescan-scsi-bus In case you use RHEL 6, the very same information is located at chapter 24 of the more comprehensive "Storage Administration Guide": http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/index.html BTW, s390-tools is called s390utils in RHEL. Hope this helps. -- Rafael Godínez Pérez Red Hat - Senior Solution Architect EMEA RHCE, RHCVA, RHCDS Tel: +34 91 414 8800 - Ext. 68815 Mo: +34 600 418 002 Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, Planta 3ºD, 28016 Madrid, Spain Dirección Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid - C.I.F. B82657941 -- 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/
Running top on second level RHEL5
Quick question. When you run top on RHEL5 linux on systemz, is it accurate or is it a best guess? Thanks Scott -- 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: zFCP issue with RHEL5
Thanks Mark for the help Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Tuesday, December 13, 2011 2:43 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP issue with RHEL5 >>> On 12/13/2011 at 02:22 PM, "Shumate, Scott" wrote: > Im trying to remove a LUN from an adapter on my RHEL5 server. It > fails with this error -bash: echo: write error: No such device or > address > > > Any ideas what I'm doing wrong? You first have to tell the SCSI layer to delete the LUN from use. Underneath the directory you were in, you'll see a subdirectory of "host?" where ? is the host number of the HBA. Under that will be one or more rport* directories. Under those will be one or more target* directories, and under those will be one or more directories that look like the numbers at the end of the lszfcp -D display: 0:0:0:1 0:0:0:2 2:0:0:2 etc. In those directories, you'll see a pseudo file named "delete". You have to echo a 1 into that before trying to do the echo to unit_remove. SUSE has zfcp_disk_configure, which we wrote for our customers. I don't know if Red Hat has a tool to figure all that out for you or not. Check the contents of the s390-tools RPM (I think Red Hat renames that though) and see if something similar is there. 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/ -- 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/
zFCP issue with RHEL5
Im trying to remove a LUN from an adapter on my RHEL5 server. It fails with this error -bash: echo: write error: No such device or address Any ideas what I'm doing wrong? [root@wil-zstscidbdev01 0x50060e800571f006]# pwd /sys/bus/ccw/drivers/zfcp/0.0.dc00/0x50060e800571f006 [root@wil-zstscidbdev01 0x50060e800571f006]# cat /etc/zfcp.conf 0.0.dc00 0x50060e800571f016 0x001e 0.0.dd00 0x50060e800571f017 0x001e 0.0.de00 0x50060e800571f006 0x001e 0.0.df00 0x50060e800571f007 0x001e 0.0.dc00 0x50060e800571f016 0x001f 0.0.dd00 0x50060e800571f017 0x001f 0.0.de00 0x50060e800571f006 0x001f 0.0.df00 0x50060e800571f007 0x001f [root@wil-zstscidbdev01 0x50060e800571f006]# lszfcp -D 0.0.dc00/0x50060e800571f006/0x001e 0:0:0:1 0.0.dc00/0x50060e800571f006/0x001f 0:0:0:2 0.0.dd00/0x50060e800571f007/0x001e 1:0:0:1 0.0.dd00/0x50060e800571f007/0x001f 1:0:0:2 0.0.de00/0x50060e800571f016/0x001e 2:0:0:1 0.0.de00/0x50060e800571f016/0x001f 2:0:0:2 0.0.df00/0x50060e800571f017/0x001e 3:0:0:1 0.0.df00/0x50060e800571f017/0x001f 3:0:0:2 [root@wil-zstscidbdev01 0x50060e800571f006]# echo 0x001e > unit_remove -bash: echo: write error: No such device or address -- 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: zFCP question for RHEL54
That makes sense. One more question. Is it possible to have your current non-NPIV configuration setup and enable NPIV, then migrate servers over to npiv zoning. Or do we turn it on and re-zone all our servers. I would like to enable it, test it. Once tested, start moving servers over to npiv. Does that make sense? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Wednesday, December 07, 2011 2:21 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 On Wednesday, 12/07/2011 at 02:07 EST, "Shumate, Scott" wrote: > I'm looking at Jon's link at the moment. I was asking from a non npiv setup. > How does most site's run NPIV or non-NPIV? Most sites I talk to are using NPIV. That's the only way to effectively manage SAN security where you have more virtual servers connecting to the SAN than you have zFCP ports. 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/ -- 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: zFCP question for RHEL54
I'm looking at Jon's link at the moment. I was asking from a non npiv setup. How does most site's run NPIV or non-NPIV? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond Higgs Sent: Wednesday, December 07, 2011 1:38 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 Scott, I'm not sure that I follow. Didn't you have to flip the HDS wwpns because those were really available through the other switch fabric? Are you asking what NPIV is? Jon sent some links to some redbooks about NPIV. I didn't look at them. Are you looking for more documentation? Regards, Ray Higgs System z FCP Firmware Development Bld. 706, B42 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 rayhi...@us.ibm.com Linux on 390 Port wrote on 12/07/2011 01:18:33 PM: > From: "Shumate, Scott" > To: LINUX-390@vm.marist.edu > Date: 12/07/2011 01:25 PM > Subject: Re: zFCP question for RHEL54 > Sent by: Linux on 390 Port > > Ray, > > Do you have any ideas? > > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Raymond Higgs > Sent: Wednesday, December 07, 2011 11:51 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: zFCP question for RHEL54 > > Scott, > > Turning on NPIV wouldn't have helped fix your problem. > > Regards, > > Ray Higgs > System z FCP Firmware Development > Bld. 706, B42 > 2455 South Road > Poughkeepsie, NY 12601 > (845) 435-8666, T/L 295-8666 > rayhi...@us.ibm.com > > Linux on 390 Port wrote on 12/07/2011 > 11:03:58 > AM: > > > From: "Shumate, Scott" > > To: LINUX-390@vm.marist.edu > > Date: 12/07/2011 11:17 AM > > Subject: Re: zFCP question for RHEL54 Sent by: Linux on 390 Port > > > > > > Yes we currently do not have NPIV enabled (in the switches or CECs). > > The way we have it setup for a cluster is to have the primary on one > > CEC and the backup on the other CEC. That’s not an issue (the > > displays below the servers on different CECs, sorry). I got the > > server mentioned to work by changing wwpn for the HDS USPv box on > > the adapters. I flipped the wwpns. No other servers are accessing > > these LUNs on this CEC. Would setting up NPIV fix this issue? If > > so, can you point me to a good resource on setting up NPIV on zLinux? > > > > Was > > --- > > 0.0.dc000x50060e800571f006 0x0017 > > 0.0.dc000x50060e800571f006 0x0019 > > 0.0.dd000x50060e800571f016 0x0017 > > 0.0.de000x50060e800571f017 0x0017 > > 0.0.df000x50060e800571f007 0x0017 > > > > Now > > -- > > > > 0.0.dc000x50060e800571f007 0x0017 > > 0.0.dc000x50060e800571f007 0x0019 > > 0.0.dd000x50060e800571f017 0x0017 > > 0.0.de000x50060e800571f016 0x0017 > > 0.0.df000x50060e800571f006 0x0017 > > > > > > > > > > Thanks > > Scott > > > > -Original Message- > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf > > Of òåôø áøåê > > Sent: Tuesday, December 06, 2011 9:38 PM > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: zFCP question for RHEL54 > > > > Hi, > > i think that is exactly your problem. > > If i got it right you are not using npiv. That means that all guests > > are using the same wwpn to the fabric on a spesific cec. 2 linux > > guests on the same cec cant access the same luns at the same time. > > The first guesr in the cec to access the luns wins. Either make sure > > you only share disks on different cecs and that no other guest is > > trying to access them, or enable npiv. > > We enabled npiv causing each linux guest to have its own virtual wwpn. > > This make life simpler from clustering point of view. > > > > Hope this helps... > > Offer Baruch > > > > Sent by emoze push mail > > > > > > - > > From: "Shumate, Scott" > > Subject: Re: zFCP question for RHEL54 > > Date: 07 דצמבר 2011 00:14 > > > > There are 2 CECs involved. Each CEC has 4 fibre connections, 2 in > > one switch and 2 in another. In our HDS box, we have 4 ports fibre > > cards > > (2 in one switch and 2 in the other). The way
Re: zFCP question for RHEL54
Ray, Do you have any ideas? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond Higgs Sent: Wednesday, December 07, 2011 11:51 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 Scott, Turning on NPIV wouldn't have helped fix your problem. Regards, Ray Higgs System z FCP Firmware Development Bld. 706, B42 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 rayhi...@us.ibm.com Linux on 390 Port wrote on 12/07/2011 11:03:58 AM: > From: "Shumate, Scott" > To: LINUX-390@vm.marist.edu > Date: 12/07/2011 11:17 AM > Subject: Re: zFCP question for RHEL54 > Sent by: Linux on 390 Port > > Yes we currently do not have NPIV enabled (in the switches or CECs). > The way we have it setup for a cluster is to have the primary on one > CEC and the backup on the other CEC. That’s not an issue (the > displays below the servers on different CECs, sorry). I got the > server mentioned to work by changing wwpn for the HDS USPv box on the > adapters. I flipped the wwpns. No other servers are accessing these > LUNs on this CEC. Would setting up NPIV fix this issue? If so, can > you point me to a good resource on setting up NPIV on zLinux? > > Was > --- > 0.0.dc000x50060e800571f006 0x0017 > 0.0.dc000x50060e800571f006 0x0019 > 0.0.dd000x50060e800571f016 0x0017 > 0.0.de000x50060e800571f017 0x0017 > 0.0.df000x50060e800571f007 0x0017 > > Now > -- > > 0.0.dc000x50060e800571f007 0x0017 > 0.0.dc000x50060e800571f007 0x0019 > 0.0.dd000x50060e800571f017 0x0017 > 0.0.de000x50060e800571f016 0x0017 > 0.0.df000x50060e800571f006 0x0017 > > > > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > òåôø áøåê > Sent: Tuesday, December 06, 2011 9:38 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: zFCP question for RHEL54 > > Hi, > i think that is exactly your problem. > If i got it right you are not using npiv. That means that all guests > are using the same wwpn to the fabric on a spesific cec. 2 linux > guests on the same cec cant access the same luns at the same time. > The first guesr in the cec to access the luns wins. Either make sure > you only share disks on different cecs and that no other guest is > trying to access them, or enable npiv. > We enabled npiv causing each linux guest to have its own virtual wwpn. > This make life simpler from clustering point of view. > > Hope this helps... > Offer Baruch > > Sent by emoze push mail > > > - > From: "Shumate, Scott" > Subject: Re: zFCP question for RHEL54 > Date: 07 דצמבר 2011 00:14 > > There are 2 CECs involved. Each CEC has 4 fibre connections, 2 in one > switch and 2 in another. In our HDS box, we have 4 ports fibre cards > (2 in one switch and 2 in the other). The way its zoned is 4 > connections from the CECs (2 from one CEC and 2 from the other) is > zoned to 2 port on the HDS box. > > So here is a break down > > ZONE IN SWITCH1 > CEC1 CHP 9C > CEC1 CHP 9D > CEC2 CHP 48 > CEC2 CHP 49 > HDS PORT CL1-G > HDS PORT CL2-G > > ZONE IN SWITCH2 > CEC1 CHP 9E > CEC1 CHP 9F > CEC2 CHP 44 > CEC2 CHP 47 > HDS PORT CL1-H > HDS PORT CL2-H > > To give you a break down, this server lives on CEC2 0.0.dc00 is > attached to CHP 44 0.0.dd00 is attached to CHP 47 0.0.de00 is attached > to CHP 48 0.0.df00 is attached to CHP 49 > > I have another server that runs with the same zfcp.conf file. It > attaches with no issues. That is what's confusing me. Is it a zoning issue? > > > Thanks > Scott > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Raymond Higgs > Sent: Tuesday, December 06, 2011 4:11 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: zFCP question for RHEL54 > > Scott, > > > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: warning: failed > > gid_pn nameserver request for wwpn 0x50060e800571f006 for adapter > 0.0.dc00 > > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: port erp failed > > (adapter 0.0.dc00, wwpn=0x50060e800571f006) > > The nameserver is a service that runs on your switches. GID_PN is a > request to the nameserver for Get Port Identifier by Port Name. The > error is that switch doesn't k
Re: zFCP question for RHEL54
Yes we currently do not have NPIV enabled (in the switches or CECs). The way we have it setup for a cluster is to have the primary on one CEC and the backup on the other CEC. That’s not an issue (the displays below the servers on different CECs, sorry). I got the server mentioned to work by changing wwpn for the HDS USPv box on the adapters. I flipped the wwpns. No other servers are accessing these LUNs on this CEC. Would setting up NPIV fix this issue? If so, can you point me to a good resource on setting up NPIV on zLinux? Was --- 0.0.dc000x50060e800571f006 0x0017 0.0.dc000x50060e800571f006 0x0019 0.0.dd000x50060e800571f016 0x0017 0.0.de000x50060e800571f017 0x0017 0.0.df000x50060e800571f007 0x0017 Now -- 0.0.dc000x50060e800571f007 0x0017 0.0.dc000x50060e800571f007 0x0019 0.0.dd000x50060e800571f017 0x0017 0.0.de000x50060e800571f016 0x0017 0.0.df000x50060e800571f006 0x0017 Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of òåôø áøåê Sent: Tuesday, December 06, 2011 9:38 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 Hi, i think that is exactly your problem. If i got it right you are not using npiv. That means that all guests are using the same wwpn to the fabric on a spesific cec. 2 linux guests on the same cec cant access the same luns at the same time. The first guesr in the cec to access the luns wins. Either make sure you only share disks on different cecs and that no other guest is trying to access them, or enable npiv. We enabled npiv causing each linux guest to have its own virtual wwpn. This make life simpler from clustering point of view. Hope this helps... Offer Baruch Sent by emoze push mail - From: "Shumate, Scott" Subject:Re: zFCP question for RHEL54 Date: 07 דצמבר 2011 00:14 There are 2 CECs involved. Each CEC has 4 fibre connections, 2 in one switch and 2 in another. In our HDS box, we have 4 ports fibre cards (2 in one switch and 2 in the other). The way its zoned is 4 connections from the CECs (2 from one CEC and 2 from the other) is zoned to 2 port on the HDS box. So here is a break down ZONE IN SWITCH1 CEC1 CHP 9C CEC1 CHP 9D CEC2 CHP 48 CEC2 CHP 49 HDS PORT CL1-G HDS PORT CL2-G ZONE IN SWITCH2 CEC1 CHP 9E CEC1 CHP 9F CEC2 CHP 44 CEC2 CHP 47 HDS PORT CL1-H HDS PORT CL2-H To give you a break down, this server lives on CEC2 0.0.dc00 is attached to CHP 44 0.0.dd00 is attached to CHP 47 0.0.de00 is attached to CHP 48 0.0.df00 is attached to CHP 49 I have another server that runs with the same zfcp.conf file. It attaches with no issues. That is what's confusing me. Is it a zoning issue? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond Higgs Sent: Tuesday, December 06, 2011 4:11 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 Scott, > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: warning: failed > gid_pn nameserver request for wwpn 0x50060e800571f006 for adapter 0.0.dc00 > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: port erp failed > (adapter 0.0.dc00, wwpn=0x50060e800571f006) The nameserver is a service that runs on your switches. GID_PN is a request to the nameserver for Get Port Identifier by Port Name. The error is that switch doesn't know about target port 0x50060e800571f006 so it can't return the n-port id that Linux needs. I'd investigate like this... 1. check zoning on your switch. Your channel may not have permission to talk to that target port. 2. check NPIV settings. If NPIV is on and you meant for it to be off, then that may change how you zone at the switch. 3. check cabling. If these linux systems are running on 2 different CECs, then maybe some channels on 1 CEC aren't cabled the way you expect. Regards, Ray Higgs System z FCP Firmware Development Bld. 706, B42 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 rayhi...@us.ibm.com Linux on 390 Port wrote on 12/06/2011 03:04:53 PM: > From: "Shumate, Scott" > To: LINUX-390@vm.marist.edu > Date: 12/06/2011 03:11 PM > Subject: zFCP question for RHEL54 > Sent by: Linux on 390 Port > > I'm running into issues adding zFCP LUNS to a clustered zLinux server. > The primary servers sees the disk with no issues and have > multipath'ing turned on. Both servers should be pointing to the same > scsi disk. What am I missing? Any ideas? I've tried rebooting with > no results. I do see the following error in /var/log/messages &g
Re: zFCP question for RHEL54
There are 2 CECs involved. Each CEC has 4 fibre connections, 2 in one switch and 2 in another. In our HDS box, we have 4 ports fibre cards (2 in one switch and 2 in the other). The way its zoned is 4 connections from the CECs (2 from one CEC and 2 from the other) is zoned to 2 port on the HDS box. So here is a break down ZONE IN SWITCH1 CEC1 CHP 9C CEC1 CHP 9D CEC2 CHP 48 CEC2 CHP 49 HDS PORT CL1-G HDS PORT CL2-G ZONE IN SWITCH2 CEC1 CHP 9E CEC1 CHP 9F CEC2 CHP 44 CEC2 CHP 47 HDS PORT CL1-H HDS PORT CL2-H To give you a break down, this server lives on CEC2 0.0.dc00 is attached to CHP 44 0.0.dd00 is attached to CHP 47 0.0.de00 is attached to CHP 48 0.0.df00 is attached to CHP 49 I have another server that runs with the same zfcp.conf file. It attaches with no issues. That is what's confusing me. Is it a zoning issue? Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond Higgs Sent: Tuesday, December 06, 2011 4:11 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP question for RHEL54 Scott, > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: warning: failed > gid_pn nameserver request for wwpn 0x50060e800571f006 for adapter 0.0.dc00 > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: port erp failed > (adapter 0.0.dc00, wwpn=0x50060e800571f006) The nameserver is a service that runs on your switches. GID_PN is a request to the nameserver for Get Port Identifier by Port Name. The error is that switch doesn't know about target port 0x50060e800571f006 so it can't return the n-port id that Linux needs. I'd investigate like this... 1. check zoning on your switch. Your channel may not have permission to talk to that target port. 2. check NPIV settings. If NPIV is on and you meant for it to be off, then that may change how you zone at the switch. 3. check cabling. If these linux systems are running on 2 different CECs, then maybe some channels on 1 CEC aren't cabled the way you expect. Regards, Ray Higgs System z FCP Firmware Development Bld. 706, B42 2455 South Road Poughkeepsie, NY 12601 (845) 435-8666, T/L 295-8666 rayhi...@us.ibm.com Linux on 390 Port wrote on 12/06/2011 03:04:53 PM: > From: "Shumate, Scott" > To: LINUX-390@vm.marist.edu > Date: 12/06/2011 03:11 PM > Subject: zFCP question for RHEL54 > Sent by: Linux on 390 Port > > I'm running into issues adding zFCP LUNS to a clustered zLinux server. > The primary servers sees the disk with no issues and have > multipath'ing turned on. Both servers should be pointing to the same > scsi disk. What am I missing? Any ideas? I've tried rebooting with > no results. I do see the following error in /var/log/messages > > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: warning: failed > gid_pn nameserver request for wwpn 0x50060e800571f006 for adapter 0.0.dc00 > Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: port erp failed > (adapter 0.0.dc00, wwpn=0x50060e800571f006) > > I see this for each adapter. I did try to remove the unit and port > vary the adapters offline and tried it again with the same results. > > The server that works > > > [root@wil-zstsccdbtst01 ~]# lsscsi > [0:0:0:1]diskHITACHI OPEN-V 6008 /dev/sda > [0:0:0:2]diskHITACHI OPEN-V 6008 /dev/sde > [1:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdb > [2:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdc > [3:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdd > > [root@wil-zstsccdbtst01 ~]# lszfcp -D > 0.0.dc00/0x50060e800571f006/0x0017 0:0:0:1 > 0.0.dc00/0x50060e800571f006/0x0019 0:0:0:2 > 0.0.dd00/0x50060e800571f016/0x0017 1:0:0:1 > 0.0.de00/0x50060e800571f007/0x0017 2:0:0:1 > 0.0.df00/0x50060e800571f017/0x0017 3:0:0:1 > > [root@wil-zstsccdbtst01 ~]# cat /etc/zfcp.conf > 0.0.dc000x50060e800571f006 0x0017 > 0.0.dd000x50060e800571f016 0x0017 > 0.0.de000x50060e800571f007 0x0017 > 0.0.df000x50060e800571f017 0x0017 > 0.0.dc000x50060e800571f006 0x0019 > > > > The server that fails > > [root@wil-zstsccdbtstbu01 0x50060e800571f006]# lsscsi > [root@wil-zstsccdbtstbu01 0x50060e800571f006]# > > [root@wil-zstsccdbtstbu01 0x50060e800571f006]# lszfcp -D > Error: No fcp devices found. > > [root@wil-zstsccdbtstbu01 0x50060e800571f006]# cat /etc/zfcp.conf > 0.0.dc000x50060e800571f006 0x001700
zFCP question for RHEL54
I'm running into issues adding zFCP LUNS to a clustered zLinux server. The primary servers sees the disk with no issues and have multipath'ing turned on. Both servers should be pointing to the same scsi disk. What am I missing? Any ideas? I've tried rebooting with no results. I do see the following error in /var/log/messages Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: warning: failed gid_pn nameserver request for wwpn 0x50060e800571f006 for adapter 0.0.dc00 Dec 6 14:28:15 wil-zstsccdbtstbu01 kernel: zfcp: port erp failed (adapter 0.0.dc00, wwpn=0x50060e800571f006) I see this for each adapter. I did try to remove the unit and port vary the adapters offline and tried it again with the same results. The server that works [root@wil-zstsccdbtst01 ~]# lsscsi [0:0:0:1]diskHITACHI OPEN-V 6008 /dev/sda [0:0:0:2]diskHITACHI OPEN-V 6008 /dev/sde [1:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdb [2:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdc [3:0:0:1]diskHITACHI OPEN-V 6008 /dev/sdd [root@wil-zstsccdbtst01 ~]# lszfcp -D 0.0.dc00/0x50060e800571f006/0x0017 0:0:0:1 0.0.dc00/0x50060e800571f006/0x0019 0:0:0:2 0.0.dd00/0x50060e800571f016/0x0017 1:0:0:1 0.0.de00/0x50060e800571f007/0x0017 2:0:0:1 0.0.df00/0x50060e800571f017/0x0017 3:0:0:1 [root@wil-zstsccdbtst01 ~]# cat /etc/zfcp.conf 0.0.dc000x50060e800571f006 0x0017 0.0.dd000x50060e800571f016 0x0017 0.0.de000x50060e800571f007 0x0017 0.0.df000x50060e800571f017 0x0017 0.0.dc000x50060e800571f006 0x0019 The server that fails [root@wil-zstsccdbtstbu01 0x50060e800571f006]# lsscsi [root@wil-zstsccdbtstbu01 0x50060e800571f006]# [root@wil-zstsccdbtstbu01 0x50060e800571f006]# lszfcp -D Error: No fcp devices found. [root@wil-zstsccdbtstbu01 0x50060e800571f006]# cat /etc/zfcp.conf 0.0.dc000x50060e800571f006 0x0017 0.0.dd000x50060e800571f016 0x0017 0.0.de000x50060e800571f007 0x0017 0.0.df000x50060e800571f017 0x0017 0.0.dc000x50060e800571f006 0x0019 Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of John Campbell Sent: Monday, December 05, 2011 9:25 AM To: LINUX-390@VM.MARIST.EDU Subject: At the optometrist's ... http://www.datamation.com/imagesvr_ce/5678/geek-eye-doctor.jpg ;-) My first though was whether there'd be enough humor in an EBCDIC version. -soup -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows -- 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: VTL with Linux
We are backing up our linux servers with fdr/upstream from z/OS side. We use CA-1 for tape management. Compression ratio stinks. We get about 1.25 to 1 compression. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Walters, Gene P Sent: Thursday, August 25, 2011 2:01 PM To: LINUX-390@VM.MARIST.EDU Subject: VTL with Linux Is anyone on the list running Linux and doing backups to a Virtual Tape Library? If so, how are you doing tape management? VM? Linux? Thanks Gene -- 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: zFCP disk issue on linux system z
Thanks for the update Steffen. I think that was my issue. Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Steffen Maier Sent: Friday, May 20, 2011 5:43 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP disk issue on linux system z Hi Scott, with RHEL(5), the persistent zfcp lun configuration is in the simple text file /etc/zfcp.conf. I don't know of any tools to manage this file except during the installation (with anaconda). Hence, any text editor will do. See also http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-zfcp.html which does describe post-installation configuration despite being part of the install guide. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 On 05/20/2011 09:55 PM, Shumate, Scott wrote: > Sorry. Im running red hat version 5.4 > -Original Message- > From: Mark Post > Sent: Friday, May 20, 2011 3:49 PM >>>> On 5/20/2011 at 02:59 PM, "Shumate, Scott" > wrote: >> I ran into something interesting today with zFCP disk. I've assigned >> a LUN to a linux server and it worked great. I did the following. >> >> 1. Set the adapter on line with chccwdev -e command >> 2. Added target port to FCP adapter by echoing port_add into wwpn. >> ex. echo 0x50060e800571f007> port_add >> 3. I cd to new port directory and added FCP LUN to that port by >> echoing unit_add into new port directory.\ >> ex. Echo 0x000b> unit_add >> 4. SCSI disk was available. I validated it with lsscsi command. >> >> I noticed that the LUN size was incorrect so I wanted to change the >> adapter to use a different LUN. In this case 0x0007. I >> removed the old LUN and changed added the new LUN with the following >> script. >> >> #!/bin/bash >> OLD_PWD=`pwd` >> DIR=/sys/bus/ccw/drivers/zfcp >> DROP=0x000b >> ADD=0x0007 >> PORT1=0x50060e800571f007 >> PORT2=0x50060e800571f017 >> PORT3=0x50060e800571f006 >> PORT4=0x50060e800571f016 >> echo 1> /sys/bus/scsi/devices/0\:0\:0\:1/delete >> echo 1> /sys/bus/scsi/devices/1\:0\:0\:1/delete >> echo 1> /sys/bus/scsi/devices/2\:0\:0\:1/delete >> echo 1> /sys/bus/scsi/devices/3\:0\:0\:1/delete >> echo $DROP> $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP> >> $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP> >> $DIR/0.0.de00/$PORT3/unit_remove echo $DROP> >> $DIR/0.0.df00/$PORT4/unit_remove echo $ADD> >> $DIR/0.0.dc00/$PORT1/unit_add echo $ADD> >> $DIR/0.0.dd00/$PORT2/unit_add echo $ADD> >> $DIR/0.0.de00/$PORT3/unit_add echo $ADD> >> $DIR/0.0.df00/$PORT4/unit_add >> >> It shows the new LUN. I validated it with the lszfcp -D command. >> Output below: >> 0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1 >> 0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1 >> 0.0.de00/0x50060e800571f006/0x0007 2:0:0:1 >> 0.0.df00/0x50060e800571f016/0x0007 3:0:0:1 >> >> So you can see that the lun is now 0X0007. When I reboot, it goes >> back to 0x000b. What am I missing? To get around this issue, I had >> to move LUNs around on the disk subsystem side. Can someone give me >> a > >> good process of removing LUNs and then readd them or tell me what I'm >> missing. > > You didn't say what distribution you're running. That's not relevant > to why you're seeing this happen, but it is relevant to how you fix it. > > Essentially, every command you issued is a dynamic change to the system. > Nothing was done to tell the system to do anything different on the > next boot. If you are running SLES, then the answer is to either: > 1. Use YaST to do this work. > 2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update > all the necessary configuration files yourself. > > I would pick option #1 or #2. :) -- 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: zFCP disk issue on linux system z
Sorry. Im running red hat version 5.4 Thanks Scott -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Friday, May 20, 2011 3:49 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: zFCP disk issue on linux system z >>> On 5/20/2011 at 02:59 PM, "Shumate, Scott" wrote: > I ran into something interesting today with zFCP disk. I've assigned > a LUN to a linux server and it worked great. I did the following. > > 1.Set the adapter on line with chccwdev -e command > 2.Added target port to FCP adapter by echoing port_add into wwpn. > ex. echo 0x50060e800571f007 > port_add > 3.I cd to new port directory and added FCP LUN to that port by > echoing unit_add into new port directory.\ > ex. Echo 0x000b > unit_add > 4.SCSI disk was available. I validated it with lsscsi command. > > I noticed that the LUN size was incorrect so I wanted to change the > adapter to use a different LUN. In this case 0x0007. I > removed the old LUN and changed added the new LUN with the following > script. > > #!/bin/bash > OLD_PWD=`pwd` > DIR=/sys/bus/ccw/drivers/zfcp > DROP=0x000b > ADD=0x0007 > PORT1=0x50060e800571f007 > PORT2=0x50060e800571f017 > PORT3=0x50060e800571f006 > PORT4=0x50060e800571f016 > echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete > echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete > echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete > echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete > echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP > > $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP > > $DIR/0.0.de00/$PORT3/unit_remove echo $DROP > > $DIR/0.0.df00/$PORT4/unit_remove echo $ADD > > $DIR/0.0.dc00/$PORT1/unit_add echo $ADD > > $DIR/0.0.dd00/$PORT2/unit_add echo $ADD > > $DIR/0.0.de00/$PORT3/unit_add echo $ADD > > $DIR/0.0.df00/$PORT4/unit_add > > It shows the new LUN. I validated it with the lszfcp -D command. > Output below: > 0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1 > 0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1 > 0.0.de00/0x50060e800571f006/0x0007 2:0:0:1 > 0.0.df00/0x50060e800571f016/0x0007 3:0:0:1 > > So you can see that the lun is now 0X0007. When I reboot, it goes > back to 0x000b. What am I missing? To get around this issue, I had > to move LUNs around on the disk subsystem side. Can someone give me a > good process of removing LUNs and then readd them or tell me what I'm > missing. You didn't say what distribution you're running. That's not relevant to why you're seeing this happen, but it is relevant to how you fix it. Essentially, every command you issued is a dynamic change to the system. Nothing was done to tell the system to do anything different on the next boot. If you are running SLES, then the answer is to either: 1. Use YaST to do this work. 2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update all the necessary configuration files yourself. I would pick option #1 or #2. :) 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/ -- 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/
zFCP disk issue on linux system z
Thanks Scott -Original Message- From: Shumate, Scott Sent: Friday, May 20, 2011 2:58 PM To: 'Linux on 390 Port' Subject: RE: cross compiling for s390 I ran into something interesting today with zFCP disk. I've assigned a LUN to a linux server and it worked great. I did the following. 1. Set the adapter on line with chccwdev -e command 2. Added target port to FCP adapter by echoing port_add into wwpn. ex. echo 0x50060e800571f007 > port_add 3. I cd to new port directory and added FCP LUN to that port by echoing unit_add into new port directory.\ ex. Echo 0x000b > unit_add 4. SCSI disk was available. I validated it with lsscsi command. I noticed that the LUN size was incorrect so I wanted to change the adapter to use a different LUN. In this case 0x0007. I removed the old LUN and changed added the new LUN with the following script. #!/bin/bash OLD_PWD=`pwd` DIR=/sys/bus/ccw/drivers/zfcp DROP=0x000b ADD=0x0007 PORT1=0x50060e800571f007 PORT2=0x50060e800571f017 PORT3=0x50060e800571f006 PORT4=0x50060e800571f016 echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP > $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP > $DIR/0.0.de00/$PORT3/unit_remove echo $DROP > $DIR/0.0.df00/$PORT4/unit_remove echo $ADD > $DIR/0.0.dc00/$PORT1/unit_add echo $ADD > $DIR/0.0.dd00/$PORT2/unit_add echo $ADD > $DIR/0.0.de00/$PORT3/unit_add echo $ADD > $DIR/0.0.df00/$PORT4/unit_add It shows the new LUN. I validated it with the lszfcp -D command. Output below: 0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1 0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1 0.0.de00/0x50060e800571f006/0x0007 2:0:0:1 0.0.df00/0x50060e800571f016/0x0007 3:0:0:1 So you can see that the lun is now 0X0007. When I reboot, it goes back to 0x000b. What am I missing? To get around this issue, I had to move LUNs around on the disk subsystem side. Can someone give me a good process of removing LUNs and then readd them or tell me what I'm missing. Regards, Scott Shumate Software Systems Prog Spec Branch Bank & Trust Assistant Vice President Mainframe Support Mail Code: 100-99-09-10 Work: (252) 246-2306 Cell:(252) 373-9605 -- .~. /\/\ /( )\ ^^-^^ Linux on Systems Z - -- 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: cross compiling for s390
I ran into something interesting today with zFCP disk. I've assigned a LUN to a linux server and it worked great. I did the following. 1. Set the adapter on line with chccwdev -e command 2. Added target port to FCP adapter by echoing port_add into wwpn. ex. echo 0x50060e800571f007 > port_add 3. I cd to new port directory and added FCP LUN to that port by echoing unit_add into new port directory.\ ex. Echo 0x000b > unit_add 4. SCSI disk was available. I validated it with lsscsi command. I noticed that the LUN size was incorrect so I wanted to change the adapter to use a different LUN. In this case 0x0007. I removed the old LUN and changed added the new LUN with the following script. #!/bin/bash OLD_PWD=`pwd` DIR=/sys/bus/ccw/drivers/zfcp DROP=0x000b ADD=0x0007 PORT1=0x50060e800571f007 PORT2=0x50060e800571f017 PORT3=0x50060e800571f006 PORT4=0x50060e800571f016 echo 1 > /sys/bus/scsi/devices/0\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/1\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/2\:0\:0\:1/delete echo 1 > /sys/bus/scsi/devices/3\:0\:0\:1/delete echo $DROP > $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP > $DIR/0.0.dd00/$PORT2/unit_remove echo $DROP > $DIR/0.0.de00/$PORT3/unit_remove echo $DROP > $DIR/0.0.df00/$PORT4/unit_remove echo $ADD > $DIR/0.0.dc00/$PORT1/unit_add echo $ADD > $DIR/0.0.dd00/$PORT2/unit_add echo $ADD > $DIR/0.0.de00/$PORT3/unit_add echo $ADD > $DIR/0.0.df00/$PORT4/unit_add It shows the new LUN. I validated it with the lszfcp -D command. Output below: 0.0.dc00/0x50060e800571f007/0x0007 0:0:0:1 0.0.dd00/0x50060e800571f017/0x0007 1:0:0:1 0.0.de00/0x50060e800571f006/0x0007 2:0:0:1 0.0.df00/0x50060e800571f016/0x0007 3:0:0:1 So you can see that the lun is now 0X0007. When I reboot, it goes back to 0x000b. What am I missing? To get around this issue, I had to move LUNs around on the disk subsystem side. Can someone give me a good process of removing LUNs and then readd them or tell me what I'm missing. Regards, Scott Shumate Software Systems Prog Spec Branch Bank & Trust Assistant Vice President Mainframe Support Mail Code: 100-99-09-10 Work: (252) 246-2306 Cell:(252) 373-9605 -- .~. /\/\ /( )\ ^^-^^ Linux on Systems Z - -- 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/
