Re: Question About LGR and Hipersocket using RHEL 7.7

[Grzegorz Powiedziuk]

On Thu, Apr 8, 2021, 12:12 PM Davis, Larry (National VM Capability) <
larry.dav...@dxc.com> wrote:

> We are seeing an Issue when Using Hipersockets connected to a DB2 system
> on z/OS
>
> When we perform a VMRELOCATE (LGR) to another member in the complex we
> lose the HS device and it goes offline
> The Relocate works fine the HS devices have the same EQID and we see the
> devices attached on the receiving system
> OSA 3A00 ATTACHED TO LXCGG01D 08A0 BY LXCGG01D
> OSA 3A01 ATTACHED TO LXCGG01D 08A1 BY LXCGG01D
> OSA 3A02 ATTACHED TO LXCGG01D 08A2 BY LXCGG01D
>
> Then we need to perform
> cio_ignore -r 0.0.08A0
> cio_ignore -r 0.0.08A0
> cio_ignore -r 0.0.08A0
>
> Then we have to restart the network devices
>
> For some reason during the LGR and/or reboot the devices are getting
> varied off and/or disabled.
>
> Am I missing something in the devices characteristics
>
> Also We are using a VSWITCH for 1G and 10G OSA's and they are reconnecting
> as expected, but HS is disappearing
>
> Larry Davis
> Senior z/VM systems Architect, Enterprise Services
> T +1.813.394.4240
> DXC Technology dxc.technology
>
>
>
How are you activating these HSI devices? Did you use the znet_conf and did
you add a ifcfg-enccw0. script ? Or you have some other way for
configuring those on boot?
I also use rhel 7.x with hipersockets and I haven't noticed a problem like
this. I used znet_conf initially to configure it live, and then added a
proper ifcfg script.
Gregory

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Mark Post]

On 4/20/21 2:04 PM, Stefan Raspl wrote:
> This is really a shot in the dark, but: Could it be a case where the
> device number from source and target system are different, and you have
> the target system's device IDs on the cio ignore list prior to the
> migration? I.e. what happens in case you run the cio_ignore commands
> prior to an LGM?

Better yet, for z/VM and KVM guests, get rid of cio_ignore altogether.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Davis, Larry (National VM Capability)]

Thanks we are testing again soon, just looking for others that may have tried 
and had similar issues

Larry Davis (z/VM Team)

-Original Message-
From: Linux on 390 Port  On Behalf Of Bill Bitner
Sent: Tuesday, April 20, 2021 12:49 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question About LGR and Hipersocket using RHEL 7.7

Larry,
If this isn't resolved, I'd suggest you open a z/VM support case and the team 
and take a closer look.

Thanks,
Bill
___

Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com 
"Making systems practical and profitable for customers through virtualization 
and its exploitation." - z/VM

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://clicktime.symantec.com/3MtjfDJabpB1V2YzGv9uirN7Vc?u=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Stefan Raspl]

Hi Larry,

On 4/8/21 6:11 PM, Davis, Larry (National VM Capability) wrote:

We are seeing an Issue when Using Hipersockets connected to a DB2 system on z/OS

When we perform a VMRELOCATE (LGR) to another member in the complex we lose the 
HS device and it goes offline
The Relocate works fine the HS devices have the same EQID and we see the 
devices attached on the receiving system
OSA 3A00 ATTACHED TO LXCGG01D 08A0 BY LXCGG01D
OSA 3A01 ATTACHED TO LXCGG01D 08A1 BY LXCGG01D
OSA 3A02 ATTACHED TO LXCGG01D 08A2 BY LXCGG01D

Then we need to perform
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0


I assume this is a typo and should be A0, A1 and A2, right?


Then we have to restart the network devices

For some reason during the LGR and/or reboot the devices are getting varied off 
and/or disabled.


This is really a shot in the dark, but: Could it be a case where the device 
number from source and target system are different, and you have the target 
system's device IDs on the cio ignore list prior to the migration? I.e. what 
happens in case you run the cio_ignore commands prior to an LGM?



Mit freundlichen Grüßen / Kind regards

Stefan Raspl


Linux on Z
---
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2177
E-Mail: stefan.ra...@de.ibm.com
---
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: 
Gregor Pillen

Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Bill Bitner]

Larry,
If this isn't resolved, I'd suggest you open a z/VM support case and the
team and take a closer look.

Thanks,
Bill
___

Bill Bitner - z/VM Client Focus and Care - 607-429-3286
bitn...@us.ibm.com
"Making systems practical and profitable for customers through
virtualization and its exploitation." - z/VM

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question on auto lun scan

[Will, Chris]

 [sdd] 141434880 512-byte logical blocks: (72.4 
GB/67.4 GiB)
[5.028987] sd 1:0:0:0: [sdc] Write Protect is off
[5.028999] sd 1:0:0:0: [sdc] Mode Sense: 8b 00 00 08
[5.029462] sd 1:0:0:0: [sdc] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[5.030860] sd 1:0:0:1: [sdd] Write Protect is off

[5.030872] sd 1:0:0:1: [sdd] Mode Sense: 8b 00 00 08
[5.032427] sd 1:0:0:1: [sdd] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[5.034279]  sdc: sdc1
[5.037147]  sdd: sdd1
[5.041471] sd 1:0:0:0: [sdc] Attached SCSI disk
[5.043020] sd 1:0:0:1: [sdd] Attached SCSI disk

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port  On Behalf Of Benjamin Block
Sent: Wednesday, February 20, 2019 5:06 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on auto lun scan

Hey Alan,

On Tue, Feb 19, 2019 at 01:06:17PM -0500, Alan Altmark wrote:
> On Tuesday, 02/19/2019 at 01:49 GMT, Benjamin Block  
> wrote:
> > udev_timeout=30
> >
> > The default is 30s, you can add it to the kernel command line
> > (/etc/zipl.conf), and increase it (e.g.: udev_timeout=90).
> >
> > This will increase the timeout for for both udevadm and the step where
> > it waits for the root-volume to appear.
> 
> Does that mean ALL of the needed needed LUNs must be brought online within 
> 30 seconds?  Or that REPORT LUNS (LUN 0) or INQUIRY (LUN 0 and/or all 
> others) must EACH respond within 30 seconds?
> 

It regulates two things at once.

First, during the early phase of the INITRD, the init process will start
'udev', and then use 'udevadm settle --timeout=${udev_timeout}' to wait
till it udev processed all the events happening in the kernel (such as
adding devices, executing rules upon it saw specific devices being added
[such as loading drivers and so on], and so on). This timeout is
deceptive though, it will only wait up to this amount OR if there is no
events in the queue anymore.. if an event happens 1s after it already
stopped waiting, bad luck - although, because udev keeps running as
daemon, it should sill process the event if I am not mistaken, its just
that init will continue doing other things meanwhile (such as:).

The second mechanism it controls is the late phase during run of the
INITRD, where init will wait till it sees the root-volume appear. In
this phase it will wait up to ${udev_timeout} seconds till it sees it,
and after that it will fall back to ask the user for guidance (which is
what I think is happening here, although strictly spoken, this is only a
guess).

That is as far as I have read the code - mind you, I didn't write it, so
it may well be that I have miss-interpreted something.



But this all changes with SLES12, because SLES12 uses a different kind
of INITRD (dracut) and the code there probably doesn't even know this
parameter. So this is strictly SLES11 only.

-- 
With Best Regards, Benjamin Block  /  Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Matthias Hartmann   /  Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG 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


The information contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

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

Re: Question on auto lun scan

[Benjamin Block]

Hey Alan,

On Tue, Feb 19, 2019 at 01:06:17PM -0500, Alan Altmark wrote:
> On Tuesday, 02/19/2019 at 01:49 GMT, Benjamin Block  
> wrote:
> > udev_timeout=30
> >
> > The default is 30s, you can add it to the kernel command line
> > (/etc/zipl.conf), and increase it (e.g.: udev_timeout=90).
> >
> > This will increase the timeout for for both udevadm and the step where
> > it waits for the root-volume to appear.
> 
> Does that mean ALL of the needed needed LUNs must be brought online within 
> 30 seconds?  Or that REPORT LUNS (LUN 0) or INQUIRY (LUN 0 and/or all 
> others) must EACH respond within 30 seconds?
> 

It regulates two things at once.

First, during the early phase of the INITRD, the init process will start
'udev', and then use 'udevadm settle --timeout=${udev_timeout}' to wait
till it udev processed all the events happening in the kernel (such as
adding devices, executing rules upon it saw specific devices being added
[such as loading drivers and so on], and so on). This timeout is
deceptive though, it will only wait up to this amount OR if there is no
events in the queue anymore.. if an event happens 1s after it already
stopped waiting, bad luck - although, because udev keeps running as
daemon, it should sill process the event if I am not mistaken, its just
that init will continue doing other things meanwhile (such as:).

The second mechanism it controls is the late phase during run of the
INITRD, where init will wait till it sees the root-volume appear. In
this phase it will wait up to ${udev_timeout} seconds till it sees it,
and after that it will fall back to ask the user for guidance (which is
what I think is happening here, although strictly spoken, this is only a
guess).

That is as far as I have read the code - mind you, I didn't write it, so
it may well be that I have miss-interpreted something.



But this all changes with SLES12, because SLES12 uses a different kind
of INITRD (dracut) and the code there probably doesn't even know this
parameter. So this is strictly SLES11 only.

-- 
With Best Regards, Benjamin Block  /  Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Matthias Hartmann   /  Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG 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

Re: Question on auto lun scan

[Alan Altmark]

On Tuesday, 02/19/2019 at 01:49 GMT, Benjamin Block  
wrote:
> udev_timeout=30
>
> The default is 30s, you can add it to the kernel command line
> (/etc/zipl.conf), and increase it (e.g.: udev_timeout=90).
>
> This will increase the timeout for for both udevadm and the step where
> it waits for the root-volume to appear.

Does that mean ALL of the needed needed LUNs must be brought online within 
30 seconds?  Or that REPORT LUNS (LUN 0) or INQUIRY (LUN 0 and/or all 
others) must EACH respond within 30 seconds?

Alan Altmark

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


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Question on auto lun scan

[Benjamin Block]

Hello Chris,

On Fri, Feb 15, 2019 at 02:32:43PM +, Will, Chris wrote:
> Thanks for your input.  
>
> One question, for SLES 11 is there a timeout on waiting for the LUN
> information after the REPORT LUNS is issued?

There is one knob I know of that you can adjust:

udev_timeout=30

The default is 30s, you can add it to the kernel command line
(/etc/zipl.conf), and increase it (e.g.: udev_timeout=90).

This will increase the timeout for for both udevadm and the step where
it waits for the root-volume to appear.

I can't say whether that will help you though (w/o more insight in what
actually happens on your machines during boot), sry.

> If it times out does it retry.

Yes and no.

At the time when the REPORT LUNS command is sent by the SCSI Common Code
in the Kernel, after the FCP devices initially got enabled, and
discovered all the remote ports, it will retry sending it up to three
times under certain conditions: SCSI Command timeouts (hard-coded; 30s),
and Commands failed with SCSI Sense 'UNIT ATTENTION'.

But right now there is no way telling if either of that actually
happens.

After this succeeded at least once - lets assume that, because you said
before, you saw LUNs being discovered, just too late - It is not retried
anymore withing the boot phase of the INITRD - or at all as far as I
know, unless someone triggers one automatically.

> Again this is during the boot process.  I have include the output from
> one of the servers I updated with the zipl changes.  This one is
> without the Cirrus device and was successful.
>  
> <5>[  112.205720] SCSI subsystem initialized
> <6>[  112.271921] qeth.87067b: loading core functions
> .
> <5>[  114.375565] sd 1:0:0:1: [sdd] Attached SCSI disk

Sry, I can't really tell anything special from these logs, it looks
normal. Like you said, this is a good case IPL.



Generally speaking though, its hard to give you proper advice here on
the list. Its also not the right place to exchange debug-data. If you
need more in-depth support it might be best if you contact IBM Z Linux
Support, so that we get a ticket for it.

> 
> -Original Message-
> From: Benjamin Block  
> Sent: Friday, February 08, 2019 11:35 AM
> To: Will, Chris 
> Cc: Linux on 390 Port 
> Subject: Re: Question on auto lun scan
> 
> Hello Chris,
> 
> On Fri, Feb 08, 2019 at 01:18:49PM +, Will, Chris wrote:
> > Thank you for all the information so far.  We had another meeting with 
> > the Cirrus team and they said that when they get the initial login 
> > they have to insert their wwpn so if they are delayed in doing this 
> > they report back a "busy" status.  For the next shot at implementing 
> > this they are going to pre-define all the npiv wwpns to prevent this 
> > delay.  They could also delay up to 10 seconds reporting back a "busy"
> > status to the server.  I did see a console log captured by z/VM which 
> > showed the server going into emergency repair mode but the LUNs were 
> > discovered later (not sure how much later since there were no
> > timestamps) but by this point the server was already in trouble.  We 
> > are using NPIV and have autolun scan enabled for the servers.  So far 
> > none of the SLES12 SP3 guests have had issues but most of the SLES11
> > SP4 guests go into this emergency repair mode.
> >
> 
> Steffen and I suspect this is not really a problem with the Cirrus
> devices. It just exposes a shortcoming in the SLES11 initial ramdisk
> and how this handles device-discovery, by adding a big'ish delay to
> the LUN-scanning.
> 
> As you say, you see devices being discovered after all, so the
> LUN-Scan Linux does, does in fact work as designed. It sounds like the
> initrd aborts its scanning - or rather: waiting - to early. This is a
> bit complicated, because there is no clear interface between the
> kernel and the userspace that tells the userspace that scanning is now
> over, and nothing will pop up anymore. SLES12 got better here.
> 
> But anyway, Steffen wrote some advice what additional debugging you
> could do, by adding the additional kernel command line parameters he
> mentioned (at the bottom of this mail). With them it would probably
> become more clear what component is failing here. It also adds some
> relative timestamps and such.
> 
> You can also instruct z/VM to spool the console output, and later
> print that spool-space into a file, so its easier to handle than just
> with whatever console you use.
> 
> > 
> > -Original Message-
> > From: Linux on 390 Port  On Behalf Of Steffen 
> > Maier
> > Sent: Friday, February 08, 2019 6:36 AM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on auto l

Re: Question on auto lun scan

[Will, Chris]

DRIVER_OK
<6>[  114.365917] sd 1:0:0:0: CDB: Test Unit Ready: 00 00 00 00 00 00
<6>[  114.365936] sd 1:0:0:0:  Sense Key : Unit Attention [current] 
<6>[  114.365945] sd 1:0:0:0:  Add. Sense: I_T nexus loss occurred
<6>[  114.365981] scsi scan: REPORT LUNS successful (try 0) result 0x0
<6>[  114.365989] sd 1:0:0:0: scsi scan: REPORT LUN scan
<6>[  114.365995] scsi scan: device exists on 1:0:0:0
<6>[  114.366408] scsi 1:0:0:1: scsi scan: INQUIRY pass 1 length 36
<5>[  114.366607] sd 1:0:0:0: [sdc] 141434880 512-byte logical blocks: (72.4 
GB/67.4 GiB)
<6>[  114.366617] scsi scan: INQUIRY successful with code 0x0
<6>[  114.366622] scsi 1:0:0:1: scsi scan: INQUIRY pass 2 length 149
<6>[  114.366775] scsi scan: INQUIRY successful with code 0x0
<5>[  114.366781] scsi 1:0:0:1: Direct-Access EMC  SYMMETRIX
5874 PQ: 0 ANSI: 5
<4>[  114.366837] sg_alloc: dev=3 
<5>[  114.366857] sd 1:0:0:1: Attached scsi generic sg3 type 0
<6>[  114.367330] sd 1:0:0:1: Done: SUCCESS
<6>[  114.367334] sd 1:0:0:1:  Result: hostbyte=DID_OK driverbyte=DRIVER_OK
<6>[  114.367338] sd 1:0:0:1: CDB: Test Unit Ready: 00 00 00 00 00 00
<6>[  114.367345] sd 1:0:0:1:  Sense Key : Unit Attention [current] 
<6>[  114.367349] sd 1:0:0:1:  Add. Sense: I_T nexus loss occurred
<5>[  114.368387] sd 1:0:0:1: [sdd] 141434880 512-byte logical blocks: (72.4 
GB/67.4 GiB)
<5>[  114.368752] sd 1:0:0:0: [sdc] Write Protect is off
<7>[  114.368756] sd 1:0:0:0: [sdc] Mode Sense: 8b 00 00 08
<5>[  114.369051] sd 1:0:0:0: [sdc] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
<5>[  114.369502] sd 1:0:0:1: [sdd] Write Protect is off
<7>[  114.369506] sd 1:0:0:1: [sdd] Mode Sense: 8b 00 00 08
<5>[  114.369810] sd 1:0:0:1: [sdd] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
<6>[  114.371017]  sdc: sdc1
<6>[  114.371976]  sdd: sdd1
<5>[  114.374989] sd 1:0:0:0: [sdc] Attached SCSI disk
<5>[  114.375565] sd 1:0:0:1: [sdd] Attached SCSI disk

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Benjamin Block  
Sent: Friday, February 08, 2019 11:35 AM
To: Will, Chris 
Cc: Linux on 390 Port 
Subject: Re: Question on auto lun scan

Hello Chris,

On Fri, Feb 08, 2019 at 01:18:49PM +, Will, Chris wrote:
> Thank you for all the information so far.  We had another meeting with 
> the Cirrus team and they said that when they get the initial login 
> they have to insert their wwpn so if they are delayed in doing this 
> they report back a "busy" status.  For the next shot at implementing 
> this they are going to pre-define all the npiv wwpns to prevent this 
> delay.  They could also delay up to 10 seconds reporting back a "busy"
> status to the server.  I did see a console log captured by z/VM which 
> showed the server going into emergency repair mode but the LUNs were 
> discovered later (not sure how much later since there were no
> timestamps) but by this point the server was already in trouble.  We 
> are using NPIV and have autolun scan enabled for the servers.  So far 
> none of the SLES12 SP3 guests have had issues but most of the SLES11
> SP4 guests go into this emergency repair mode.
>

Steffen and I suspect this is not really a problem with the Cirrus devices. It 
just exposes a shortcoming in the SLES11 initial ramdisk and how this handles 
device-discovery, by adding a big'ish delay to the LUN-scanning.

As you say, you see devices being discovered after all, so the LUN-Scan Linux 
does, does in fact work as designed. It sounds like the initrd aborts its 
scanning - or rather: waiting - to early. This is a bit complicated, because 
there is no clear interface between the kernel and the userspace that tells the 
userspace that scanning is now over, and nothing will pop up anymore. SLES12 
got better here.

But anyway, Steffen wrote some advice what additional debugging you could do, 
by adding the additional kernel command line parameters he mentioned (at the 
bottom of this mail). With them it would probably become more clear what 
component is failing here. It also adds some relative timestamps and such.

You can also instruct z/VM to spool the console output, and later print that 
spool-space into a file, so its easier to handle than just with whatever 
console you use.

> 
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Steffen 
> Maier
> Sent: Friday, February 08, 2019 6:36 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on auto lun scan
> 
> On 02/05/2019 12:02 PM, Benjamin Block wrote:
> > On Mon, Feb 04, 2019 at 04:37:52PM +, Will, Chris wrote:
> >> We have auto lun scan turned on for our SLES 11 SP4 hos

Re: Question on auto lun scan

[Benjamin Block]

Hello Chris,

On Fri, Feb 08, 2019 at 01:18:49PM +, Will, Chris wrote:
> Thank you for all the information so far.  We had another meeting with
> the Cirrus team and they said that when they get the initial login
> they have to insert their wwpn so if they are delayed in doing this
> they report back a "busy" status.  For the next shot at implementing
> this they are going to pre-define all the npiv wwpns to prevent this
> delay.  They could also delay up to 10 seconds reporting back a "busy"
> status to the server.  I did see a console log captured by z/VM which
> showed the server going into emergency repair mode but the LUNs were
> discovered later (not sure how much later since there were no
> timestamps) but by this point the server was already in trouble.  We
> are using NPIV and have autolun scan enabled for the servers.  So far
> none of the SLES12 SP3 guests have had issues but most of the SLES11
> SP4 guests go into this emergency repair mode.
>

Steffen and I suspect this is not really a problem with the Cirrus
devices. It just exposes a shortcoming in the SLES11 initial ramdisk and
how this handles device-discovery, by adding a big'ish delay to the
LUN-scanning.

As you say, you see devices being discovered after all, so the LUN-Scan
Linux does, does in fact work as designed. It sounds like the initrd
aborts its scanning - or rather: waiting - to early. This is a bit
complicated, because there is no clear interface between the kernel and
the userspace that tells the userspace that scanning is now over, and
nothing will pop up anymore. SLES12 got better here.

But anyway, Steffen wrote some advice what additional debugging you
could do, by adding the additional kernel command line parameters he
mentioned (at the bottom of this mail). With them it would probably
become more clear what component is failing here. It also adds some
relative timestamps and such.

You can also instruct z/VM to spool the console output, and later print
that spool-space into a file, so its easier to handle than just with
whatever console you use.

> 
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Steffen Maier
> Sent: Friday, February 08, 2019 6:36 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on auto lun scan
> 
> On 02/05/2019 12:02 PM, Benjamin Block wrote:
> > On Mon, Feb 04, 2019 at 04:37:52PM +, Will, Chris wrote:
> >> We have auto lun scan turned on for our SLES 11 SP4 hosts and it is 
> >> on by default for our SLES 12 SP3 hosts.  We are trying to insert a 
> >> Cirrus device which has the capability to discover LUNs and NPIV WWNs.
> >> My very limited understanding of the process, during the initial boot 
> >> process (z/VM IPL) it initially will report back no LUNs to the 
> >> guest, logs into the storage device and then reports back to the 
> >> guest with the LUNs that are masked for the NPIV WWPN.
> 
> Is it this?: https://www.cdsi.us.com/technology/
> If so, it sounds as if the discovery on the appliance is done on
> initializing the multi-step data migration. After that, I would assume
> it persistently knows both ends and answers on behalf of its attached
> opposite ends (host, storage).
> 
> Actually it has quite some commonality with SAN volume virtualizers
> using "pass-through" mirrored "image" volumes. One of the main
> differences being that it can be inserted into the data path without
> having to reconfigure the host as the host still gets to see something
> that looks like the old storage one is migrating from.
> 
> > Auto-LUN-Scan in Linux works roughly as follows:
> >   - in z/VM guests you need dedicated FCP devices that are on CHPIDs with
> > NPIV enabled (I assume you have that already). Apart from this z/VM
> > does not play any role in this, it doesn't help or intercept
> > anything.
> >   - during boot - when the zFCP driver is loaded, usually by the initial
> > RAM-Disk - we (the driver) scan the FC-Network for available remote
> > ports (ports that are in the same zone as the initiator ports on
> > your) and open them automatically
> > - this happens completely transparent, regardless of whether NPIV
> >   and/or auto-LUN-scan is enabled or not
> >   - for each successfully opened remote port the Linux Kernel SCSI code
> > will issue LUN-scanning. If you have auto-LUN-scan enabled and use a
> > NPIV enabled FCP device the zFCP driver will allow the scan to
> > happen - otherwise we intercept it.
> >   - such a scan entails sending of the SCSI Command REPORT LUNS (support
> > for this commands is mandatory for every SCSI device type), and for
> > all reported device

Re: Question on auto lun scan

[Will, Chris]

Thank you for all the information so far.  We had another meeting with the 
Cirrus team and they said that when they get the initial login they have to 
insert their wwpn so if they are delayed in doing this they report back a 
"busy" status.  For the next shot at implementing this they are going to 
pre-define all the npiv wwpns to prevent this delay.  They could also delay up 
to 10 seconds reporting back a "busy" status to the server.  I did see a 
console log captured by z/VM which showed the server going into emergency 
repair mode but the LUNs were discovered later (not sure how much later since 
there were no timestamps) but by this point the server was already in trouble.  
We are using NPIV and have autolun scan enabled for the servers.  So far none 
of the SLES12 SP3 guests have had issues but most of the SLES11 SP4 guests go 
into this emergency repair mode.

Chris Will
Enterprise Linux/UNIX (ELU)
(313) 549-9729 Cell
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port  On Behalf Of Steffen Maier
Sent: Friday, February 08, 2019 6:36 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on auto lun scan

On 02/05/2019 12:02 PM, Benjamin Block wrote:
> On Mon, Feb 04, 2019 at 04:37:52PM +, Will, Chris wrote:
>> We have auto lun scan turned on for our SLES 11 SP4 hosts and it is 
>> on by default for our SLES 12 SP3 hosts.  We are trying to insert a 
>> Cirrus device which has the capability to discover LUNs and NPIV WWNs.
>> My very limited understanding of the process, during the initial boot 
>> process (z/VM IPL) it initially will report back no LUNs to the 
>> guest, logs into the storage device and then reports back to the 
>> guest with the LUNs that are masked for the NPIV WWPN.

Is it this?: https://www.cdsi.us.com/technology/
If so, it sounds as if the discovery on the appliance is done on initializing 
the multi-step data migration. After that, I would assume it persistently knows 
both ends and answers on behalf of its attached opposite ends (host, storage).

Actually it has quite some commonality with SAN volume virtualizers using 
"pass-through" mirrored "image" volumes. One of the main differences being that 
it can be inserted into the data path without having to reconfigure the host as 
the host still gets to see something that looks like the old storage one is 
migrating from.

> Auto-LUN-Scan in Linux works roughly as follows:
>   - in z/VM guests you need dedicated FCP devices that are on CHPIDs with
> NPIV enabled (I assume you have that already). Apart from this z/VM
> does not play any role in this, it doesn't help or intercept
> anything.
>   - during boot - when the zFCP driver is loaded, usually by the initial
> RAM-Disk - we (the driver) scan the FC-Network for available remote
> ports (ports that are in the same zone as the initiator ports on
> your) and open them automatically
> - this happens completely transparent, regardless of whether NPIV
>   and/or auto-LUN-scan is enabled or not
>   - for each successfully opened remote port the Linux Kernel SCSI code
> will issue LUN-scanning. If you have auto-LUN-scan enabled and use a
> NPIV enabled FCP device the zFCP driver will allow the scan to
> happen - otherwise we intercept it.
>   - such a scan entails sending of the SCSI Command REPORT LUNS (support
> for this commands is mandatory for every SCSI device type), and for
> all reported devices the Linux kernel will create SCSI-Devices
>   - note that "opening" a LUN does not actually generate any traffic in
> the network, only the remote port open and REPORT LUNS does generate
> traffic, and for all found LUNs Linux will also send some
> INQUIRY commands and such, but there is no "open LUN" command as
> such
>   - Linux doesn't retry this LUN-scanning later without any reason (port
> recovery or such), so if the network stays quit it doesn't
>
> Now, I have never worked with the devices you want to use, so its 
> guessing after this.
>
> If I understand you correctly the Cirrus device sits between your 
> initiator FC-Ports (on the Z side) and the storage-server, somewhere 
> in the network and intercepts your traffic? So Linux will open the 
> port on this device and it will see the initial traffic by Linux, and 
> forward it to whatever storage-server it thinks is correct.
>
> If it does not report back the correct list of LUNs for the initial 
> REPORT LUNS command, you have a problem (and I'd consider this device 
> broken). There are some fall-backs in the kernel for cases where the 
> storage device is buggy and/or doesn't properly support modern SCSI 
> standards, but that doesn't mean it'll help you.
>
>>

Re: Question on auto lun scan

[Steffen Maier]

On 02/05/2019 12:02 PM, Benjamin Block wrote:

On Mon, Feb 04, 2019 at 04:37:52PM +, Will, Chris wrote:

We have auto lun scan turned on for our SLES 11 SP4 hosts and it is on
by default for our SLES 12 SP3 hosts.  We are trying to insert a
Cirrus device which has the capability to discover LUNs and NPIV WWNs.
My very limited understanding of the process, during the initial boot
process (z/VM IPL) it initially will report back no LUNs to the guest,
logs into the storage device and then reports back to the guest with
the LUNs that are masked for the NPIV WWPN.


Is it this?: https://www.cdsi.us.com/technology/
If so, it sounds as if the discovery on the appliance is done on initializing
the multi-step data migration. After that, I would assume it persistently knows
both ends and answers on behalf of its attached opposite ends (host, storage).

Actually it has quite some commonality with SAN volume virtualizers using
"pass-through" mirrored "image" volumes. One of the main differences being that
it can be inserted into the data path without having to reconfigure the host as
the host still gets to see something that looks like the old storage one is
migrating from.


Auto-LUN-Scan in Linux works roughly as follows:
  - in z/VM guests you need dedicated FCP devices that are on CHPIDs with
NPIV enabled (I assume you have that already). Apart from this z/VM
does not play any role in this, it doesn't help or intercept
anything.
  - during boot - when the zFCP driver is loaded, usually by the initial
RAM-Disk - we (the driver) scan the FC-Network for available remote
ports (ports that are in the same zone as the initiator ports on
your) and open them automatically
- this happens completely transparent, regardless of whether NPIV
  and/or auto-LUN-scan is enabled or not
  - for each successfully opened remote port the Linux Kernel SCSI code
will issue LUN-scanning. If you have auto-LUN-scan enabled and use a
NPIV enabled FCP device the zFCP driver will allow the scan to
happen - otherwise we intercept it.
  - such a scan entails sending of the SCSI Command REPORT LUNS (support
for this commands is mandatory for every SCSI device type), and for
all reported devices the Linux kernel will create SCSI-Devices
  - note that "opening" a LUN does not actually generate any traffic in
the network, only the remote port open and REPORT LUNS does generate
traffic, and for all found LUNs Linux will also send some
INQUIRY commands and such, but there is no "open LUN" command as
such
  - Linux doesn't retry this LUN-scanning later without any reason (port
recovery or such), so if the network stays quit it doesn't

Now, I have never worked with the devices you want to use, so its
guessing after this.

If I understand you correctly the Cirrus device sits between your
initiator FC-Ports (on the Z side) and the storage-server, somewhere in
the network and intercepts your traffic? So Linux will open the port on
this device and it will see the initial traffic by Linux, and forward it
to whatever storage-server it thinks is correct.

If it does not report back the correct list of LUNs for the initial
REPORT LUNS command, you have a problem (and I'd consider this device
broken). There are some fall-backs in the kernel for cases where the
storage device is buggy and/or doesn't properly support modern SCSI
standards, but that doesn't mean it'll help you.


This does not seem to give the SLES 12 guests issues but most of the
SLES 11 guests have issues.  Is there anyway for the guest to do a
retry, otherwise it ends up in emergency repair mode (setting we have
in fstab).


Its hard to give you proper advice without knowing in what state the
system halts, and what exactly happend during the whole process I
described above.

But in the absence of this:

Like Mark said, it might help to just trigger a scan manually with the
script rescan-scsi-bus.sh, or you could just try writing into the scan
attribute of the SCSI-Hosts in question (as root):

+-- Device-Bus-ID of your FCP device
|
v
echo "- - -" > /sys/devices/css*/*/0.0.1900/host*/scsi_host/host*/scan

This should issue an other rescan of all the attached remote ports, and
you don't need any extra tools. You might also be able to script that
and put it in your initial ram-disk (although that might be not as easy
as it sounds; you'd have to find a proper trigger and time to issue the
script during the boot-process). I don't know any way to activate
something like this "out-of-the-box" with SLES11 (or 12 for that
matter).


Appending the following at IPL to the kernel parameters, might help you debug
further at which point things break in the way that some disk block device it
depends on is not configured or ready. This includes any initrd processing, and
auto lun scan processing during initrd and after initrd. 

Re: Question on auto lun scan

[Benjamin Block]

On Mon, Feb 04, 2019 at 04:37:52PM +, Will, Chris wrote:
> We have auto lun scan turned on for our SLES 11 SP4 hosts and it is on
> by default for our SLES 12 SP3 hosts.  We are trying to insert a
> Cirrus device which has the capability to discover LUNs and NPIV WWNs.
> My very limited understanding of the process, during the initial boot
> process (z/VM IPL) it initially will report back no LUNs to the guest,
> logs into the storage device and then reports back to the guest with
> the LUNs that are masked for the NPIV WWPN.

Auto-LUN-Scan in Linux works roughly as follows:
 - in z/VM guests you need dedicated FCP devices that are on CHPIDs with
   NPIV enabled (I assume you have that already). Apart from this z/VM
   does not play any role in this, it doesn't help or intercept
   anything.
 - during boot - when the zFCP driver is loaded, usually by the initial
   RAM-Disk - we (the driver) scan the FC-Network for available remote
   ports (ports that are in the same zone as the initiator ports on
   your) and open them automatically
   - this happens completely transparent, regardless of whether NPIV
 and/or auto-LUN-scan is enabled or not
 - for each successfully opened remote port the Linux Kernel SCSI code
   will issue LUN-scanning. If you have auto-LUN-scan enabled and use a
   NPIV enabled FCP device the zFCP driver will allow the scan to
   happen - otherwise we intercept it.
 - such a scan entails sending of the SCSI Command REPORT LUNS (support
   for this commands is mandatory for every SCSI device type), and for
   all reported devices the Linux kernel will create SCSI-Devices
 - note that "opening" a LUN does not actually generate any traffic in
   the network, only the remote port open and REPORT LUNS does generate
   traffic, and for all found LUNs Linux will also send some
   INQUIRY commands and such, but there is no "open LUN" command as
   such
 - Linux doesn't retry this LUN-scanning later without any reason (port
   recovery or such), so if the network stays quit it doesn't

Now, I have never worked with the devices you want to use, so its
guessing after this.

If I understand you correctly the Cirrus device sits between your
initiator FC-Ports (on the Z side) and the storage-server, somewhere in
the network and intercepts your traffic? So Linux will open the port on
this device and it will see the initial traffic by Linux, and forward it
to whatever storage-server it thinks is correct.

If it does not report back the correct list of LUNs for the initial
REPORT LUNS command, you have a problem (and I'd consider this device
broken). There are some fall-backs in the kernel for cases where the
storage device is buggy and/or doesn't properly support modern SCSI
standards, but that doesn't mean it'll help you.

> This does not seem to give the SLES 12 guests issues but most of the
> SLES 11 guests have issues.  Is there anyway for the guest to do a
> retry, otherwise it ends up in emergency repair mode (setting we have
> in fstab).

Its hard to give you proper advice without knowing in what state the
system halts, and what exactly happend during the whole process I
described above.

But in the absence of this:

Like Mark said, it might help to just trigger a scan manually with the
script rescan-scsi-bus.sh, or you could just try writing into the scan
attribute of the SCSI-Hosts in question (as root):

   +-- Device-Bus-ID of your FCP device
   |
   v
echo "- - -" > /sys/devices/css*/*/0.0.1900/host*/scsi_host/host*/scan

This should issue an other rescan of all the attached remote ports, and
you don't need any extra tools. You might also be able to script that
and put it in your initial ram-disk (although that might be not as easy
as it sounds; you'd have to find a proper trigger and time to issue the
script during the boot-process). I don't know any way to activate
something like this "out-of-the-box" with SLES11 (or 12 for that
matter).


-- 
With Best Regards, Benjamin Block  /  Linux on IBM Z Kernel Development
IBM Systems & Technology Group   /  IBM Deutschland Research & Development GmbH
Vorsitz. AufsR.: Matthias Hartmann   /  Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG 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

Re: Question on auto lun scan

[Alan Altmark]

On Monday, 02/04/2019 at 04:38 GMT, "Will, Chris"  wrote:
> We have auto lun scan turned on for our SLES 11 SP4 hosts and it is on 
by
> default for our SLES 12 SP3 hosts.  We are trying to insert a Cirrus 
device
> which has the capability to discover LUNs and NPIV WWNs.  My very 
limited
> understanding of the process, during the initial boot process (z/VM IPL) 
it
> initially will report back no LUNs to the guest, logs into the storage 
device
> and then reports back to the guest with the LUNs that are masked for the 
NPIV
> WWPN.  This does not seem to give the SLES 12 guests issues but most of 
the
> SLES 11 guests have issues.  Is there anyway for the guest to do a 
retry,
> otherwise it ends up in emergency repair mode (setting we have in 
fstab).

I've never heard of that design, Chris.  z/VM doesn't intercept FCP 
operations by the guest, so CP doesn't report back anything to the guest. 
I believe the physical fabric login occurs when the PCHID comes online, 
and NPIV login (if used) occurs when the guest device driver (or CP, for 
EDEVs) activates the subchannel.  Establishing paths to the target WWPN 
and performing a LUN enumeration is under control of the guest.

Alan Altmark

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


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Question on auto lun scan

[Mark Post]

>>> On 2/4/2019 at 11:37 AM, "Will, Chris"  wrote: 
> We have auto lun scan turned on for our SLES 11 SP4 hosts and it is on by 
> default for our SLES 12 SP3 hosts.  We are trying to insert a Cirrus device 
> which has the capability to discover LUNs and NPIV WWNs.  My very limited 
> understanding of the process, during the initial boot process (z/VM IPL) it 
> initially will report back no LUNs to the guest, logs into the storage device 
> and then reports back to the guest with the LUNs that are masked for the NPIV 

Man, what a horrible hardware design.

> WWPN.  This does not seem to give the SLES 12 guests issues but most of the 
> SLES 11 guests have issues.  Is there anyway for the guest to do a retry, 
> otherwise it ends up in emergency repair mode (setting we have in fstab).

If you have the sg3_utils package installed, and the disks necessary for /usr 
to get mounted are available, you can use the rescan-scsi-bus.sh script.  If 
/usr isn't able to be mounted, then you can try to do manually what the script 
does.


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

Re: question on SWAPGEN preferences

[Alan Ackerman]

I thank you for doing this! Long ago and far away I did report a problem with 
SWAPGEN. I took this up with IBM, since they were providing our Linux (Red Hat) 
support and since they used SWAPGEN in their RedBook. Eventually, IBM 
determined that the problem was not in SWAPGEN but in systemd. They tried to 
convince Red Hat to make some changes, but Red Hat refused. Nevertheless, the 
problem went away when we put on some service, so I didn't pursue it any 
further.


My original post was 
Date: Mon, 16 May 2016 10:28:55 -0700
http://www2.marist.edu:8000/htbin/wlvtype?LINUX-VM.92905


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



On Dec 29, 2018, at 11:29 AM, David Boyes  wrote:

On 12/27/18, 11:16 AM, "Linux on 390 Port on behalf of Rob van der Heij" 
 wrote:

> I don’t see how specifying the size should make a difference, apart from
> the last odd blocks when an arbitrary size does not make a full number of
> cylinders.

Apparently there are still a fair number of people who care about SWAPGEN (who 
knew?) mostly to deal with creating swap on VDISKs, so I'm trying to address 
the stuff I've had queued up on the round tuit list. It's been a few years 
since the last release, so the list is somewhat longer, but I can make educated 
guesses for many of those. 

Reason for the size/units question was to make it friendlier for non-CMS 
literate people who don't (and don’t want to) understand the underlying disk 
geometries and just want to say "give me a 18G swap disk *there*" and have it 
automagically sort out what it needs to do to make that happen -- purely a 
usability issue. I agree that for real 3390/FBA swap disk, setting size in 
SWAPGEN is irrelevant, but creating swap space for that use case is persistent 
across logons, so it's less important to me. 

The BLKSIZE option was requested by someone a while back to try to align it 
with more efficient use of space with larger memory page sizes to try to better 
align the # of I/Os needed to move a complete frame in and out. Future item 
(IIRC, Alan was talking about it as a fairly distant need), but I've got some 
spare time to think about it at the moment. 

Figured I'd ask and see what people want, so there it is. If nobody cares, then 
I won't expend any more effort on it. 




--
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: question on SWAPGEN preferences

[O'Brien, Dennis L]

David,
We use SWAPGEN to initialize virtual disks in storage before Linux IPL's.  It's 
quite a useful tool.  Specifying a size in M or G might be convenient for 
people who issue the command manually or hard-code values in EXEC's.  Our guest 
PROFILE EXEC calculates the size as a percentage of the logon storage size, so 
it will continue to specify an exact number of pages.


Dennis L. O’Brien
Vice President
Consultant II, z/VM Engineering
Technology Engineering & Operations
Bank of America
CA4-704-06-15, 2000 Clayton Rd, Concord, CA 94520
Dennis.L.O’br...@bankofamerica.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David 
Boyes
Sent: Saturday, December 29, 2018 11:29
To: LINUX-390@VM.MARIST.EDU
Subject: Re: question on SWAPGEN preferences

On 12/27/18, 11:16 AM, "Linux on 390 Port on behalf of Rob van der Heij" 
 wrote:

> I don’t see how specifying the size should make a difference, apart from
> the last odd blocks when an arbitrary size does not make a full number of
> cylinders.

Apparently there are still a fair number of people who care about SWAPGEN (who 
knew?) mostly to deal with creating swap on VDISKs, so I'm trying to address 
the stuff I've had queued up on the round tuit list. It's been a few years 
since the last release, so the list is somewhat longer, but I can make educated 
guesses for many of those. 

Reason for the size/units question was to make it friendlier for non-CMS 
literate people who don't (and don’t want to) understand the underlying disk 
geometries and just want to say "give me a 18G swap disk *there*" and have it 
automagically sort out what it needs to do to make that happen -- purely a 
usability issue. I agree that for real 3390/FBA swap disk, setting size in 
SWAPGEN is irrelevant, but creating swap space for that use case is persistent 
across logons, so it's less important to me. 

The BLKSIZE option was requested by someone a while back to try to align it 
with more efficient use of space with larger memory page sizes to try to better 
align the # of I/Os needed to move a complete frame in and out. Future item 
(IIRC, Alan was talking about it as a fairly distant need), but I've got some 
spare time to think about it at the moment. 

Figured I'd ask and see what people want, so there it is. If nobody cares, then 
I won't expend any more effort on it. 




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIGaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=YjdXFsYwJ4HEj6o-pUp8xumQus2UJEtFNhPEIMAdx7b8RVzYjxKSlDO03Niwnd7q&m=YUYcrFcbDD0TgP2pJNqKedGjhWyojxDxl4vhCstkSH8&s=359ZxAI-d3uiB0U-Co4DspBOhhRyOR9Yzt5HfOIXx8A&e=
--
For more information on Linux on System z, visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_&d=DwIGaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=YjdXFsYwJ4HEj6o-pUp8xumQus2UJEtFNhPEIMAdx7b8RVzYjxKSlDO03Niwnd7q&m=YUYcrFcbDD0TgP2pJNqKedGjhWyojxDxl4vhCstkSH8&s=K_nw-qTG5NSJStBclKow2rtXBfex86i8rxGeKzj2hag&e=

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.


--
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: question on SWAPGEN preferences

[David Boyes]

On 12/27/18, 11:16 AM, "Linux on 390 Port on behalf of Rob van der Heij" 
 wrote:

> I don’t see how specifying the size should make a difference, apart from
> the last odd blocks when an arbitrary size does not make a full number of
> cylinders.

Apparently there are still a fair number of people who care about SWAPGEN (who 
knew?) mostly to deal with creating swap on VDISKs, so I'm trying to address 
the stuff I've had queued up on the round tuit list. It's been a few years 
since the last release, so the list is somewhat longer, but I can make educated 
guesses for many of those. 

Reason for the size/units question was to make it friendlier for non-CMS 
literate people who don't (and don’t want to) understand the underlying disk 
geometries and just want to say "give me a 18G swap disk *there*" and have it 
automagically sort out what it needs to do to make that happen -- purely a 
usability issue. I agree that for real 3390/FBA swap disk, setting size in 
SWAPGEN is irrelevant, but creating swap space for that use case is persistent 
across logons, so it's less important to me. 

The BLKSIZE option was requested by someone a while back to try to align it 
with more efficient use of space with larger memory page sizes to try to better 
align the # of I/Os needed to move a complete frame in and out. Future item 
(IIRC, Alan was talking about it as a fairly distant need), but I've got some 
spare time to think about it at the moment. 

Figured I'd ask and see what people want, so there it is. If nobody cares, then 
I won't expend any more effort on it. 




--
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: question on SWAPGEN preferences

[O'Brien, Dennis L]

Instead of requiring UNITS SIZE, you could infer it from the presence of a G or 
an M on the size parameter.



Dennis L. O’Brien
Vice President
Consultant II, z/VM Engineering
Technology Engineering & Operations
Bank of America
CA4-704-06-15, 2000 Clayton Rd, Concord, CA 94520
Dennis.L.O’br...@bankofamerica.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David 
Boyes
Sent: Thursday, December 27, 2018 06:38
To: LINUX-390@VM.MARIST.EDU
Subject: question on SWAPGEN preferences

I'm trying to tackle some of the backlogged nits with SWAPGEN, and wanted to 
get opinions on a couple of changes.



  1.  Right now, the size of the swap disk is specified in # of blocks. Would 
it be valuable to be able to specify this in megabytes/gigabytes and let 
SWAPGEN worry about the geometry issues needed to get that amount of space? For 
backward compatibility, the default would remain # of blocks, but adding a new 
option to interpret the value as meg/gig wouldn’t break anything, eg:

SWAPGEN 300 1048576 would be treated as allocate 1048576 blocks. This would be 
the default.

SWAPGEN 300 8G ( UNITS SIZE would look at the geometry of the storage 
requested, figure out how many blocks would be needed (at the desired block 
size) to get that amount of space, and them do the deed. New option values: 
UNITS SIZE indicates by size, UNITS BLKS to get the # of blocks, default UNITS 
BLKS.

  2.  Add a BLKSIZE option to specify size of blocks (512,1024, 4096) for more 
efficient use of space.  Default would remain 512 (as now).



Thoughts?

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIGaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=YjdXFsYwJ4HEj6o-pUp8xumQus2UJEtFNhPEIMAdx7b8RVzYjxKSlDO03Niwnd7q&m=5wRg5i1dS2QZ_leL04rK_XnHpZ2KzoHjwy63pJVkxIU&s=HKU_oxu7bbYlTdYfYqkjYZZZs2AjNLO16nJvz78z7jk&e=
--
For more information on Linux on System z, visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.linuxvm.org_&d=DwIGaQ&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=YjdXFsYwJ4HEj6o-pUp8xumQus2UJEtFNhPEIMAdx7b8RVzYjxKSlDO03Niwnd7q&m=5wRg5i1dS2QZ_leL04rK_XnHpZ2KzoHjwy63pJVkxIU&s=5yMMT1tE5WHs5KgtIRPobBa-D8d0aD6ZE9OJiyfgV9Y&e=

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.


--
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: question on SWAPGEN preferences

[Rich Smrcina]

For many years SWAPGEN has had an option to reuse a previously defined vdisk. 
That way the directory can control the size of the vdisk, not SWAPGEN.

Rich Smrcina
Sr. Systems Engineer

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


> On Dec 27, 2018, at 10:03 AM, Cohen, Sam  wrote:
> 
> David,
> 
> Personally, I don't use SWAPGEN, I just run makeswap as part of boot.local, 
> rc.local or systemd local routines.  This way, I don't have to worry about 
> changes in V-disk sizes or future changes in swap disk formats.
> 
> Thanks,
> 
> Sam
> (217) 862-9227 (office)
> (602) 327-2134 (cell)
> 
> -Original Message-
> From: Linux on 390 Port  On Behalf Of David Boyes
> Sent: Thursday, December 27, 2018 7:38 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: question on SWAPGEN preferences
> 
> I'm trying to tackle some of the backlogged nits with SWAPGEN, and wanted to 
> get opinions on a couple of changes.
> 
> 
> 
>  1.  Right now, the size of the swap disk is specified in # of blocks. Would 
> it be valuable to be able to specify this in megabytes/gigabytes and let 
> SWAPGEN worry about the geometry issues needed to get that amount of space? 
> For backward compatibility, the default would remain # of blocks, but adding 
> a new option to interpret the value as meg/gig wouldn’t break anything, eg:
> 
> SWAPGEN 300 1048576 would be treated as allocate 1048576 blocks. This would 
> be the default.
> 
> SWAPGEN 300 8G ( UNITS SIZE would look at the geometry of the storage 
> requested, figure out how many blocks would be needed (at the desired block 
> size) to get that amount of space, and them do the deed. New option values: 
> UNITS SIZE indicates by size, UNITS BLKS to get the # of blocks, default 
> UNITS BLKS.
> 
>  2.  Add a BLKSIZE option to specify size of blocks (512,1024, 4096) for more 
> efficient use of space.  Default would remain 512 (as now).
> 
> 
> 
> Thoughts?
> 
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send email 
> to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CSam.Cohen%40LRS.COM%7C20da5b76d9804590dc2908d66c1240a1%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C636815222990736053&sdata=OIsOM6%2FkWyG%2FgWcUDrx8nrwrBvzQEOee0hnSeUtrtQM%3D&reserved=0
> --
> For more information on Linux on System z, visit
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F&data=02%7C01%7CSam.Cohen%40LRS.COM%7C20da5b76d9804590dc2908d66c1240a1%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C636815222990736053&sdata=OghbrnNCE2iANrYwpsWPYfYZOr2nveNxxrTAXBiH85I%3D&reserved=0
> 
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://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: question on SWAPGEN preferences

[Rob van der Heij]

I don’t see how specifying the size should make a difference, apart from
the last odd blocks when an arbitrary size does not make a full number of
cylinders.

If you’re talking VDISK then it seems irrelevant since there’s just a doze
blocks to be written at any size.
With 3390 we can’t really avoid formatting the tracks. You can speed things
up doing multiple tracks in one diag as CMS Pipelines does.

That’s not depending on size. But it's possible formatting floods NVS with
large disks. Marcy reported that PPRC treated various ways of formatting
differently. I don’t recall someone investigated that in detail.

The best trick is to flash copy from a prepared disk. Technically it does
not even have to be an empty one like we did; you may pass security frowns
flashing the disk of the guest. If these are meant not to be used normally,
space efficient flash copy is attractive.

Rob

On Thu, 27 Dec 2018 at 16:43, David Boyes  wrote:

> I'm trying to tackle some of the backlogged nits with SWAPGEN, and wanted
> to get opinions on a couple of changes.
>
>
>
>   1.  Right now, the size of the swap disk is specified in # of blocks.
> Would it be valuable to be able to specify this in megabytes/gigabytes and
> let SWAPGEN worry about the geometry issues needed to get that amount of
> space? For backward compatibility, the default would remain # of blocks,
> but adding a new option to interpret the value as meg/gig wouldn’t break
> anything, eg:
>
> SWAPGEN 300 1048576 would be treated as allocate 1048576 blocks. This
> would be the default.
>
> SWAPGEN 300 8G ( UNITS SIZE would look at the geometry of the storage
> requested, figure out how many blocks would be needed (at the desired block
> size) to get that amount of space, and them do the deed. New option values:
> UNITS SIZE indicates by size, UNITS BLKS to get the # of blocks, default
> UNITS BLKS.
>
>   2.  Add a BLKSIZE option to specify size of blocks (512,1024, 4096) for
> more efficient use of space.  Default would remain 512 (as now).
>
>
>
> Thoughts?
>
> --
> 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: question on SWAPGEN preferences

[Cohen, Sam]

David,

Personally, I don't use SWAPGEN, I just run makeswap as part of boot.local, 
rc.local or systemd local routines.  This way, I don't have to worry about 
changes in V-disk sizes or future changes in swap disk formats.

Thanks,

Sam
(217) 862-9227 (office)
(602) 327-2134 (cell)

-Original Message-
From: Linux on 390 Port  On Behalf Of David Boyes
Sent: Thursday, December 27, 2018 7:38 AM
To: LINUX-390@VM.MARIST.EDU
Subject: question on SWAPGEN preferences

I'm trying to tackle some of the backlogged nits with SWAPGEN, and wanted to 
get opinions on a couple of changes.



  1.  Right now, the size of the swap disk is specified in # of blocks. Would 
it be valuable to be able to specify this in megabytes/gigabytes and let 
SWAPGEN worry about the geometry issues needed to get that amount of space? For 
backward compatibility, the default would remain # of blocks, but adding a new 
option to interpret the value as meg/gig wouldn’t break anything, eg:

SWAPGEN 300 1048576 would be treated as allocate 1048576 blocks. This would be 
the default.

SWAPGEN 300 8G ( UNITS SIZE would look at the geometry of the storage 
requested, figure out how many blocks would be needed (at the desired block 
size) to get that amount of space, and them do the deed. New option values: 
UNITS SIZE indicates by size, UNITS BLKS to get the # of blocks, default UNITS 
BLKS.

  2.  Add a BLKSIZE option to specify size of blocks (512,1024, 4096) for more 
efficient use of space.  Default would remain 512 (as now).



Thoughts?

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7CSam.Cohen%40LRS.COM%7C20da5b76d9804590dc2908d66c1240a1%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C636815222990736053&sdata=OIsOM6%2FkWyG%2FgWcUDrx8nrwrBvzQEOee0hnSeUtrtQM%3D&reserved=0
--
For more information on Linux on System z, visit
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.linuxvm.org%2F&data=02%7C01%7CSam.Cohen%40LRS.COM%7C20da5b76d9804590dc2908d66c1240a1%7C62af9ccc42164ae2a1d306614c59c315%7C0%7C0%7C636815222990736053&sdata=OghbrnNCE2iANrYwpsWPYfYZOr2nveNxxrTAXBiH85I%3D&reserved=0

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on EDEV devides and DIRMAINT

[Alan Altmark]

On Tuesday, 12/08/2015 at 02:46 GMT, Bruce Hayden  
wrote:
> Note that CPFMTXA refers to the blocks on FB-512 disks as "pages" and 
there
> are 8 blocks in a page.  So the reserved area at the start of a FB-512
> volume is 4 pages but 32 blocks.  In EXTENT CONTROL, you'd start at 32, 
not
> 4.
>
> But - EXTENT CONTROL allows a keyword "Start" for the beginning
> allocation.  It translates to 1 for ECKD and 32 for FB-512.  So, just 
code
> your regions as "START END" and you've allocated the entire pack.
>
> Note 1:  DIRMAINT won't allocate minidisk starting below the "Start" 
value
> anyway, so if you would code 0 or 4 (for FBA), no worries.
>
> Note 2:  You'll probably want to create your own device type in the
> :Defaults. section at the end of the file that specifies how many blocks
> your LUNs have.  Otherwise, Dirmaint will default to the very small 
9336.
> For instance, for my 10 GB LUNs on my test system, I have "BIGEDEV
> 20971520" in the defaults section.  (Maybe 10 GB isn't "big" any more..)

Much appreciated, Bruce!  I should have remembered about blocks v. pages. 
(sigh)  And while DIRMAINT may treat '1' as '32', that doesn't help the 
humans learn about the difference between FBA and ECKD.  Code it as 32.

Alan Altmark

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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on EDEV devides and DIRMAINT

[Bruce Hayden]

Note that CPFMTXA refers to the blocks on FB-512 disks as "pages" and there
are 8 blocks in a page.  So the reserved area at the start of a FB-512
volume is 4 pages but 32 blocks.  In EXTENT CONTROL, you'd start at 32, not
4.

But - EXTENT CONTROL allows a keyword "Start" for the beginning
allocation.  It translates to 1 for ECKD and 32 for FB-512.  So, just code
your regions as "START END" and you've allocated the entire pack.

Note 1:  DIRMAINT won't allocate minidisk starting below the "Start" value
anyway, so if you would code 0 or 4 (for FBA), no worries.

Note 2:  You'll probably want to create your own device type in the
:Defaults. section at the end of the file that specifies how many blocks
your LUNs have.  Otherwise, Dirmaint will default to the very small 9336.
For instance, for my 10 GB LUNs on my test system, I have "BIGEDEV
20971520" in the defaults section.  (Maybe 10 GB isn't "big" any more..)

On Tue, Dec 8, 2015 at 9:26 AM, Alan Altmark 
wrote:

>
>
> First, note that EDEVs are limited to 1TB minus 1 page.  (See the notes on
> the MDISK statement in the CP Planning and Admin book.)
>
> Other than that, you treat FBA volumes just like 9336 from a prep
> perspective.  Use CPFMTXA.  CPFMTXA will tell you that 4-END are PERM
> space, so make sure your EXTENT CONTROL is "4 END", not "1 END".
>
> Just like using a VFB-512 mdisk on a 2nd level system.
>
> 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/
>



--
Bruce Hayden
z/VM and Linux on z Systems ATS
IBM, Endicott, NY

--
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: Question on EDEV devides and DIRMAINT

[Alan Altmark]

On Tuesday, 12/08/2015 at 02:13 GMT, "Will, Chris"  
wrote:
> I have been investigating using EDEV devices (EMC SAN) for Linux guest
> deployment.  What I would like to do is request say a 1TB LUN, assign it 
to
> z/VM in a DIRMAINT pool, and then deploy 40G of space to the guests.  I 
see how
> to create EDEV devices and I see a few examples of 9336 type devices in 
the
> extent control file but no examples of how we get from an EDEV device 
("4000")
> to a 6 character label in the extent control file.  I would assume this 
would
> use cpfmtxa but not sure how to go about this.

First, note that EDEVs are limited to 1TB minus 1 page.  (See the notes on 
the MDISK statement in the CP Planning and Admin book.)

Other than that, you treat FBA volumes just like 9336 from a prep 
perspective.  Use CPFMTXA.  CPFMTXA will tell you that 4-END are PERM 
space, so make sure your EXTENT CONTROL is "4 END", not "1 END".

Just like using a VFB-512 mdisk on a 2nd level system.

Alan Altmark

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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Chu, Raymond]

Mike,

As soon as I changed from 

USER LNXMAINT LXPSEGLI 64M 128M G 
 INCLUDE TCPCMSU  
 LINK TCPMAINT 592 592 RR 
 MDISK 0191 3390 0001 0020  VM1090 MR READ WRITE MULTIPLE 
 MDISK 0192 3390 0021 0500  VM1090 MR ALL  WRITE MULTIPLE 

To 

USER LNXMAINT LXPSEGLI 64M 128M G 
 INCLUDE TCPCMSU  
 LINK TCPMAINT 592 592 RR 
 MDISK 0191 3390 0001 0020  VM1090 MR PASSWORD PASSWORD PASSWORD 
 MDISK 0192 3390 0021 0500  VM1090 MR PASSWORD PASSWORD PASSWORD  

* 

It works.

Ray


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
MacIsaac
Sent: Friday, December 12, 2014 6:44 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

Email sent from outside of PSEG. Use caution before using links/attachments.


Ray,

When I wrote:
> Yes, each Linux system will need its own disk.
Sorry, I meant that for LNXADMIN (the sysadmin's Linux on each member LPAR), 
not LNXMAINT (the CMS machine designed for a common 191 disk on all Linux 
virtual machines).

If you make LNXMAINT an IDENTITY, you will have to maintain four common disks, 
not just one.  Why make things more complex?

I would recommend going back to the original USER directory entry.  If you are 
getting an error on the other members, post the error message(s) here and we'll 
figure it out.

-Mike

On Thu, Dec 11, 2014 at 3:37 PM, Chu, Raymond  wrote:
>
> Mike,
>
> This is how I modified the user direct file and it worked but I would 
> like your assistance to confirm what and how to make it better.
>
> Step 1 - modified the LNXMAINT from
>
> USER LNXMAINT PASSWORD 64M 128M G
>  INCLUDE TCPCMSU
>  LINK TCPMAINT 592 592 RR
>  MDISK 0191 3390 0001 0020  VM1090 MR READ WRITE MULTIPLE  MDISK 0192 
> 3390 0021 0500  VM1090 MR ALL  WRITE MULTIPLE
>
>
> To
>
> IDENTITY LNXMAINT PASSWORD 64M 128M G
>   INCLUDE TCPCMSU
>   BUILD ON NAVY USING SUBCONFIG LNXMNT-1
>   BUILD ON AIRFORCE USING SUBCONFIG LNXMNT-2
>   BUILD ON ARMY USING SUBCONFIG LNXMNT-3
>   BUILD ON MARINES  USING SUBCONFIG LNXMNT-4
>   SUBCONFIG LNXMNT-1
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1090 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1090 MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-2
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1526 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1526 MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-3
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM149F MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM149F MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-4
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1528 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1528 MR PASSWORD PASSWORD  PASSWORD
> *
> Step 2 - Shutdown the LNXADMIN (Linux image) with halt command Step 3 
> - Make sure LNXADMIN be logged off from the current LPAR let's day
> zVM3
> Step 4 - Logon to zVM2 LPAR as LNXADMIN and start up the Linux image 
> Step 5 - Logon to the LNXADMIN in Linux and run the famous "clone" script.
> It picks the expected specified range of macprefix.
>
> It works.
>
> Here is the question. It seems the LNXADMIN and RH65GOLD are only be 
> picked up from the first zVM1 (DISK VM10901) and other disks (VM1526, 
> VM149F and VM1528) are not used at all.  I would like to save some 
> DASDs and use them for something else. It there a way to work around them.
>
> Thanks,
>
> Ray
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Michael MacIsaac
> Sent: Thursday, December 11, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3
>
> Email sent from outside of PSEG. Use caution before using 
> links/attachments.
>
>
> Ray,
>
> > But I am unable to use zVM2, zVM3 and zVM4 to do any cloning at all.
> What error are you getting?
>
> The golden image is a USER, not an IDENTITY, right?  If the minidisk
> volume(s) of the golden image are available to all member systems, 
> then you should be OK.
>
> -Mike
>
> On Thu, Dec 11, 2014 at 12:14 PM, Chu, Raymond 
> wrote:
>
> > Mike,
> >
> > I actually have the following set up shown below:
> >
> > IDENTITY LNXADMIN PASSWORD 256M 1G BG  INC

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Michael MacIsaac]

Ray,

When I wrote:
> Yes, each Linux system will need its own disk.
Sorry, I meant that for LNXADMIN (the sysadmin's Linux on each member
LPAR), not LNXMAINT (the CMS machine designed for a common 191 disk on all
Linux virtual machines).

If you make LNXMAINT an IDENTITY, you will have to maintain four common
disks, not just one.  Why make things more complex?

I would recommend going back to the original USER directory entry.  If you
are getting an error on the other members, post the error message(s) here
and we'll figure it out.

-Mike

On Thu, Dec 11, 2014 at 3:37 PM, Chu, Raymond  wrote:
>
> Mike,
>
> This is how I modified the user direct file and it worked but I would like
> your assistance to confirm what and how to make it better.
>
> Step 1 - modified the LNXMAINT from
>
> USER LNXMAINT PASSWORD 64M 128M G
>  INCLUDE TCPCMSU
>  LINK TCPMAINT 592 592 RR
>  MDISK 0191 3390 0001 0020  VM1090 MR READ WRITE MULTIPLE
>  MDISK 0192 3390 0021 0500  VM1090 MR ALL  WRITE MULTIPLE
>
>
> To
>
> IDENTITY LNXMAINT PASSWORD 64M 128M G
>   INCLUDE TCPCMSU
>   BUILD ON NAVY USING SUBCONFIG LNXMNT-1
>   BUILD ON AIRFORCE USING SUBCONFIG LNXMNT-2
>   BUILD ON ARMY USING SUBCONFIG LNXMNT-3
>   BUILD ON MARINES  USING SUBCONFIG LNXMNT-4
>   SUBCONFIG LNXMNT-1
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1090 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1090 MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-2
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1526 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1526 MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-3
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM149F MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM149F MR PASSWORD PASSWORD  PASSWORD
>   SUBCONFIG LNXMNT-4
>   LINK TCPMAINT 592 592 RR
>   MDISK 0191 3390 0001 0020  VM1528 MR PASSWORD PASSWORD  PASSWORD
>   MDISK 0192 3390 0021 0500  VM1528 MR PASSWORD PASSWORD  PASSWORD
> *
> Step 2 - Shutdown the LNXADMIN (Linux image) with halt command
> Step 3 - Make sure LNXADMIN be logged off from the current LPAR let's day
> zVM3
> Step 4 - Logon to zVM2 LPAR as LNXADMIN and start up the Linux image
> Step 5 - Logon to the LNXADMIN in Linux and run the famous "clone" script.
> It picks the expected specified range of macprefix.
>
> It works.
>
> Here is the question. It seems the LNXADMIN and RH65GOLD are only be
> picked up from the first zVM1 (DISK VM10901) and other disks (VM1526,
> VM149F and VM1528) are not used at all.  I would like to save some DASDs
> and use them for something else. It there a way to work around them.
>
> Thanks,
>
> Ray
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Michael MacIsaac
> Sent: Thursday, December 11, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3
>
> Email sent from outside of PSEG. Use caution before using
> links/attachments.
>
>
> Ray,
>
> > But I am unable to use zVM2, zVM3 and zVM4 to do any cloning at all.
> What error are you getting?
>
> The golden image is a USER, not an IDENTITY, right?  If the minidisk
> volume(s) of the golden image are available to all member systems, then
> you should be OK.
>
> -Mike
>
> On Thu, Dec 11, 2014 at 12:14 PM, Chu, Raymond 
> wrote:
>
> > Mike,
> >
> > I actually have the following set up shown below:
> >
> > IDENTITY LNXADMIN PASSWORD 256M 1G BG
> >  INCLUDE LNXDFLT
> >   BUILD ON   zVM1 USING SUBCONFIG LNXADM-1
> >   BUILD ON   zVM2 USING SUBCONFIG LNXADM-2
> >   BUILD ON   zVM3 USING SUBCONFIG LNXADM-3
> >   BUILD ON   zVM4 USING SUBCONFIG LNXADM-4
> >   OPTION LNKNOPAS
> >   SUBCONFIG LNXADM-1
> >MDISK 0100 3390 0001 10016 VM1091 MR PASSWORD PASSWORD PASSWORD
> >MDISK 0101 3390 0521  9496 VM1090 MR PASSWORD PASSWORD PASSWORD
> >   SUBCONFIG LNXADM-2
> >MDISK 0100 3390 0001 10016 VM1525 MR PASSWORD PASSWORD PASSWORD
> >MDISK 0101 3390 0521  9496 VM1526 MR PASSWORD PASSWORD PASSWORD
> > SUBCONFIG LNXADM-3
> >MDISK 0100 3390 0001 10016 VM149E MR PASSWORD PASSWORD PASSWORD
> >MDISK 0101 3390 0521  9496 VM149F MR PASSWORD PASSWORD PASSWORD
> > SUBCONFIG LNXADM-4
> >MDISK 0100 3390 0001 10016 VM1527 MR PASSWORD PASSWORD PASSWORD
> >MDISK 0101 3390 0521  9496 VM1528 MR PASSWORD PASSWORD PASSWORD
> >
> > It works great to use the zVM1 to do cloning and I can create zLinux z
> > Images from the zVM

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Chu, Raymond]

Mike,

This is how I modified the user direct file and it worked but I would like your 
assistance to confirm what and how to make it better.

Step 1 - modified the LNXMAINT from 

USER LNXMAINT PASSWORD 64M 128M G  
 INCLUDE TCPCMSU   
 LINK TCPMAINT 592 592 RR  
 MDISK 0191 3390 0001 0020  VM1090 MR READ WRITE MULTIPLE  
 MDISK 0192 3390 0021 0500  VM1090 MR ALL  WRITE MULTIPLE  


To 

IDENTITY LNXMAINT PASSWORD 64M 128M G  
  INCLUDE TCPCMSU   
  BUILD ON NAVY USING SUBCONFIG LNXMNT-1
  BUILD ON AIRFORCE USING SUBCONFIG LNXMNT-2
  BUILD ON ARMY USING SUBCONFIG LNXMNT-3
  BUILD ON MARINES  USING SUBCONFIG LNXMNT-4
  SUBCONFIG LNXMNT-1
  LINK TCPMAINT 592 592 RR  
  MDISK 0191 3390 0001 0020  VM1090 MR PASSWORD PASSWORD  PASSWORD
  MDISK 0192 3390 0021 0500  VM1090 MR PASSWORD PASSWORD  PASSWORD  
  SUBCONFIG LNXMNT-2
  LINK TCPMAINT 592 592 RR  
  MDISK 0191 3390 0001 0020  VM1526 MR PASSWORD PASSWORD  PASSWORD  
  MDISK 0192 3390 0021 0500  VM1526 MR PASSWORD PASSWORD  PASSWORD  
  SUBCONFIG LNXMNT-3
  LINK TCPMAINT 592 592 RR  
  MDISK 0191 3390 0001 0020  VM149F MR PASSWORD PASSWORD  PASSWORD  
  MDISK 0192 3390 0021 0500  VM149F MR PASSWORD PASSWORD  PASSWORD  
  SUBCONFIG LNXMNT-4
  LINK TCPMAINT 592 592 RR  
  MDISK 0191 3390 0001 0020  VM1528 MR PASSWORD PASSWORD  PASSWORD  
  MDISK 0192 3390 0021 0500  VM1528 MR PASSWORD PASSWORD  PASSWORD  
*   
Step 2 - Shutdown the LNXADMIN (Linux image) with halt command
Step 3 - Make sure LNXADMIN be logged off from the current LPAR let's day zVM3
Step 4 - Logon to zVM2 LPAR as LNXADMIN and start up the Linux image
Step 5 - Logon to the LNXADMIN in Linux and run the famous "clone" script. It 
picks the expected specified range of macprefix.

It works.

Here is the question. It seems the LNXADMIN and RH65GOLD are only be picked up 
from the first zVM1 (DISK VM10901) and other disks (VM1526, VM149F and VM1528) 
are not used at all.  I would like to save some DASDs and use them for 
something else. It there a way to work around them.

Thanks,

Ray


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
MacIsaac
Sent: Thursday, December 11, 2014 2:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

Email sent from outside of PSEG. Use caution before using links/attachments.


Ray,

> But I am unable to use zVM2, zVM3 and zVM4 to do any cloning at all.
What error are you getting?

The golden image is a USER, not an IDENTITY, right?  If the minidisk
volume(s) of the golden image are available to all member systems, then you 
should be OK.

-Mike

On Thu, Dec 11, 2014 at 12:14 PM, Chu, Raymond  wrote:

> Mike,
>
> I actually have the following set up shown below:
>
> IDENTITY LNXADMIN PASSWORD 256M 1G BG
>  INCLUDE LNXDFLT
>   BUILD ON   zVM1 USING SUBCONFIG LNXADM-1
>   BUILD ON   zVM2 USING SUBCONFIG LNXADM-2
>   BUILD ON   zVM3 USING SUBCONFIG LNXADM-3
>   BUILD ON   zVM4 USING SUBCONFIG LNXADM-4
>   OPTION LNKNOPAS
>   SUBCONFIG LNXADM-1
>MDISK 0100 3390 0001 10016 VM1091 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1090 MR PASSWORD PASSWORD PASSWORD
>   SUBCONFIG LNXADM-2
>MDISK 0100 3390 0001 10016 VM1525 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1526 MR PASSWORD PASSWORD PASSWORD 
> SUBCONFIG LNXADM-3
>MDISK 0100 3390 0001 10016 VM149E MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM149F MR PASSWORD PASSWORD PASSWORD 
> SUBCONFIG LNXADM-4
>MDISK 0100 3390 0001 10016 VM1527 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1528 MR PASSWORD PASSWORD PASSWORD
>
> It works great to use the zVM1 to do cloning and I can create zLinux z 
> Images from the zVM1 LPAR.  But I am unable to use zVM2, zVM3 and zVM4 
> to do any cloning at all.
>
> I also cloned MDISK 100 (VM1091) of zVM1 to VM1525, VM149E and VM1527  
> and MDISK 101 (VM1090) of zVM1 to VM1526, VM149F and VM1528. 
> Understood that the MISK 101 started at 521 because 1 to

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Michael MacIsaac]

Ray,

> But I am unable to use zVM2, zVM3 and zVM4 to do any cloning at all.
What error are you getting?

The golden image is a USER, not an IDENTITY, right?  If the minidisk
volume(s) of the golden image are available to all member systems, then you
should be OK.

-Mike

On Thu, Dec 11, 2014 at 12:14 PM, Chu, Raymond  wrote:

> Mike,
>
> I actually have the following set up shown below:
>
> IDENTITY LNXADMIN PASSWORD 256M 1G BG
>  INCLUDE LNXDFLT
>   BUILD ON   zVM1 USING SUBCONFIG LNXADM-1
>   BUILD ON   zVM2 USING SUBCONFIG LNXADM-2
>   BUILD ON   zVM3 USING SUBCONFIG LNXADM-3
>   BUILD ON   zVM4 USING SUBCONFIG LNXADM-4
>   OPTION LNKNOPAS
>   SUBCONFIG LNXADM-1
>MDISK 0100 3390 0001 10016 VM1091 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1090 MR PASSWORD PASSWORD PASSWORD
>   SUBCONFIG LNXADM-2
>MDISK 0100 3390 0001 10016 VM1525 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1526 MR PASSWORD PASSWORD PASSWORD
> SUBCONFIG LNXADM-3
>MDISK 0100 3390 0001 10016 VM149E MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM149F MR PASSWORD PASSWORD PASSWORD
> SUBCONFIG LNXADM-4
>MDISK 0100 3390 0001 10016 VM1527 MR PASSWORD PASSWORD PASSWORD
>MDISK 0101 3390 0521  9496 VM1528 MR PASSWORD PASSWORD PASSWORD
>
> It works great to use the zVM1 to do cloning and I can create zLinux z
> Images from the zVM1 LPAR.  But I am unable to use zVM2, zVM3 and zVM4 to
> do any cloning at all.
>
> I also cloned MDISK 100 (VM1091) of zVM1 to VM1525, VM149E and VM1527  and
> MDISK 101 (VM1090) of zVM1 to VM1526, VM149F and VM1528. Understood that
> the MISK 101 started at 521 because 1 to 520 were used by LNXMAINT for two
> virtual mode A and D for SWAPGEN, RH65GOLD and LNXADMIN parameters and
> configurations and so on.
>
> I have been communicating with IBM Link to figure how to create Linux on
> System z from zVM2, zVM3 and zVM4 and I am kind of out of resource. Since
> you were the Master of the RedBook and you still are.  Could you please
> show and tell me what went wrong?
>
> The reason that I am looking for this particular configuration is because
> I want to configure zLinux images from a particular LPARs to pick up
> particular range of predefined mac prefix.
>
> Thanks,
>
> Ray
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Michael MacIsaac
> Sent: Friday, November 14, 2014 2:43 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3
>
> Email sent from outside of PSEG. Use caution before using
> links/attachments.
>
>
> Ray,
>
> Yes. The idea here is to have one administrative Linux per LPAR (SSI
> member).  With an IDENTITY, all four can/should be running at the same time.
>
> We had 100 and 101 minidisks in an earlier Cookbook so as to have two
> 3390-3s. In the current cookbook we split a 3390-9 in half which may not
> make the most sense, but it still works. If you have the disk space, you
> might want to make both 100 and 101 full mod-9s to leave a little more room
> for growth.
>
> -Mike
>
> On Fri, Nov 14, 2014 at 1:28 PM, Chu, Raymond 
> wrote:
>
> > Hi,
> >
> > I have already configured a z/VM SSI cluster with 4 LPARs. When I
> > revisited the Cookbook at Section 2.8.5 z/VM DASD used in this book.
> > Table 2-8, I can see DASD are reserved for LNXMAINT(191-192), LNXADMIN
> > (101), LNXADMIN (100) for member 1 LNXADMIN (100) and LNXADMIN (100)
> > for member 2
> >
> > Our system has 4 z/VM LPARs.  Should I also reserve DASDs
> > LNXADMIN(100) and (101) for member 3 and 4 ? They should have the same
> > setting as the member? Please advise.
> >
> > Thanks,
> > Ray
> >
> >
> >
> > -
> >
> > The information contained in this e-mail, including any attachment(s),
> > is intended solely for use by the named addressee(s).  If you are not
> > the intended recipient, or a person designated as responsible for
> > delivering such messages to the intended recipient, you are not
> > authorized to disclose, copy, distribute or retain this message, in
> > whole or in part, without written authorization from PSEG.  This
> > e-mail may contain proprietary, confidential or privileged
> > information. If you have received this message in error, please notify
> > the sender immediately. This notice is included in all e-mail messages
> > leaving PSEG.  Thank you for your cooperation.
> >
> > --

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Michael MacIsaac]

Ray,

Yes, each Linux system will need its own disk.

-Mike

On Fri, Nov 14, 2014 at 1:28 PM, Chu, Raymond  wrote:

> Hi,
>
> I have already configured a z/VM SSI cluster with 4 LPARs. When I
> revisited the Cookbook at Section 2.8.5 z/VM DASD used in this book. Table
> 2-8, I can see DASD are reserved for
> LNXMAINT(191-192), LNXADMIN (101), LNXADMIN (100) for member 1
> LNXADMIN (100) and LNXADMIN (100) for member 2
>
> Our system has 4 z/VM LPARs.  Should I also reserve DASDs LNXADMIN(100)
> and (101) for member 3 and 4 ? They should have the same setting as the
> member? Please advise.
>
> Thanks,
> Ray
>
>
>
> -
>
> The information contained in this e-mail, including any attachment(s), is
> intended solely for use by the named addressee(s).  If you are not the
> intended recipient, or a person designated as responsible for delivering
> such messages to the intended recipient, you are not authorized to
> disclose, copy, distribute or retain this message, in whole or in part,
> without written authorization from PSEG.  This e-mail may contain
> proprietary, confidential or privileged information. If you have received
> this message in error, please notify the sender immediately. This notice is
> included in all e-mail messages leaving PSEG.  Thank you for your
> cooperation.
>
> --
> 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: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Chu, Raymond]

Mike,

I actually have the following set up shown below:

IDENTITY LNXADMIN PASSWORD 256M 1G BG   
 INCLUDE LNXDFLT
  BUILD ON   zVM1 USING SUBCONFIG LNXADM-1  
  
  BUILD ON   zVM2 USING SUBCONFIG LNXADM-2  
  
  BUILD ON   zVM3 USING SUBCONFIG LNXADM-3  
  
  BUILD ON   zVM4 USING SUBCONFIG LNXADM-4  
  
  OPTION LNKNOPAS   
  SUBCONFIG LNXADM-1
   MDISK 0100 3390 0001 10016 VM1091 MR PASSWORD PASSWORD PASSWORD  
   MDISK 0101 3390 0521  9496 VM1090 MR PASSWORD PASSWORD PASSWORD  
  SUBCONFIG LNXADM-2
   MDISK 0100 3390 0001 10016 VM1525 MR PASSWORD PASSWORD PASSWORD  
   MDISK 0101 3390 0521  9496 VM1526 MR PASSWORD PASSWORD PASSWORD  
SUBCONFIG LNXADM-3 
   MDISK 0100 3390 0001 10016 VM149E MR PASSWORD PASSWORD PASSWORD  
   MDISK 0101 3390 0521  9496 VM149F MR PASSWORD PASSWORD PASSWORD  
SUBCONFIG LNXADM-4
   MDISK 0100 3390 0001 10016 VM1527 MR PASSWORD PASSWORD PASSWORD  
   MDISK 0101 3390 0521  9496 VM1528 MR PASSWORD PASSWORD PASSWORD  

It works great to use the zVM1 to do cloning and I can create zLinux z Images 
from the zVM1 LPAR.  But I am unable to use zVM2, zVM3 and zVM4 to do any 
cloning at all.

I also cloned MDISK 100 (VM1091) of zVM1 to VM1525, VM149E and VM1527  and 
MDISK 101 (VM1090) of zVM1 to VM1526, VM149F and VM1528. Understood that the 
MISK 101 started at 521 because 1 to 520 were used by LNXMAINT for two virtual 
mode A and D for SWAPGEN, RH65GOLD and LNXADMIN parameters and configurations 
and so on.

I have been communicating with IBM Link to figure how to create Linux on System 
z from zVM2, zVM3 and zVM4 and I am kind of out of resource. Since you were the 
Master of the RedBook and you still are.  Could you please show and tell me 
what went wrong?

The reason that I am looking for this particular configuration is because I 
want to configure zLinux images from a particular LPARs to pick up particular 
range of predefined mac prefix.

Thanks,

Ray

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
MacIsaac
Sent: Friday, November 14, 2014 2:43 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

Email sent from outside of PSEG. Use caution before using links/attachments.


Ray,

Yes. The idea here is to have one administrative Linux per LPAR (SSI member).  
With an IDENTITY, all four can/should be running at the same time.

We had 100 and 101 minidisks in an earlier Cookbook so as to have two 3390-3s. 
In the current cookbook we split a 3390-9 in half which may not make the most 
sense, but it still works. If you have the disk space, you might want to make 
both 100 and 101 full mod-9s to leave a little more room for growth.

-Mike

On Fri, Nov 14, 2014 at 1:28 PM, Chu, Raymond  wrote:

> Hi,
>
> I have already configured a z/VM SSI cluster with 4 LPARs. When I 
> revisited the Cookbook at Section 2.8.5 z/VM DASD used in this book. 
> Table 2-8, I can see DASD are reserved for LNXMAINT(191-192), LNXADMIN 
> (101), LNXADMIN (100) for member 1 LNXADMIN (100) and LNXADMIN (100) 
> for member 2
>
> Our system has 4 z/VM LPARs.  Should I also reserve DASDs 
> LNXADMIN(100) and (101) for member 3 and 4 ? They should have the same 
> setting as the member? Please advise.
>
> Thanks,
> Ray
>
>
>
> -
>
> The information contained in this e-mail, including any attachment(s), 
> is intended solely for use by the named addressee(s).  If you are not 
> the intended recipient, or a person designated as responsible for 
> delivering such messages to the intended recipient, you are not 
> authorized to disclose, copy, distribute or retain this message, in 
> whole or in part, without written authorization from PSEG.  This 
> e-mail may contain proprietary, confidential or privileged 
> information. If you have received this message in error, please notify 
> the sender immediately. This notice is included in all e-mail messages 
> leaving PSEG.  Thank you for your cooperation.
>
> --
> 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
> 

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Chu, Raymond]

I got it. Thanks


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Michael 
MacIsaac
Sent: Friday, November 14, 2014 2:43 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

Email sent from outside of PSEG. Use caution before using links/attachments.


Ray,

Yes. The idea here is to have one administrative Linux per LPAR (SSI member).  
With an IDENTITY, all four can/should be running at the same time.

We had 100 and 101 minidisks in an earlier Cookbook so as to have two 3390-3s. 
In the current cookbook we split a 3390-9 in half which may not make the most 
sense, but it still works. If you have the disk space, you might want to make 
both 100 and 101 full mod-9s to leave a little more room for growth.

-Mike

On Fri, Nov 14, 2014 at 1:28 PM, Chu, Raymond  wrote:

> Hi,
>
> I have already configured a z/VM SSI cluster with 4 LPARs. When I 
> revisited the Cookbook at Section 2.8.5 z/VM DASD used in this book. 
> Table 2-8, I can see DASD are reserved for LNXMAINT(191-192), LNXADMIN 
> (101), LNXADMIN (100) for member 1 LNXADMIN (100) and LNXADMIN (100) 
> for member 2
>
> Our system has 4 z/VM LPARs.  Should I also reserve DASDs 
> LNXADMIN(100) and (101) for member 3 and 4 ? They should have the same 
> setting as the member? Please advise.
>
> Thanks,
> Ray
>
>
>
> -
>
> The information contained in this e-mail, including any attachment(s), 
> is intended solely for use by the named addressee(s).  If you are not 
> the intended recipient, or a person designated as responsible for 
> delivering such messages to the intended recipient, you are not 
> authorized to disclose, copy, distribute or retain this message, in 
> whole or in part, without written authorization from PSEG.  This 
> e-mail may contain proprietary, confidential or privileged 
> information. If you have received this message in error, please notify 
> the sender immediately. This notice is included in all e-mail messages 
> leaving PSEG.  Thank you for your cooperation.
>
> --
> 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 contained in this e-mail, including any attachment(s), is 
intended solely for use by the named addressee(s).  If you are not the intended 
recipient, or a person designated as responsible for delivering such messages 
to the intended recipient, you are not authorized to disclose, copy, distribute 
or retain this message, in whole or in part, without written authorization from 
PSEG.  This e-mail may contain proprietary, confidential or privileged 
information. If you have received this message in error, please notify the 
sender immediately. This notice is included in all e-mail messages leaving 
PSEG.  Thank you for your cooperation.

Re: Question on The Virtualization Cookbook for IVM z/VM V6.3

[Michael MacIsaac]

Ray,

Yes. The idea here is to have one administrative Linux per LPAR (SSI
member).  With an IDENTITY, all four can/should be running at the same time.

We had 100 and 101 minidisks in an earlier Cookbook so as to have two
3390-3s. In the current cookbook we split a 3390-9 in half which may not
make the most sense, but it still works. If you have the disk space, you
might want to make both 100 and 101 full mod-9s to leave a little more room
for growth.

-Mike

On Fri, Nov 14, 2014 at 1:28 PM, Chu, Raymond  wrote:

> Hi,
>
> I have already configured a z/VM SSI cluster with 4 LPARs. When I
> revisited the Cookbook at Section 2.8.5 z/VM DASD used in this book. Table
> 2-8, I can see DASD are reserved for
> LNXMAINT(191-192), LNXADMIN (101), LNXADMIN (100) for member 1
> LNXADMIN (100) and LNXADMIN (100) for member 2
>
> Our system has 4 z/VM LPARs.  Should I also reserve DASDs LNXADMIN(100)
> and (101) for member 3 and 4 ? They should have the same setting as the
> member? Please advise.
>
> Thanks,
> Ray
>
>
>
> -
>
> The information contained in this e-mail, including any attachment(s), is
> intended solely for use by the named addressee(s).  If you are not the
> intended recipient, or a person designated as responsible for delivering
> such messages to the intended recipient, you are not authorized to
> disclose, copy, distribute or retain this message, in whole or in part,
> without written authorization from PSEG.  This e-mail may contain
> proprietary, confidential or privileged information. If you have received
> this message in error, please notify the sender immediately. This notice is
> included in all e-mail messages leaving PSEG.  Thank you for your
> cooperation.
>
> --
> 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: Question about going from z/VM 5.4 to z/VM 6.3

[Mauro Souza]

We upgraded from 6.1 single to 6.3 SSI a few months ago. We created a
(currently one member) second-level cluster, imported and tweaked all
configuration from the 6.1 image. After checking and rechecking everything,
we shut down the 6.1 image and loaded the 6.3 image. Everything worked out
of the box.

We are now planning to do the same again, but now we will create a second
level multi-member SSI, migrate config and load.

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


2014-08-06 13:03 GMT-03:00 Berthold Gunreben :

> On Tue, 5 Aug 2014 17:42:08 +
> "Feller, Paul"  wrote:
>
> > We have a configuration of three VM lpars running 5.4.  We share RACF
> > and DIRMAINT across all three lpars.  This is a Linux only
> > environment under VM.  We have started the planning of converting to
> > 6.3.  In talking with some people from IBM we have determined that we
> > should not try to share DIRMAINT between the 5.4 systems and 6.3
> > systems.  We are thinking about SSI and what it could do for us.  We
> > are looking at how do we migrate to 6.3.
> >
> > One option that came up was a big bang approach.  The idea being we
> > create a three system SSI cluster 2nd level and test as much as we
> > can.  Even if we didn't do SSI we would still create all three new
> > systems 2nd level so we could test the RACF and DIRMAINT sharing.
> > Then on some weekend during our maintenance window we would bring
> > down the three 5.4 systems and startup the new 6.3 systems 1st
> > level.  Do as much testing as we can and if nothing breaks move
> > forward.
> >
> > Has anyone tried to do this type of migration to 6.3?  Have our
> > wheels come off the train for even thinking about doing the migration
> > this way?
>
> Although going the "big bang" approach, I believe that it would be
> smarter to accomplish a one-by-one approach. This obviously depends on
> how much main storage you have available.
>
> There is a number of changes when doing the migration. For me, the most
> "interesting" part was configuring the FCTC connections in IOCDS.
> Considering that you already use RACF and DIRMAINT, the new setup will
> likely be way easier to handle than the three z/VM LPARs you got now.
>
> So, depending on your environment:
> 1. If you got enough main storage, you probably should create three
> z/VM 6.3 LPARs with SSI enabled and migrate all the guests.
>
> 2. If you do not have enough main storage, you might want to create
> just one LPAR with 6.3 and SSI enabled. Note, that you do not need
> expanded storage for 6.3 (and its actually deprecated). You can then
> do all needed tests and afterwards migrate the guests one by one. For
> this, just define them on 6.3, and after shutting them down on 5.4 its
> only an IPL on 6.3. Do this until one of the 5.4 LPARs is migrated. This
> gives you the needed storage to add a second 6.3 node instead of the
> 5.4 z/VM...
>
> 3. If you do not have any spare main memory, you probably should use
> the maintenance window to do some resizing of the existing VMs to be
> able to create a new LPAR.
>
> Note, that one way of setting up a 6.3 z/VM with SSI, RACF and DIRMAINT
> enabled is described in "The Virtualization Cookbook for IBM z/VM 6.3,
> RHEL 6.4, and SLES 11 SP3"
> http://www.redbooks.ibm.com/abstracts/sg248147.html
>
> Berthold
>
> --
> --
>  Berthold Gunreben  Build Service Team
>  http://www.suse.de/ Maxfeldstr. 5
>  SUSE LINUX Products GmbH   D-90409 Nuernberg, Germany
>  GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
>  HRB 16746 (AG Nürnberg)
>
> --
> 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: Question about going from z/VM 5.4 to z/VM 6.3

[Berthold Gunreben]

On Tue, 5 Aug 2014 17:42:08 +
"Feller, Paul"  wrote:

> We have a configuration of three VM lpars running 5.4.  We share RACF
> and DIRMAINT across all three lpars.  This is a Linux only
> environment under VM.  We have started the planning of converting to
> 6.3.  In talking with some people from IBM we have determined that we
> should not try to share DIRMAINT between the 5.4 systems and 6.3
> systems.  We are thinking about SSI and what it could do for us.  We
> are looking at how do we migrate to 6.3.
> 
> One option that came up was a big bang approach.  The idea being we
> create a three system SSI cluster 2nd level and test as much as we
> can.  Even if we didn't do SSI we would still create all three new
> systems 2nd level so we could test the RACF and DIRMAINT sharing.
> Then on some weekend during our maintenance window we would bring
> down the three 5.4 systems and startup the new 6.3 systems 1st
> level.  Do as much testing as we can and if nothing breaks move
> forward.
> 
> Has anyone tried to do this type of migration to 6.3?  Have our
> wheels come off the train for even thinking about doing the migration
> this way?

Although going the "big bang" approach, I believe that it would be
smarter to accomplish a one-by-one approach. This obviously depends on
how much main storage you have available.

There is a number of changes when doing the migration. For me, the most
"interesting" part was configuring the FCTC connections in IOCDS.
Considering that you already use RACF and DIRMAINT, the new setup will
likely be way easier to handle than the three z/VM LPARs you got now.

So, depending on your environment:
1. If you got enough main storage, you probably should create three
z/VM 6.3 LPARs with SSI enabled and migrate all the guests.

2. If you do not have enough main storage, you might want to create
just one LPAR with 6.3 and SSI enabled. Note, that you do not need
expanded storage for 6.3 (and its actually deprecated). You can then
do all needed tests and afterwards migrate the guests one by one. For
this, just define them on 6.3, and after shutting them down on 5.4 its
only an IPL on 6.3. Do this until one of the 5.4 LPARs is migrated. This
gives you the needed storage to add a second 6.3 node instead of the
5.4 z/VM...

3. If you do not have any spare main memory, you probably should use
the maintenance window to do some resizing of the existing VMs to be
able to create a new LPAR.

Note, that one way of setting up a 6.3 z/VM with SSI, RACF and DIRMAINT
enabled is described in "The Virtualization Cookbook for IBM z/VM 6.3,
RHEL 6.4, and SLES 11 SP3"
http://www.redbooks.ibm.com/abstracts/sg248147.html

Berthold

-- 
--
 Berthold Gunreben  Build Service Team
 http://www.suse.de/ Maxfeldstr. 5
 SUSE LINUX Products GmbH   D-90409 Nuernberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
 HRB 16746 (AG Nürnberg)

--
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: Question on WWPN WP

[Raymond Higgs]

Chris,

We've been talking about your migration problem internally.  If you open a
hardware PMH asking for migration assistance, we might be able to help
you.

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 01/13/2014 11:32:42
AM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/13/2014 11:38 AM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> We try to keep the number of NPIV WWPNs at 32 or less per physical
> channel.  Otherwise we get nameserver and login problems.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf
> Of Raymond Higgs
> Sent: Saturday, January 11, 2014 2:16 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Chris,
>
> Yes, there is port zoning, but all of the vendors will recommend
> small zones, and port zoning does not encourage small zones.  When
> setting up zoning, it is the number of virtual ports in it that
> matter.  Port zoning makes it easy to ignore the virtual
> considerations because you are working with physical resources.
> Extra care is needed to avoid making a zone too big, and sometimes
> it only takes an add of 1 port.
>
> Fibre channel has a notification mechanism called state changes.
> Whenever a virtual nport logs in or out of the fabric, all of the
> other virtual ports in the fabric are notified by the fabric
> controller service running on the switch(s).  This can be a very big
> burden on the switch fabric. The switch vendors have recommendations
> about zone sizes which are much smaller than their consoles will let
> a person set up.  For the most part, newer switches will work with
> larger zones so people really need to check for the hardware that they
have.
>
> 600 Luns was mentioned in another email.  If this means 600 NPIV
> subchannels, then 1 giant zone with 600+ members would be too big!
>
> The other Chris said they were using Brocade.  I believe Brocade
> also recommends either port, or WWPN zoning.  So no mixing port and
> WWPN zoning.
>
> The toughest aspect of making zones too big is that it isn't
> apparent right away.  The symptoms do not show up until events like
> fibre pulls, pchid/chpid/switch port vary off/on, guest IPL/
> shutdown, etc happen.
>
> 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 01/10/2014 02:37:10
> PM:
>
> > From: "burgess, christopher" 
> > To: LINUX-390@vm.marist.edu
> > Date: 01/10/2014 04:30 PM
> > Subject: Re: Question on WWPN WP
> > Sent by: Linux on 390 Port 
> >
> > You don't have to zone by WWPN. In the switch you can set up your
> > zones by port number and then make sure the cables are in the right
> ports.
> >
> >  Thanks,
> > Chris Burgess
> > Phone: 1-800-445-2588 x42149
> >1-508-249-2149
> > Fax: 1-508-497-8027
> > Email: christopher.burg...@emc.com
> >
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Raymond Higgs
> > Sent: Friday, January 10, 2014 2:27 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > Chris,
> >
> > I don't agree with that.  My memory is foggy because there are so many

> > storage array vendors and their consoles are all different.  I haven't

> > run across one that doesn't let you enter WWPNs manually.
> > It isn't always easy to find, and might be through a CLI, but it is
> > always there.
> >
> > So, I bet you have 2 options:
> > enter them in some manual way
> > drag and drop with the GUI as you have been advised
> >
> > 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 01/10/2014
> > 12:38:25
> > PM:
> >
> > > From: "Will, Chris" 
> > > To: LINUX-390@vm.marist.edu
> > > Date: 01/10/2014 12:40 PM
> > > Subject: Re: Question on WWPN WP
> > > Sent by: Linux on 390 Port 
> > >
> >

Re: Question on WWPN WP

[Alan Altmark]

On Saturday, 01/11/2014 at 02:17 EST, Raymond Higgs/Poughkeepsie/IBM@IBMUS
wrote:
> The other Chris said they were using Brocade.  I believe Brocade also
> recommends either port, or WWPN zoning.  So no mixing port and WWPN
> zoning.

I believe that Brocade recommends WWPN zoning as Best Practice, leaving
port zoning only for very specific use cases.  (I would say where you're
in an experimental/test environment where you don't know what WWPNs are
expected.)

> The toughest aspect of making zones too big is that it isn't apparent
> right away.  The symptoms do not show up until events like fibre pulls,
> pchid/chpid/switch port vary off/on, guest IPL/shutdown, etc happen.

Error recovery seems to be the worst aspect of FC.  I think SANs
(switches, HBAs) are still a good distance behind the large-scale
virtualization curve.   If you exceed the various real-world
vendor-imposed operational limits, there are typically no problems when
everything comes up in a nice sequence with time delays, but when you plug
something in or power something on, all hell breaks loose.

To be forewarned is to be forearmed.  ;-)

Alan Altmark

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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on WWPN WP

[Will, Chris]

We try to keep the number of NPIV WWPNs at 32 or less per physical channel.  
Otherwise we get nameserver and login problems.

Chris Will
Systems Software
(313) 549-9729
cw...@bcbsm.com


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond 
Higgs
Sent: Saturday, January 11, 2014 2:16 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Chris,

Yes, there is port zoning, but all of the vendors will recommend small zones, 
and port zoning does not encourage small zones.  When setting up zoning, it is 
the number of virtual ports in it that matter.  Port zoning makes it easy to 
ignore the virtual considerations because you are working with physical 
resources.  Extra care is needed to avoid making a zone too big, and sometimes 
it only takes an add of 1 port.

Fibre channel has a notification mechanism called state changes.  Whenever a 
virtual nport logs in or out of the fabric, all of the other virtual ports in 
the fabric are notified by the fabric controller service running on the 
switch(s).  This can be a very big burden on the switch fabric. The switch 
vendors have recommendations about zone sizes which are much smaller than their 
consoles will let a person set up.  For the most part, newer switches will work 
with larger zones so people really need to check for the hardware that they 
have.

600 Luns was mentioned in another email.  If this means 600 NPIV subchannels, 
then 1 giant zone with 600+ members would be too big!

The other Chris said they were using Brocade.  I believe Brocade also 
recommends either port, or WWPN zoning.  So no mixing port and WWPN zoning.

The toughest aspect of making zones too big is that it isn't apparent right 
away.  The symptoms do not show up until events like fibre pulls, 
pchid/chpid/switch port vary off/on, guest IPL/shutdown, etc happen.

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 01/10/2014 02:37:10
PM:

> From: "burgess, christopher" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 04:30 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> You don't have to zone by WWPN. In the switch you can set up your 
> zones by port number and then make sure the cables are in the right
ports.
>
>  Thanks,
> Chris Burgess
> Phone: 1-800-445-2588 x42149
>1-508-249-2149
> Fax: 1-508-497-8027
> Email: christopher.burg...@emc.com
>
>
>
>
>
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Raymond Higgs
> Sent: Friday, January 10, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Chris,
>
> I don't agree with that.  My memory is foggy because there are so many 
> storage array vendors and their consoles are all different.  I haven't 
> run across one that doesn't let you enter WWPNs manually.
> It isn't always easy to find, and might be through a CLI, but it is 
> always there.
>
> So, I bet you have 2 options:
> enter them in some manual way
> drag and drop with the GUI as you have been advised
>
> 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 01/10/2014 
> 12:38:25
> PM:
>
> > From: "Will, Chris" 
> > To: LINUX-390@vm.marist.edu
> > Date: 01/10/2014 12:40 PM
> > Subject: Re: Question on WWPN WP
> > Sent by: Linux on 390 Port 
> >
> > Our issue is that z/VM and the zLinux guests have to be up and the 
> > npiv channel logged in before the new NPIV WWPN can be zoned from 
> > the SAN side.  At least this is my understanding with EMC storage.
> >
> > Chris Will
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf 
> > Of Scott Rohling
> > Sent: Friday, January 10, 2014 12:28 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > I'm not familiar with the WPT tool, but my experience using NPIV 
> > would

> > leave me to believe that the tool simply tells you what you're new 
> > WWPN's will be for the FCP channels, so that you can get zoning, etc 
> > established
> > before migrating to it.I don't believe you'll have to change
> anything
> > on the Linux guests - as the target WWPN's on the fabric won't 
> > change
> > - only the WWPN associated with the virtual device you attach to the 
> > Linu

Re: Question on WWPN WP

[Will, Chris]

Would this work for NPIV?  For example, the WWPN of the physical FCP channel is 
5005076401A26859 and the NPIV WWPN of the subchannel (1605) is 
C05076F47B8003D4.  The assigned LUNs I see from the Linux side are 
 and 0001.

Chris Will
Systems Software
(313) 549-9729
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Offer 
Baruch
Sent: Saturday, January 11, 2014 12:50 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Although i am not a brocade admin this should do the trick...

Create aliases for the hosts HBA's on each switch Example:switch_1> alicreate " 
HOSTNAME01_HBA_0","10:00:00:c9:69:3d:53"
switch_2> alicreate " HOSTNAME01_HBA_1","10:00:00:c9:69:ae:4e"

Create the zones with the new wwpns:
switch_1> zonecreate "Z_HOSTNAME01_A", "HOSTNAME01_HBA_0"
switch_2> zonecreate "Z_HOSTNAME01_B", "HOSTNAME01_HBA_1"

They should be able to add the storage members to the zones same as they do 
today...

Offer Baruch
On Jan 11, 2014 3:20 AM, "Will, Chris"  wrote:

> We are attached to a Brocade switch.  Our z/VM environment is the only 
> one using NPIV.  If you have the Brocade commands that would be great 
> or if someone could point me to the documentation for defining 
> non-existing WWPNs.  I could then forward the information to our SAN admin.
>
> Chris Will
> 
> From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Offer 
> Baruch [offerbar...@gmail.com]
> Sent: Friday, January 10, 2014 4:10 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Hi
>
> I am both the linux and storage admin...
> For the SAN part it is not a problem to pre define zones for non 
> existing WWPNs. Are you using CISCO/BROCADE?
> I can send you the commands if it is CISCO.
> Same for the storage itself... no problem to do it... you just need to 
> make your storage admins to try. Make them contact support if they 
> don't know how to do it.
>
> Another option is to attach all the zfcp devices to a single linux on 
> the new machine before the cut over and just vary them online. This 
> will triger the fabric login and your storage guys can see them in the fabric.
>
> Hope this helps...
> Offer Baruch
> On Jan 10, 2014 9:42 PM, "Will, Chris"  wrote:
>
> > From Raymond's answers, my original thought was to export and then 
> > import the NPIV WWPNs into the EC12 but was told by our hardware 
> > vendor that
> this
> > could not be done since it was not a MES upgrade.  The other option 
> > would be to pre-stage the new NPIV WWPN names but was told by our 
> > SAN admin
> that
> > they had to be online and logged in for him to configure them.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf 
> > Of Raymond Higgs
> > Sent: Friday, January 10, 2014 2:27 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > Chris,
> >
> > I don't agree with that.  My memory is foggy because there are so 
> > many storage array vendors and their consoles are all different.  I 
> > haven't
> run
> > across one that doesn't let you enter WWPNs manually.  It isn't 
> > always
> easy
> > to find, and might be through a CLI, but it is always there.
> >
> > So, I bet you have 2 options:
> > enter them in some manual way
> > drag and drop with the GUI as you have been advised
> >
> > 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 01/10/2014 
> > 12:38:25
> > PM:
> >
> > > From: "Will, Chris" 
> > > To: LINUX-390@vm.marist.edu
> > > Date: 01/10/2014 12:40 PM
> > > Subject: Re: Question on WWPN WP
> > > Sent by: Linux on 390 Port 
> > >
> > > Our issue is that z/VM and the zLinux guests have to be up and the 
> > > npiv channel logged in before the new NPIV WWPN can be zoned from 
> > > the SAN side.  At least this is my understanding with EMC storage.
> > >
> > > Chris Will
> > >
> > > -Original Message-
> > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf 
> > >

Re: Question on WWPN WP

[Raymond Higgs]

Chris,

Yes, there is port zoning, but all of the vendors will recommend small
zones, and port zoning does not encourage small zones.  When setting up
zoning, it is the number of virtual ports in it that matter.  Port zoning
makes it easy to ignore the virtual considerations because you are working
with physical resources.  Extra care is needed to avoid making a zone too
big, and sometimes it only takes an add of 1 port.

Fibre channel has a notification mechanism called state changes.  Whenever
a virtual nport logs in or out of the fabric, all of the other virtual
ports in the fabric are notified by the fabric controller service running
on the switch(s).  This can be a very big burden on the switch fabric. The
switch vendors have recommendations about zone sizes which are much
smaller than their consoles will let a person set up.  For the most part,
newer switches will work with larger zones so people really need to check
for the hardware that they have.

600 Luns was mentioned in another email.  If this means 600 NPIV
subchannels, then 1 giant zone with 600+ members would be too big!

The other Chris said they were using Brocade.  I believe Brocade also
recommends either port, or WWPN zoning.  So no mixing port and WWPN
zoning.

The toughest aspect of making zones too big is that it isn't apparent
right away.  The symptoms do not show up until events like fibre pulls,
pchid/chpid/switch port vary off/on, guest IPL/shutdown, etc happen.

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 01/10/2014 02:37:10
PM:

> From: "burgess, christopher" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 04:30 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> You don't have to zone by WWPN. In the switch you can set up your
> zones by port number and then make sure the cables are in the right
ports.
>
>  Thanks,
> Chris Burgess
> Phone: 1-800-445-2588 x42149
>1-508-249-2149
> Fax: 1-508-497-8027
> Email: christopher.burg...@emc.com
>
>
>
>
>
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf
> Of Raymond Higgs
> Sent: Friday, January 10, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Chris,
>
> I don't agree with that.  My memory is foggy because there are so
> many storage array vendors and their consoles are all different.  I
> haven't run across one that doesn't let you enter WWPNs manually.
> It isn't always easy to find, and might be through a CLI, but it is
> always there.
>
> So, I bet you have 2 options:
> enter them in some manual way
> drag and drop with the GUI as you have been advised
>
> 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 01/10/2014 12:38:25
> PM:
>
> > From: "Will, Chris" 
> > To: LINUX-390@vm.marist.edu
> > Date: 01/10/2014 12:40 PM
> > Subject: Re: Question on WWPN WP
> > Sent by: Linux on 390 Port 
> >
> > Our issue is that z/VM and the zLinux guests have to be up and the
> > npiv channel logged in before the new NPIV WWPN can be zoned from the
> > SAN side.  At least this is my understanding with EMC storage.
> >
> > Chris Will
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Scott Rohling
> > Sent: Friday, January 10, 2014 12:28 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > I'm not familiar with the WPT tool, but my experience using NPIV would

> > leave me to believe that the tool simply tells you what you're new
> > WWPN's will be for the FCP channels, so that you can get zoning, etc
> > established
> > before migrating to it.I don't believe you'll have to change
> anything
> > on the Linux guests - as the target WWPN's on the fabric won't change
> > - only the WWPN associated with the virtual device you attach to the
> > Linux
> > guests will.   So if you know which virtual devices you'll use - they
> can
> > zone things so those new WWPNs have access to same SAN as the old.
> > Then you should be able to come up on the new box without
changinganything.
> > After you migrate - they can remove the old WWPN's from the zoning.
> > That's my understanding, but my experience is mostly on the z/VM side
> > and using EDEV wit

Re: Question on WWPN WP

[Offer Baruch]

Although i am not a brocade admin this should do the trick...

Create aliases for the hosts HBA's on each switch Example:switch_1>
alicreate " HOSTNAME01_HBA_0","10:00:00:c9:69:3d:53"
switch_2> alicreate " HOSTNAME01_HBA_1","10:00:00:c9:69:ae:4e"

Create the zones with the new wwpns:
switch_1> zonecreate "Z_HOSTNAME01_A", "HOSTNAME01_HBA_0"
switch_2> zonecreate "Z_HOSTNAME01_B", "HOSTNAME01_HBA_1"

They should be able to add the storage members to the zones same as they do
today...

Offer Baruch
On Jan 11, 2014 3:20 AM, "Will, Chris"  wrote:

> We are attached to a Brocade switch.  Our z/VM environment is the only one
> using NPIV.  If you have the Brocade commands that would be great or if
> someone could point me to the documentation for defining non-existing
> WWPNs.  I could then forward the information to our SAN admin.
>
> Chris Will
> 
> From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Offer
> Baruch [offerbar...@gmail.com]
> Sent: Friday, January 10, 2014 4:10 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Hi
>
> I am both the linux and storage admin...
> For the SAN part it is not a problem to pre define zones for non existing
> WWPNs. Are you using CISCO/BROCADE?
> I can send you the commands if it is CISCO.
> Same for the storage itself... no problem to do it... you just need to make
> your storage admins to try. Make them contact support if they don't know
> how to do it.
>
> Another option is to attach all the zfcp devices to a single linux on the
> new machine before the cut over and just vary them online. This will triger
> the fabric login and your storage guys can see them in the fabric.
>
> Hope this helps...
> Offer Baruch
> On Jan 10, 2014 9:42 PM, "Will, Chris"  wrote:
>
> > From Raymond's answers, my original thought was to export and then import
> > the NPIV WWPNs into the EC12 but was told by our hardware vendor that
> this
> > could not be done since it was not a MES upgrade.  The other option would
> > be to pre-stage the new NPIV WWPN names but was told by our SAN admin
> that
> > they had to be online and logged in for him to configure them.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Raymond Higgs
> > Sent: Friday, January 10, 2014 2:27 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > Chris,
> >
> > I don't agree with that.  My memory is foggy because there are so many
> > storage array vendors and their consoles are all different.  I haven't
> run
> > across one that doesn't let you enter WWPNs manually.  It isn't always
> easy
> > to find, and might be through a CLI, but it is always there.
> >
> > So, I bet you have 2 options:
> > enter them in some manual way
> > drag and drop with the GUI as you have been advised
> >
> > 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 01/10/2014 12:38:25
> > PM:
> >
> > > From: "Will, Chris" 
> > > To: LINUX-390@vm.marist.edu
> > > Date: 01/10/2014 12:40 PM
> > > Subject: Re: Question on WWPN WP
> > > Sent by: Linux on 390 Port 
> > >
> > > Our issue is that z/VM and the zLinux guests have to be up and the
> > > npiv channel logged in before the new NPIV WWPN can be zoned from the
> > > SAN side.  At least this is my understanding with EMC storage.
> > >
> > > Chris Will
> > >
> > > -Original Message-
> > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > > Scott Rohling
> > > Sent: Friday, January 10, 2014 12:28 PM
> > > To: LINUX-390@VM.MARIST.EDU
> > > Subject: Re: Question on WWPN WP
> > >
> > > I'm not familiar with the WPT tool, but my experience using NPIV would
> > > leave me to believe that the tool simply tells you what you're new
> > > WWPN's will be for the FCP channels, so that you can get zoning, etc
> > > established
> > > before migrating to it.I don't believe you'll have to change
> > anything
> > > o

Re: Question on WWPN WP

[Lee Daniels]

Sent from my mobile device

> On Jan 10, 2014, at 11:47 AM, "Will, Chris"  wrote:
> 
> We are migrating from a Z10 to an EC12 mainframe and have questions about the 
> WPT tool.  Can we use this to import our existing NPIV WWPN definitions from 
> the Z10 to the EC12 so we do not have to reconfigure the SAN definitions?  If 
> not, how does the WWPN prediction tool help if we have to bring the new 
> system and zLinux guests up to do the SAN configuration?  We are using EMC 
> storage with directly attached zfcp LUNs.
> 
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
> 
> 
> 
> The information contained in this communication is highly confidential and is 
> intended solely for the use of the individual(s) to whom this communication 
> is directed. If you are not the intended recipient, you are hereby notified 
> that any viewing, copying, disclosure or distribution of this information is 
> prohibited. Please notify the sender, by electronic mail or telephone, of any 
> unintended receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
> nonprofit corporations and independent licensees of the Blue Cross and Blue 
> Shield Association.
> 
> --
> 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: Question on WWPN WP

[Will, Chris]

We are attached to a Brocade switch.  Our z/VM environment is the only one 
using NPIV.  If you have the Brocade commands that would be great or if someone 
could point me to the documentation for defining non-existing WWPNs.  I could 
then forward the information to our SAN admin.

Chris Will

From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Offer Baruch 
[offerbar...@gmail.com]
Sent: Friday, January 10, 2014 4:10 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Hi

I am both the linux and storage admin...
For the SAN part it is not a problem to pre define zones for non existing
WWPNs. Are you using CISCO/BROCADE?
I can send you the commands if it is CISCO.
Same for the storage itself... no problem to do it... you just need to make
your storage admins to try. Make them contact support if they don't know
how to do it.

Another option is to attach all the zfcp devices to a single linux on the
new machine before the cut over and just vary them online. This will triger
the fabric login and your storage guys can see them in the fabric.

Hope this helps...
Offer Baruch
On Jan 10, 2014 9:42 PM, "Will, Chris"  wrote:

> From Raymond's answers, my original thought was to export and then import
> the NPIV WWPNs into the EC12 but was told by our hardware vendor that this
> could not be done since it was not a MES upgrade.  The other option would
> be to pre-stage the new NPIV WWPN names but was told by our SAN admin that
> they had to be online and logged in for him to configure them.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Raymond Higgs
> Sent: Friday, January 10, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Chris,
>
> I don't agree with that.  My memory is foggy because there are so many
> storage array vendors and their consoles are all different.  I haven't run
> across one that doesn't let you enter WWPNs manually.  It isn't always easy
> to find, and might be through a CLI, but it is always there.
>
> So, I bet you have 2 options:
> enter them in some manual way
> drag and drop with the GUI as you have been advised
>
> 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 01/10/2014 12:38:25
> PM:
>
> > From: "Will, Chris" 
> > To: LINUX-390@vm.marist.edu
> > Date: 01/10/2014 12:40 PM
> > Subject: Re: Question on WWPN WP
> > Sent by: Linux on 390 Port 
> >
> > Our issue is that z/VM and the zLinux guests have to be up and the
> > npiv channel logged in before the new NPIV WWPN can be zoned from the
> > SAN side.  At least this is my understanding with EMC storage.
> >
> > Chris Will
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Scott Rohling
> > Sent: Friday, January 10, 2014 12:28 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > I'm not familiar with the WPT tool, but my experience using NPIV would
> > leave me to believe that the tool simply tells you what you're new
> > WWPN's will be for the FCP channels, so that you can get zoning, etc
> > established
> > before migrating to it.I don't believe you'll have to change
> anything
> > on the Linux guests - as the target WWPN's on the fabric won't change
> > - only the WWPN associated with the virtual device you attach to the
> > Linux
> > guests will.   So if you know which virtual devices you'll use - they
> can
> > zone things so those new WWPNs have access to same SAN as the old.
> > Then you should be able to come up on the new box without changing
> anything.
> > After you migrate - they can remove the old WWPN's from the zoning.
> > That's my understanding, but my experience is mostly on the z/VM side
> > and using EDEV with NPIV WWPN's..  I assume the same concepts apply to
> > Linux guests directly attaching the stuff..
> >
> > Scott Rohling
> >
> >
> >
> >
> > On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
> >
> > > We are migrating from a Z10 to an EC12 mainframe and have questions
> > > about the WPT tool.  Can we use this to import our existing NPIV
> > > WWPN definitions from the Z10 to the EC12 so we do not have to
> > > reconfigure the 

Re: Question on WWPN WP

[burgess, christopher]

You don't have to zone by WWPN. In the switch you can set up your zones by port 
number and then make sure the cables are in the right ports. 

 Thanks,
Chris Burgess
Phone: 1-800-445-2588 x42149
   1-508-249-2149
Fax: 1-508-497-8027
Email: christopher.burg...@emc.com







-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond 
Higgs
Sent: Friday, January 10, 2014 2:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Chris,

I don't agree with that.  My memory is foggy because there are so many storage 
array vendors and their consoles are all different.  I haven't run across one 
that doesn't let you enter WWPNs manually.  It isn't always easy to find, and 
might be through a CLI, but it is always there.

So, I bet you have 2 options:
enter them in some manual way
drag and drop with the GUI as you have been advised

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 01/10/2014 12:38:25
PM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 12:40 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> Our issue is that z/VM and the zLinux guests have to be up and the 
> npiv channel logged in before the new NPIV WWPN can be zoned from the 
> SAN side.  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would 
> leave me to believe that the tool simply tells you what you're new 
> WWPN's will be for the FCP channels, so that you can get zoning, etc 
> established
> before migrating to it.I don't believe you'll have to change
anything
> on the Linux guests - as the target WWPN's on the fabric won't change 
> - only the WWPN associated with the virtual device you attach to the 
> Linux
> guests will.   So if you know which virtual devices you'll use - they
can
> zone things so those new WWPNs have access to same SAN as the old. 
> Then you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side 
> and using EDEV with NPIV WWPN's..  I assume the same concepts apply to 
> Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions 
> > about the WPT tool.  Can we use this to import our existing NPIV 
> > WWPN definitions from the Z10 to the EC12 so we do not have to 
> > reconfigure the SAN definitions?  If not, how does the WWPN 
> > prediction tool help if we have to bring the new system and zLinux 
> > guests up to do the SAN configuration?  We are using EMC storage 
> > with directly attached zfcp
LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly 
> > confidential

> > and is intended solely for the use of the individual(s) to whom this 
> > communication is directed. If you are not the intended recipient, 
> > you are hereby notified that any viewing, copying, disclosure or 
> > distribution of this information is prohibited. Please notify the 
> > sender, by electronic mail or telephone, of any unintended receipt 
> > and

> > delete the original message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of 
> > Michigan are nonprofit corporations and independent licensees of the 
> > Blue Cross

> > and Blue Shield Association.
> >
> > 
> > -- 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 LIN

Re: Question on WWPN WP

[Offer Baruch]

Hi

I am both the linux and storage admin...
For the SAN part it is not a problem to pre define zones for non existing
WWPNs. Are you using CISCO/BROCADE?
I can send you the commands if it is CISCO.
Same for the storage itself... no problem to do it... you just need to make
your storage admins to try. Make them contact support if they don't know
how to do it.

Another option is to attach all the zfcp devices to a single linux on the
new machine before the cut over and just vary them online. This will triger
the fabric login and your storage guys can see them in the fabric.

Hope this helps...
Offer Baruch
On Jan 10, 2014 9:42 PM, "Will, Chris"  wrote:

> From Raymond's answers, my original thought was to export and then import
> the NPIV WWPNs into the EC12 but was told by our hardware vendor that this
> could not be done since it was not a MES upgrade.  The other option would
> be to pre-stage the new NPIV WWPN names but was told by our SAN admin that
> they had to be online and logged in for him to configure them.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Raymond Higgs
> Sent: Friday, January 10, 2014 2:27 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Chris,
>
> I don't agree with that.  My memory is foggy because there are so many
> storage array vendors and their consoles are all different.  I haven't run
> across one that doesn't let you enter WWPNs manually.  It isn't always easy
> to find, and might be through a CLI, but it is always there.
>
> So, I bet you have 2 options:
> enter them in some manual way
> drag and drop with the GUI as you have been advised
>
> 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 01/10/2014 12:38:25
> PM:
>
> > From: "Will, Chris" 
> > To: LINUX-390@vm.marist.edu
> > Date: 01/10/2014 12:40 PM
> > Subject: Re: Question on WWPN WP
> > Sent by: Linux on 390 Port 
> >
> > Our issue is that z/VM and the zLinux guests have to be up and the
> > npiv channel logged in before the new NPIV WWPN can be zoned from the
> > SAN side.  At least this is my understanding with EMC storage.
> >
> > Chris Will
> >
> > -Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Scott Rohling
> > Sent: Friday, January 10, 2014 12:28 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > I'm not familiar with the WPT tool, but my experience using NPIV would
> > leave me to believe that the tool simply tells you what you're new
> > WWPN's will be for the FCP channels, so that you can get zoning, etc
> > established
> > before migrating to it.I don't believe you'll have to change
> anything
> > on the Linux guests - as the target WWPN's on the fabric won't change
> > - only the WWPN associated with the virtual device you attach to the
> > Linux
> > guests will.   So if you know which virtual devices you'll use - they
> can
> > zone things so those new WWPNs have access to same SAN as the old.
> > Then you should be able to come up on the new box without changing
> anything.
> > After you migrate - they can remove the old WWPN's from the zoning.
> > That's my understanding, but my experience is mostly on the z/VM side
> > and using EDEV with NPIV WWPN's..  I assume the same concepts apply to
> > Linux guests directly attaching the stuff..
> >
> > Scott Rohling
> >
> >
> >
> >
> > On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
> >
> > > We are migrating from a Z10 to an EC12 mainframe and have questions
> > > about the WPT tool.  Can we use this to import our existing NPIV
> > > WWPN definitions from the Z10 to the EC12 so we do not have to
> > > reconfigure the SAN definitions?  If not, how does the WWPN
> > > prediction tool help if we have to bring the new system and zLinux
> > > guests up to do the SAN configuration?  We are using EMC storage
> > > with directly attached zfcp
> LUNs.
> > >
> > > Chris Will
> > > Systems Software
> > > (313) 549-9729
> > > cw...@bcbsm.com
> > >
> > >
> > >
> > > The information contained in this communication is highly
> > > con

Re: Question on WWPN WP

[Will, Chris]

From Raymond's answers, my original thought was to export and then import the 
NPIV WWPNs into the EC12 but was told by our hardware vendor that this could 
not be done since it was not a MES upgrade.  The other option would be to 
pre-stage the new NPIV WWPN names but was told by our SAN admin that they had 
to be online and logged in for him to configure them. 

Chris Will
Systems Software
(313) 549-9729
cw...@bcbsm.com

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Raymond 
Higgs
Sent: Friday, January 10, 2014 2:27 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Chris,

I don't agree with that.  My memory is foggy because there are so many storage 
array vendors and their consoles are all different.  I haven't run across one 
that doesn't let you enter WWPNs manually.  It isn't always easy to find, and 
might be through a CLI, but it is always there.

So, I bet you have 2 options:
enter them in some manual way
drag and drop with the GUI as you have been advised

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 01/10/2014 12:38:25
PM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 12:40 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> Our issue is that z/VM and the zLinux guests have to be up and the 
> npiv channel logged in before the new NPIV WWPN can be zoned from the 
> SAN side.  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would 
> leave me to believe that the tool simply tells you what you're new 
> WWPN's will be for the FCP channels, so that you can get zoning, etc 
> established
> before migrating to it.I don't believe you'll have to change
anything
> on the Linux guests - as the target WWPN's on the fabric won't change 
> - only the WWPN associated with the virtual device you attach to the 
> Linux
> guests will.   So if you know which virtual devices you'll use - they
can
> zone things so those new WWPNs have access to same SAN as the old. 
> Then you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side 
> and using EDEV with NPIV WWPN's..  I assume the same concepts apply to 
> Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions 
> > about the WPT tool.  Can we use this to import our existing NPIV 
> > WWPN definitions from the Z10 to the EC12 so we do not have to 
> > reconfigure the SAN definitions?  If not, how does the WWPN 
> > prediction tool help if we have to bring the new system and zLinux 
> > guests up to do the SAN configuration?  We are using EMC storage 
> > with directly attached zfcp
LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly 
> > confidential

> > and is intended solely for the use of the individual(s) to whom this 
> > communication is directed. If you are not the intended recipient, 
> > you are hereby notified that any viewing, copying, disclosure or 
> > distribution of this information is prohibited. Please notify the 
> > sender, by electronic mail or telephone, of any unintended receipt 
> > and

> > delete the original message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of 
> > Michigan are nonprofit corporations and independent licensees of the 
> > Blue Cross

> > and Blue Shield Association.
> >
> > 
> > -- 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, vis

Re: Question on WWPN WP

[Raymond Higgs]

Chris,

There is some merit in that 2nd approach from my last note.  Having
everything logged in, and dragging things around on a GUI eliminates human
error for small numbers of ports.  If you have 600 of them to do, I think
automating it from output from the WWPN tool is better.  Thousands of
mouse movements might take hours.

The other thing to keep in mind with this migration is the change in our
IO drawer.  z10 had 4 port cards.  ec12 primarily has 2 port cards.  Are
you carrying forward the old cards, or getting new Ficon Express 8S cards?
 This difference in port counts usually leads people to making more IOCDS
changes than usual, and makes the migration harder.

Anyway, hopefully we can figure something out, and it isn't as big of a
problem as it seems now.

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 01/10/2014 01:03:37
PM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 01:05 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> So if we can't pre-stage our NPIV definitions, this will
> significantly increase the cutover time from the Z10 to the EC12.
> We have about 60 servers with about 600 LUNs.  With other sites
> having hundreds of guests, I would think there would be a better way
> to do this.  We have done cpu migrations in the past but this is the
> first time z/VM and NPIV have been involved.
>
> Chris Will
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf
> Of Scott Rohling
> Sent: Friday, January 10, 2014 12:51 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> Ah ...  now that you say this I do recall going through the same with
our
> SAN folks as well..  argh.I don't know enough about storage and SAN
> fabrics to know if there is a way to 'prefill' without the channel
> being logged in..  it did not sound like it, but I always wondered.
>
> Sorry -  I guess it doesn't really help you..  as far as I know -
> you cannot make use of any tool to import WWPN's so that they are
> used for NPIV assignments on a new z box.  I'd love to be wrong
> about this though...
>
> Scott Rohling
>
>
> On Fri, Jan 10, 2014 at 9:38 AM, Will, Chris  wrote:
>
> > Our issue is that z/VM and the zLinux guests have to be up and the
> > npiv channel logged in before the new NPIV WWPN can be zoned from
> the SAN side.
> >  At least this is my understanding with EMC storage.
> >
> > Chris Will
> >
> > -----Original Message-
> > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> > Scott Rohling
> > Sent: Friday, January 10, 2014 12:28 PM
> > To: LINUX-390@VM.MARIST.EDU
> > Subject: Re: Question on WWPN WP
> >
> > I'm not familiar with the WPT tool, but my experience using NPIV would

> > leave me to believe that the tool simply tells you what you're new
> > WWPN's will be for the FCP channels, so that you can get zoning,
> etc established
> > before migrating to it.I don't believe you'll have to change
anything
> > on the Linux guests - as the target WWPN's on the fabric won't change
> > - only the WWPN associated with the virtual device you attach to the
Linux
> > guests will.   So if you know which virtual devices you'll use - they
can
> > zone things so those new WWPNs have access to same SAN as the old.
Then
> > you should be able to come up on the new box without changing
anything.
> > After you migrate - they can remove the old WWPN's from the zoning.
> > That's my understanding, but my experience is mostly on the z/VM side
> > and using EDEV with NPIV WWPN's..  I assume the same concepts apply to

> > Linux guests directly attaching the stuff..
> >
> > Scott Rohling
> >
> >
> >
> >
> > On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
> >
> > > We are migrating from a Z10 to an EC12 mainframe and have questions
> > > about the WPT tool.  Can we use this to import our existing NPIV
> > > WWPN definitions from the Z10 to the EC12 so we do not have to
> > > reconfigure the SAN definitions?  If not, how does the WWPN
> > > prediction tool help if we have to bring the new system and zLinux
> > > guests up to do the SAN configuration?  We are using EMC storage
> > > with directly attached zfcp
> > LUNs.
> > >
> > > Chris Will
> > > Systems Software
> > > (313) 549-9729
> > >

Re: Question on WWPN WP

[Raymond Higgs]

Chris,

I don't agree with that.  My memory is foggy because there are so many
storage array vendors and their consoles are all different.  I haven't run
across one that doesn't let you enter WWPNs manually.  It isn't always
easy to find, and might be through a CLI, but it is always there.

So, I bet you have 2 options:
enter them in some manual way
drag and drop with the GUI as you have been advised

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 01/10/2014 12:38:25
PM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 12:40 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> Our issue is that z/VM and the zLinux guests have to be up and the
> npiv channel logged in before the new NPIV WWPN can be zoned from
> the SAN side.  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf
> Of Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV
> would leave me to believe that the tool simply tells you what you're
> new WWPN's will be for the FCP channels, so that you can get zoning,
> etc established
> before migrating to it.I don't believe you'll have to change
anything
> on the Linux guests - as the target WWPN's on the fabric won't
> change - only the WWPN associated with the virtual device you attach
> to the Linux
> guests will.   So if you know which virtual devices you'll use - they
can
> zone things so those new WWPNs have access to same SAN as the old. Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM
> side and using EDEV with NPIV WWPN's..  I assume the same concepts
> apply to Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions
> > about the WPT tool.  Can we use this to import our existing NPIV WWPN
> > definitions from the Z10 to the EC12 so we do not have to reconfigure
> > the SAN definitions?  If not, how does the WWPN prediction tool help
> > if we have to bring the new system and zLinux guests up to do the SAN
> > configuration?  We are using EMC storage with directly attached zfcp
LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly confidential

> > and is intended solely for the use of the individual(s) to whom this
> > communication is directed. If you are not the intended recipient, you
> > are hereby notified that any viewing, copying, disclosure or
> > distribution of this information is prohibited. Please notify the
> > sender, by electronic mail or telephone, of any unintended receipt and

> > delete the original message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> > are nonprofit corporations and independent licensees of the Blue Cross

> > and Blue Shield Association.
> >
> > --
> > 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 contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the inte

Re: Question on WWPN WP

[Raymond Higgs]

Scott,

Right.  The first use of the WWPN Tool was to just have WWPNs before a
brand new machine is IML'ed the first time, but it has accumulate other
migration stuff.  Like the ability to generate the configuration files
that get loaded into HSA as the real tables of WWPNs, and to handle
physical WWPNs.

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 01/10/2014 12:27:57
PM:

> From: Scott Rohling 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 12:29 PM
> Subject: Re: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> I'm not familiar with the WPT tool, but my experience using NPIV would
> leave me to believe that the tool simply tells you what you're new
WWPN's
> will be for the FCP channels, so that you can get zoning, etc
established
> before migrating to it.I don't believe you'll have to change
anything
> on the Linux guests - as the target WWPN's on the fabric won't change -
> only the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they
can
> zone things so those new WWPNs have access to same SAN as the old. Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side
and
> using EDEV with NPIV WWPN's..  I assume the same concepts apply to Linux
> guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions
about
> > the WPT tool.  Can we use this to import our existing NPIV WWPN
definitions
> > from the Z10 to the EC12 so we do not have to reconfigure the SAN
> > definitions?  If not, how does the WWPN prediction tool help if we
have to
> > bring the new system and zLinux guests up to do the SAN configuration?
 We
> > are using EMC storage with directly attached zfcp LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly confidential
and
> > is intended solely for the use of the individual(s) to whom this
> > communication is directed. If you are not the intended recipient, you
are
> > hereby notified that any viewing, copying, disclosure or distribution
of
> > this information is prohibited. Please notify the sender, by
electronic
> > mail or telephone, of any unintended receipt and delete the original
> > message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
are
> > nonprofit corporations and independent licensees of the Blue Cross and
Blue
> > Shield Association.
> >
> > --
> > 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: Question on WWPN WP

[Richard Troth]

> Our issue is that z/VM and the zLinux guests have to be up
> and the npiv channel logged in before the new NPIV WWPN
> can be zoned from the SAN side.

I've heard this before and am not sure it's strictly true.

> At least this is my understanding with EMC storage.

The server side (whether z/VM or zLinux or something else) has to be
"up" and must have initiated a fabric login for convenience tools to
"see" them. Makes sense: they come online, the storage side sees the
traffic, it gets more WWPNs to make note of. Call it discovery mode.

Difficult to believe the storage side truly cannot be pre-populated
with the new WWPNs. More likely it is a hassle, outside the scope of
what your storage guys have done up to now. But it's KIND OF IMPORTANT
that they find and use the pre-pop feature on their end. It's a
question of scalability. (Not just a speed bump for you. They too
would be up all night long zoning and masking LUNs if they can't
script it ahead of time.)

My experience was with EMC and my storage team made it work.
Pre-loading transition WWPNs was outside their day-to-day work, but
System z was far from the only server platform stretching them.

Again, it will probably HELP your storage guys to be able to pre-enter
the new WWPNs. How many are in use now? If just a half dozen, then not
worth the trouble. But some z/VM and zLinux have literally hundreds,
even thousands, of WWPN and LUN pairs to punch.




On Fri, Jan 10, 2014 at 12:38 PM, Will, Chris  wrote:
> Our issue is that z/VM and the zLinux guests have to be up and the npiv 
> channel logged in before the new NPIV WWPN can be zoned from the SAN side.  
> At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
> Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would leave 
> me to believe that the tool simply tells you what you're new WWPN's will be 
> for the FCP channels, so that you can get zoning, etc established
> before migrating to it.I don't believe you'll have to change anything
> on the Linux guests - as the target WWPN's on the fabric won't change - only 
> the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they can
> zone things so those new WWPNs have access to same SAN as the old.   Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side and 
> using EDEV with NPIV WWPN's..  I assume the same concepts apply to Linux 
> guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
>> We are migrating from a Z10 to an EC12 mainframe and have questions
>> about the WPT tool.  Can we use this to import our existing NPIV WWPN
>> definitions from the Z10 to the EC12 so we do not have to reconfigure
>> the SAN definitions?  If not, how does the WWPN prediction tool help
>> if we have to bring the new system and zLinux guests up to do the SAN
>> configuration?  We are using EMC storage with directly attached zfcp LUNs.
>>
>> Chris Will
>> Systems Software
>> (313) 549-9729
>> cw...@bcbsm.com
>>
>>
>>
>> The information contained in this communication is highly confidential
>> and is intended solely for the use of the individual(s) to whom this
>> communication is directed. If you are not the intended recipient, you
>> are hereby notified that any viewing, copying, disclosure or
>> distribution of this information is prohibited. Please notify the
>> sender, by electronic mail or telephone, of any unintended receipt and
>> delete the original message without making any copies.
>>
>>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
>> are nonprofit corporations and independent licensees of the Blue Cross
>> and Blue Shield Association.
>>
>> --
>> 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

Re: Question on WWPN WP

[Raymond Higgs]

Chris,

Have you seen the documentation for the WWPN tool?  It describes some use
cases.

It can be used to transform your z10 configuration into something that can
be imported into ec12, but has limitations.  MES upgrades let you keep the
old IO serial number from the z10.  The IO serial number determines the
first 41 bits of the NPIV WWPNs.

Are you using lun masking on the EMC storage?  I believe it is optional
for them.

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 01/10/2014 11:47:56
AM:

> From: "Will, Chris" 
> To: LINUX-390@vm.marist.edu
> Date: 01/10/2014 11:49 AM
> Subject: Question on WWPN WP
> Sent by: Linux on 390 Port 
>
> We are migrating from a Z10 to an EC12 mainframe and have questions
> about the WPT tool.  Can we use this to import our existing NPIV
> WWPN definitions from the Z10 to the EC12 so we do not have to
> reconfigure the SAN definitions?  If not, how does the WWPN
> prediction tool help if we have to bring the new system and zLinux
> guests up to do the SAN configuration?  We are using EMC storage
> with directly attached zfcp LUNs.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
>
>
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any
> unintended receipt and delete the original message without making any
copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of
> Michigan are nonprofit corporations and independent licensees of the
> Blue Cross and Blue Shield Association.
>
> --
> 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: Question on WWPN WP

[Will, Chris]

Sorry to not be clear.  We are using SAN but not EDEV.  Channels are attached 
using zfcp_host_configure and LUNs are attached using zfcp_disk_configure from 
SLES Linux.

Chris Will

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of burgess, 
christopher
Sent: Friday, January 10, 2014 1:10 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Chris,
I'm not sure why you would be worried about SAN issues if you are using 
direct attach zfcp luns. Direct attach implies no SAN. Do you mean lun masking 
on the storage side?

 Thanks,
Chris Burgess
Phone: 1-800-445-2588 x42149
   1-508-249-2149
Fax: 1-508-497-8027
Email: christopher.burg...@emc.com







-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Will, 
Chris
Sent: Friday, January 10, 2014 1:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

So if we can't pre-stage our NPIV definitions, this will significantly increase 
the cutover time from the Z10 to the EC12.  We have about 60 servers with about 
600 LUNs.  With other sites having hundreds of guests, I would think there 
would be a better way to do this.  We have done cpu migrations in the past but 
this is the first time z/VM and NPIV have been involved.

Chris Will


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
Rohling
Sent: Friday, January 10, 2014 12:51 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Ah ...  now that you say this I do recall going through the same with our
SAN folks as well..  argh.I don't know enough about storage and SAN
fabrics to know if there is a way to 'prefill' without the channel being logged 
in..  it did not sound like it, but I always wondered.

Sorry -  I guess it doesn't really help you..  as far as I know - you cannot 
make use of any tool to import WWPN's so that they are used for NPIV 
assignments on a new z box.  I'd love to be wrong about this though...

Scott Rohling


On Fri, Jan 10, 2014 at 9:38 AM, Will, Chris  wrote:

> Our issue is that z/VM and the zLinux guests have to be up and the 
> npiv channel logged in before the new NPIV WWPN can be zoned from the SAN 
> side.
>  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would 
> leave me to believe that the tool simply tells you what you're new 
> WWPN's will be for the FCP channels, so that you can get zoning, etc 
> established
> before migrating to it.I don't believe you'll have to change anything
> on the Linux guests - as the target WWPN's on the fabric won't change
> - only the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they can
> zone things so those new WWPNs have access to same SAN as the old.   Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side 
> and using EDEV with NPIV WWPN's..  I assume the same concepts apply to 
> Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions 
> > about the WPT tool.  Can we use this to import our existing NPIV 
> > WWPN definitions from the Z10 to the EC12 so we do not have to 
> > reconfigure the SAN definitions?  If not, how does the WWPN 
> > prediction tool help if we have to bring the new system and zLinux 
> > guests up to do the SAN configuration?  We are using EMC storage 
> > with directly attached zfcp
> LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly 
> > confidential and is intended solely for the use of the individual(s) 
> > to whom this communication is directed. If you are not the intended 
> > recipient, you are hereby notified that any viewing, copying, 
> > disclosure or distribution of this information is prohibited. Please 
> > notify the sender, by electronic mail or telephone, of any 
> > unintended receipt and delete the original message without making any 
> >

Re: Question on WWPN WP

[burgess, christopher]

Chris,
I'm not sure why you would be worried about SAN issues if you are using 
direct attach zfcp luns. Direct attach implies no SAN. Do you mean lun masking 
on the storage side?

 Thanks,
Chris Burgess
Phone: 1-800-445-2588 x42149
   1-508-249-2149
Fax: 1-508-497-8027
Email: christopher.burg...@emc.com







-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Will, 
Chris
Sent: Friday, January 10, 2014 1:04 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

So if we can't pre-stage our NPIV definitions, this will significantly increase 
the cutover time from the Z10 to the EC12.  We have about 60 servers with about 
600 LUNs.  With other sites having hundreds of guests, I would think there 
would be a better way to do this.  We have done cpu migrations in the past but 
this is the first time z/VM and NPIV have been involved.

Chris Will


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
Rohling
Sent: Friday, January 10, 2014 12:51 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Ah ...  now that you say this I do recall going through the same with our
SAN folks as well..  argh.I don't know enough about storage and SAN
fabrics to know if there is a way to 'prefill' without the channel being logged 
in..  it did not sound like it, but I always wondered.

Sorry -  I guess it doesn't really help you..  as far as I know - you cannot 
make use of any tool to import WWPN's so that they are used for NPIV 
assignments on a new z box.  I'd love to be wrong about this though...

Scott Rohling


On Fri, Jan 10, 2014 at 9:38 AM, Will, Chris  wrote:

> Our issue is that z/VM and the zLinux guests have to be up and the 
> npiv channel logged in before the new NPIV WWPN can be zoned from the SAN 
> side.
>  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would 
> leave me to believe that the tool simply tells you what you're new 
> WWPN's will be for the FCP channels, so that you can get zoning, etc 
> established
> before migrating to it.I don't believe you'll have to change anything
> on the Linux guests - as the target WWPN's on the fabric won't change
> - only the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they can
> zone things so those new WWPNs have access to same SAN as the old.   Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side 
> and using EDEV with NPIV WWPN's..  I assume the same concepts apply to 
> Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions 
> > about the WPT tool.  Can we use this to import our existing NPIV 
> > WWPN definitions from the Z10 to the EC12 so we do not have to 
> > reconfigure the SAN definitions?  If not, how does the WWPN 
> > prediction tool help if we have to bring the new system and zLinux 
> > guests up to do the SAN configuration?  We are using EMC storage 
> > with directly attached zfcp
> LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly 
> > confidential and is intended solely for the use of the individual(s) 
> > to whom this communication is directed. If you are not the intended 
> > recipient, you are hereby notified that any viewing, copying, 
> > disclosure or distribution of this information is prohibited. Please 
> > notify the sender, by electronic mail or telephone, of any 
> > unintended receipt and delete the original message without making any 
> > copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of 
> > Michigan are nonprofit corporations and independent licensees of the 
> > Blue Cross and Blue Shield Association.
> >
> > 
> > -- For LINUX-390 subscribe / signoff / archive access instructions, 
> > send email to l

Re: Question on WWPN WP

[Mark Post]

>>> On 1/10/2014 at 01:03 PM, "Will, Chris"  wrote: 
> So if we can't pre-stage our NPIV definitions, this will significantly 
> increase the cutover time from the Z10 to the EC12.  We have about 60 servers 
> with about 600 LUNs.  With other sites having hundreds of guests, I would 
> think there would be a better way to do this.  We have done cpu migrations in 
> the past but this is the first time z/VM and NPIV have been involved.
> 
> Chris Will

You would think so, I agree.  Unfortunately, after talking with many people 
over time at places like SHARE, etc., there doesn't seem to be.  Things like 
IBM's SAN Volume Controller seem to make things somewhat easier, but not as 
easy as it should be.  (I don't have any personal experience with the SVC, so I 
could be overly pessimistic here.)  I and several other people see a 
potentially large opportunity for some ISV to provide a SAN/LUN 
discovery/inventory/management tool to make a lot of things easier, including 
CPU migrations.  Considering how hard IBM pushes customers to upgrade to new 
CPUs when they're announced, this is a rather large speed bump to run into.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on WWPN WP

[Will, Chris]

So if we can't pre-stage our NPIV definitions, this will significantly increase 
the cutover time from the Z10 to the EC12.  We have about 60 servers with about 
600 LUNs.  With other sites having hundreds of guests, I would think there 
would be a better way to do this.  We have done cpu migrations in the past but 
this is the first time z/VM and NPIV have been involved.

Chris Will


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
Rohling
Sent: Friday, January 10, 2014 12:51 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

Ah ...  now that you say this I do recall going through the same with our
SAN folks as well..  argh.I don't know enough about storage and SAN
fabrics to know if there is a way to 'prefill' without the channel being logged 
in..  it did not sound like it, but I always wondered.

Sorry -  I guess it doesn't really help you..  as far as I know - you cannot 
make use of any tool to import WWPN's so that they are used for NPIV 
assignments on a new z box.  I'd love to be wrong about this though...

Scott Rohling


On Fri, Jan 10, 2014 at 9:38 AM, Will, Chris  wrote:

> Our issue is that z/VM and the zLinux guests have to be up and the 
> npiv channel logged in before the new NPIV WWPN can be zoned from the SAN 
> side.
>  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would 
> leave me to believe that the tool simply tells you what you're new 
> WWPN's will be for the FCP channels, so that you can get zoning, etc 
> established
> before migrating to it.I don't believe you'll have to change anything
> on the Linux guests - as the target WWPN's on the fabric won't change 
> - only the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they can
> zone things so those new WWPNs have access to same SAN as the old.   Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side 
> and using EDEV with NPIV WWPN's..  I assume the same concepts apply to 
> Linux guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions 
> > about the WPT tool.  Can we use this to import our existing NPIV 
> > WWPN definitions from the Z10 to the EC12 so we do not have to 
> > reconfigure the SAN definitions?  If not, how does the WWPN 
> > prediction tool help if we have to bring the new system and zLinux 
> > guests up to do the SAN configuration?  We are using EMC storage 
> > with directly attached zfcp
> LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly 
> > confidential and is intended solely for the use of the individual(s) 
> > to whom this communication is directed. If you are not the intended 
> > recipient, you are hereby notified that any viewing, copying, 
> > disclosure or distribution of this information is prohibited. Please 
> > notify the sender, by electronic mail or telephone, of any 
> > unintended receipt and delete the original message without making any 
> > copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of 
> > Michigan are nonprofit corporations and independent licensees of the 
> > Blue Cross and Blue Shield Association.
> >
> > 
> > -- 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

Re: Question on WWPN WP

[Scott Rohling]

Ah ...  now that you say this I do recall going through the same with our
SAN folks as well..  argh.I don't know enough about storage and SAN
fabrics to know if there is a way to 'prefill' without the channel being
logged in..  it did not sound like it, but I always wondered.

Sorry -  I guess it doesn't really help you..  as far as I know - you
cannot make use of any tool to import WWPN's so that they are used for NPIV
assignments on a new z box.  I'd love to be wrong about this though...

Scott Rohling


On Fri, Jan 10, 2014 at 9:38 AM, Will, Chris  wrote:

> Our issue is that z/VM and the zLinux guests have to be up and the npiv
> channel logged in before the new NPIV WWPN can be zoned from the SAN side.
>  At least this is my understanding with EMC storage.
>
> Chris Will
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Scott Rohling
> Sent: Friday, January 10, 2014 12:28 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Question on WWPN WP
>
> I'm not familiar with the WPT tool, but my experience using NPIV would
> leave me to believe that the tool simply tells you what you're new WWPN's
> will be for the FCP channels, so that you can get zoning, etc established
> before migrating to it.I don't believe you'll have to change anything
> on the Linux guests - as the target WWPN's on the fabric won't change -
> only the WWPN associated with the virtual device you attach to the Linux
> guests will.   So if you know which virtual devices you'll use - they can
> zone things so those new WWPNs have access to same SAN as the old.   Then
> you should be able to come up on the new box without changing anything.
> After you migrate - they can remove the old WWPN's from the zoning.
> That's my understanding, but my experience is mostly on the z/VM side and
> using EDEV with NPIV WWPN's..  I assume the same concepts apply to Linux
> guests directly attaching the stuff..
>
> Scott Rohling
>
>
>
>
> On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:
>
> > We are migrating from a Z10 to an EC12 mainframe and have questions
> > about the WPT tool.  Can we use this to import our existing NPIV WWPN
> > definitions from the Z10 to the EC12 so we do not have to reconfigure
> > the SAN definitions?  If not, how does the WWPN prediction tool help
> > if we have to bring the new system and zLinux guests up to do the SAN
> > configuration?  We are using EMC storage with directly attached zfcp
> LUNs.
> >
> > Chris Will
> > Systems Software
> > (313) 549-9729
> > cw...@bcbsm.com
> >
> >
> >
> > The information contained in this communication is highly confidential
> > and is intended solely for the use of the individual(s) to whom this
> > communication is directed. If you are not the intended recipient, you
> > are hereby notified that any viewing, copying, disclosure or
> > distribution of this information is prohibited. Please notify the
> > sender, by electronic mail or telephone, of any unintended receipt and
> > delete the original message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> > are nonprofit corporations and independent licensees of the Blue Cross
> > and Blue Shield Association.
> >
> > --
> > 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 contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete

Re: Question on WWPN WP

[Will, Chris]

Our issue is that z/VM and the zLinux guests have to be up and the npiv channel 
logged in before the new NPIV WWPN can be zoned from the SAN side.  At least 
this is my understanding with EMC storage.

Chris Will

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott 
Rohling
Sent: Friday, January 10, 2014 12:28 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question on WWPN WP

I'm not familiar with the WPT tool, but my experience using NPIV would leave me 
to believe that the tool simply tells you what you're new WWPN's will be for 
the FCP channels, so that you can get zoning, etc established
before migrating to it.I don't believe you'll have to change anything
on the Linux guests - as the target WWPN's on the fabric won't change - only 
the WWPN associated with the virtual device you attach to the Linux
guests will.   So if you know which virtual devices you'll use - they can
zone things so those new WWPNs have access to same SAN as the old.   Then
you should be able to come up on the new box without changing anything.
After you migrate - they can remove the old WWPN's from the zoning.
That's my understanding, but my experience is mostly on the z/VM side and using 
EDEV with NPIV WWPN's..  I assume the same concepts apply to Linux guests 
directly attaching the stuff..

Scott Rohling




On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:

> We are migrating from a Z10 to an EC12 mainframe and have questions 
> about the WPT tool.  Can we use this to import our existing NPIV WWPN 
> definitions from the Z10 to the EC12 so we do not have to reconfigure 
> the SAN definitions?  If not, how does the WWPN prediction tool help 
> if we have to bring the new system and zLinux guests up to do the SAN 
> configuration?  We are using EMC storage with directly attached zfcp LUNs.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
>
>
> The information contained in this communication is highly confidential 
> and is intended solely for the use of the individual(s) to whom this 
> communication is directed. If you are not the intended recipient, you 
> are hereby notified that any viewing, copying, disclosure or 
> distribution of this information is prohibited. Please notify the 
> sender, by electronic mail or telephone, of any unintended receipt and 
> delete the original message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan 
> are nonprofit corporations and independent licensees of the Blue Cross 
> and Blue Shield Association.
>
> --
> 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 contained in this communication is highly confidential and is 
intended solely for the use of the individual(s) to whom this communication is 
directed. If you are not the intended recipient, you are hereby notified that 
any viewing, copying, disclosure or distribution of this information is 
prohibited. Please notify the sender, by electronic mail or telephone, of any 
unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are 
nonprofit corporations and independent licensees of the Blue Cross and Blue 
Shield Association.

--
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: Question on WWPN WP

[Scott Rohling]

I'm not familiar with the WPT tool, but my experience using NPIV would
leave me to believe that the tool simply tells you what you're new WWPN's
will be for the FCP channels, so that you can get zoning, etc established
before migrating to it.I don't believe you'll have to change anything
on the Linux guests - as the target WWPN's on the fabric won't change -
only the WWPN associated with the virtual device you attach to the Linux
guests will.   So if you know which virtual devices you'll use - they can
zone things so those new WWPNs have access to same SAN as the old.   Then
you should be able to come up on the new box without changing anything.
After you migrate - they can remove the old WWPN's from the zoning.
That's my understanding, but my experience is mostly on the z/VM side and
using EDEV with NPIV WWPN's..  I assume the same concepts apply to Linux
guests directly attaching the stuff..

Scott Rohling




On Fri, Jan 10, 2014 at 8:47 AM, Will, Chris  wrote:

> We are migrating from a Z10 to an EC12 mainframe and have questions about
> the WPT tool.  Can we use this to import our existing NPIV WWPN definitions
> from the Z10 to the EC12 so we do not have to reconfigure the SAN
> definitions?  If not, how does the WWPN prediction tool help if we have to
> bring the new system and zLinux guests up to do the SAN configuration?  We
> are using EMC storage with directly attached zfcp LUNs.
>
> Chris Will
> Systems Software
> (313) 549-9729
> cw...@bcbsm.com
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
> --
> 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: Question on MongoDB usage under z/VM

[Dan Horák]

Peter Linnell píše v Pá 04. 01. 2013 v 14:11 -0700: 
> >>> David Boyes  1/4/2013 11:07 AM >>> 
> > The MongoDB server (mongod) must run on a little-endian CPU, so if you are
> > using a PPC OS X machine, mongod will not work.
> > So it's not true anymore?
> 
> >Doesn't seem to be if you have the most recent SRPM. They've been doing a 
> >lot of work to remove some of those limitations in recent versions, although 
> >admittedly I haven't >explored all the dark corners of this turkey. 
> 
> I could not find any SRPM's to rebuild, but just tested building the latest 
> stable 2.2.0 version in our own internal build system on s390x and it fails 
> both on SLES11Sp2 and the latest openSUSE Factory which has a much newer GCC. 
> Googling the error, led me to https://jira.mongodb.org/browse/SERVER-1811

yeah, it fails for me too with mongodb-2.2.2 srpm from Rawhide hitting
the classic "not-invented-here" symptom about atomics :-( Why authors
can't just use the gcc or C++ provided ones ...


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/

Re: Question on MongoDB usage under z/VM

[Dan Horák]

David Boyes píše v Pá 04. 01. 2013 v 19:07 +: 
> > The MongoDB server (mongod) must run on a little-endian CPU, so if you are
> > using a PPC OS X machine, mongod will not work.
> > So it's not true anymore?
> 
> Doesn't seem to be if you have the most recent SRPM. They've been doing a lot 
> of work to remove some of those limitations in recent versions, although 
> admittedly I haven't explored all the dark corners of this turkey. 
> 

thanks for the info, and it means I will re-add MongoDB and related
packages back to Fedora/s390x


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/

Re: Question on MongoDB usage under z/VM

[Peter Linnell]

>>> David Boyes  1/4/2013 11:07 AM >>> 
> The MongoDB server (mongod) must run on a little-endian CPU, so if you are
> using a PPC OS X machine, mongod will not work.
> So it's not true anymore?

>Doesn't seem to be if you have the most recent SRPM. They've been doing a lot 
>of work to remove some of those limitations in recent versions, although 
>admittedly I haven't >explored all the dark corners of this turkey. 

I could not find any SRPM's to rebuild, but just tested building the latest 
stable 2.2.0 version in our own internal build system on s390x and it fails 
both on SLES11Sp2 and the latest openSUSE Factory which has a much newer GCC. 
Googling the error, led me to https://jira.mongodb.org/browse/SERVER-1811

>From what I can see, even if it compiles, I'm pretty certain you are going to 
>hit run time errors.

HTH,
Peter




Peter Linnell
SUSE Linux Technical Specialist
Tel: 1-415-308-3037



--
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: Question on MongoDB usage under z/VM

[David Boyes]

> The MongoDB server (mongod) must run on a little-endian CPU, so if you are
> using a PPC OS X machine, mongod will not work.
> So it's not true anymore?

Doesn't seem to be if you have the most recent SRPM. They've been doing a lot 
of work to remove some of those limitations in recent versions, although 
admittedly I haven't explored all the dark corners of this turkey. 

Re: Question on MongoDB usage under z/VM

[Dan Horák]

David Boyes píše v Pá 04. 01. 2013 v 18:08 +: 
> > I've been asked by my management if we can support MongoDB (with SOLR)
> > using RHEL under z/VM.  Has anyone on this list given this a try?  Inquiring
> > minds would like to know what your thoughts are.
> 
> It builds and runs cleanly (there's no s390x RPM AFAIK, but the source RPM 
> builds without problems). 

hmm, from http://www.mongodb.org/downloads

The MongoDB server (mongod) must run on a little-endian CPU, so if you
are using a PPC OS X machine, mongod will not work.

So it's not true anymore?

Dan

> As to whether it's a good idea, I'll leave that to the theologians. It's no 
> better or worse than it is on any other platform, although it (MongoDB) is 
> designed for machines where I/O is expensive and RAM is cheap, which tends to 
> not play nice in a shared environment. Depends on what you need it to do. 
> 
> --
> 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: Question on MongoDB usage under z/VM

[Dan Horák]

David Boyes píše v Pá 04. 01. 2013 v 18:08 +: 
> > I've been asked by my management if we can support MongoDB (with SOLR)
> > using RHEL under z/VM.  Has anyone on this list given this a try?  Inquiring
> > minds would like to know what your thoughts are.
> 
> It builds and runs cleanly (there's no s390x RPM AFAIK, but the source RPM 
> builds without problems). 

really? last time I checked there were some little-endianisms hard-coded
and upstream said they are not interested ... Or am I confusing it with
something else?


Dan

> As to whether it's a good idea, I'll leave that to the theologians. It's no 
> better or worse than it is on any other platform, although it (MongoDB) is 
> designed for machines where I/O is expensive and RAM is cheap, which tends to 
> not play nice in a shared environment. Depends on what you need it to do. 
> 
> --
> 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: Question on MongoDB usage under z/VM

[David Boyes]

> AFAIK MongoDB (the server side) still support only little endian
> architectures, so no luck with s390 (or ppc) unfortunately.

Recent updates have removed most of those restrictions. 

Re: Question on MongoDB usage under z/VM

[David Boyes]

> I've been asked by my management if we can support MongoDB (with SOLR)
> using RHEL under z/VM.  Has anyone on this list given this a try?  Inquiring
> minds would like to know what your thoughts are.

It builds and runs cleanly (there's no s390x RPM AFAIK, but the source RPM 
builds without problems). 

As to whether it's a good idea, I'll leave that to the theologians. It's no 
better or worse than it is on any other platform, although it (MongoDB) is 
designed for machines where I/O is expensive and RAM is cheap, which tends to 
not play nice in a shared environment. Depends on what you need it to do. 

--
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: Question on MongoDB usage under z/VM

[Dan Horák]

Carson, Brad píše v Pá 04. 01. 2013 v 15:42 +: 
> Hello,
> 
> I've been asked by my management if we can support MongoDB (with SOLR) using 
> RHEL under z/VM.  Has anyone on this list given this a try?  Inquiring minds 
> would like to know what your thoughts are.

AFAIK MongoDB (the server side) still support only little endian
architectures, so no luck with s390 (or ppc) unfortunately.


Dan

-- 
Dan Horák, RHCE
Senior Software Engineer, BaseOS

Red Hat Czech s.r.o., Purkyňova 99, 612 45 Brno

--
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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Harold Grovesteen]

The gratuitous ARP updates the switch's Layer-2 forwarding tables based
upon the MAC address.  It says to the switch, forward packets for this
MAC address to this switch port.  The gratuitous ARP will only help in
these situations where the same MAC address is moving.

Normally the ARP cache is only updated when the switch issues an ARP
request, soliciting an ARP response, not whenever an ARP response is
presented.  A gratuitous ARP is an unsolicited ARP response.   Hence,
your case does require the ARP cache to be flushed and relearned (as you
have discovered). This assumes the same IP address is in use in both
scenarios.

Obviously use of the same MAC address will improve the situation, but
there may be reasons why this is not the case for you.  Use of different
IP addresses will also improve the situation.  Again, you may have
reasons for wanting the same IP address.

There are numerous options available depending upon the switch vendor
and model.  Consult with your networking team to see what can be done to
make this more fluid.  Newly emerging and available networking
technology, the LISP standards in particular, are explicitly designed to
address this problem, but are likely overkill for your organization.

Harold Grovesteen

On Fri, 2012-09-21 at 12:55 +0200, Florian Bilek wrote:
> Dear Harold,
>
> The MAC addresses of the VSWITCHs are different. At node A
> 02-F1-00-00-00-04 and at node B 02-F2-00-00-00-03.
>
> BR Florian
>
> On Fri, Sep 21, 2012 at 11:50 AM, Harold Grovesteen
> wrote:
>
> > Does the "same manner as on NODE A" mean the same MAC address?
> >
> > Harold Grovesteen
> >
> > On Thu, 2012-09-20 at 19:13 +0200, Florian Bilek wrote:
> > > Dear all,
> > >
> > > I face a problem with the new VMRELOCATION under z/VM 6.2.
> > > The situation is as follows: One SLES 11 SP1 guest is connected via an
> > > VSWITCH to a CICSO firewall. The vswitch is defined as type layer 2.
> > > The network connection is working.
> > >
> > > When I relocate now the guest to NODE B the SSI cluster where the VSWITCH
> > > is defined in the same manner as on NODE A the connection is not working
> > > because of the arp cache in the firewall. It lasts endlessly till the
> > > firewall flushes the arp cache and reestablish the connection.
> > >
> > > Is there some additional setup or manual intervention required on z/VM in
> > > order to force a clear the arp cache in the firewall or is this a
> > function
> > > z/VM should handle internally? Does somebody had a similar situation?
> > >
> > > Thank you very much in advance.
> > >
> > > --
> > > Best regards
> > >
> > > Florian Bilek
> > >
> > > --
> > > 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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Florian Bilek]

Dear all,

Thank you for all the interest and support. I investigated the problem
together with our network team.
It turned out that there was a configuration mismatch in the VLAN
definitions of the physical switch where the VSWITCH/OSA was connected to.
Due to the fact that we run that DMZ only on our primary node (Node A)
before we had z/VM 6.2, the VSWITCH on the backup site was never used
before. It was patched but not really tested.
The situation was quite strange since we never faced problems with a
relocation of a guest in the internal LAN before. Since in that specific
case there was now a firewall involved I suspected the firewall. Mea culpa.

However we managed the move of the production guest successfully the other
node just in time.

Kind regards,
Florian



On Fri, Sep 21, 2012 at 7:20 PM, Alan Altmark wrote:

> I wasn't paying close enough attention.  APAR VM65104 is not for LGR.  The
> APAR is a roll-back of a subset of the LGR grat ARP logic.   Florian, you
> need to open a CP PMR.
>
> Regards,
>   Alan
>
> Senior Managing z/VM and Linux Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Alan Altmark]

I wasn't paying close enough attention.  APAR VM65104 is not for LGR.  The
APAR is a roll-back of a subset of the LGR grat ARP logic.   Florian, you
need to open a CP PMR.

Regards,
  Alan

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
alan_altm...@us.ibm.com

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Alan Altmark]

On Friday, 09/21/2012 at 06:57 EDT, Florian Bilek
 wrote:
> The MAC addresses of the VSWITCHs are different. At node A
> 02-F1-00-00-00-04 and at node B 02-F2-00-00-00-03.

The MAC address of a layer 2 VSWITCH itself isn't important in this
context.

In a relocation, the guest keeps its MAC address, so the remote host or
router ARP cache entry doesn't need to be updated.  What *does* have to
happen is for CP to notify the physical switch to remove the guest's MAC
address from its port forwarding database.  The not-yet-closed PTF for
APAR VM65104 that Marcy mentioned is needed to deal with this problem.
Real Soon Now.

All of this was triggered by that nasty (IMO) change in Linux to not do
grat ARPs when network interfaces are recovered.  On the positive side, CP
is now more properly in charge of the situation and it works for non-IP
network solutions, too, for which there is no grat ARP-like function.

Alan Altmark

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

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Florian Bilek]

Dear Harold,

The MAC addresses of the VSWITCHs are different. At node A
02-F1-00-00-00-04 and at node B 02-F2-00-00-00-03.

BR Florian

On Fri, Sep 21, 2012 at 11:50 AM, Harold Grovesteen
wrote:

> Does the "same manner as on NODE A" mean the same MAC address?
>
> Harold Grovesteen
>
> On Thu, 2012-09-20 at 19:13 +0200, Florian Bilek wrote:
> > Dear all,
> >
> > I face a problem with the new VMRELOCATION under z/VM 6.2.
> > The situation is as follows: One SLES 11 SP1 guest is connected via an
> > VSWITCH to a CICSO firewall. The vswitch is defined as type layer 2.
> > The network connection is working.
> >
> > When I relocate now the guest to NODE B the SSI cluster where the VSWITCH
> > is defined in the same manner as on NODE A the connection is not working
> > because of the arp cache in the firewall. It lasts endlessly till the
> > firewall flushes the arp cache and reestablish the connection.
> >
> > Is there some additional setup or manual intervention required on z/VM in
> > order to force a clear the arp cache in the firewall or is this a
> function
> > z/VM should handle internally? Does somebody had a similar situation?
> >
> > Thank you very much in advance.
> >
> > --
> > Best regards
> >
> > Florian Bilek
> >
> > --
> > 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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Harold Grovesteen]

Does the "same manner as on NODE A" mean the same MAC address?

Harold Grovesteen

On Thu, 2012-09-20 at 19:13 +0200, Florian Bilek wrote:
> Dear all,
>
> I face a problem with the new VMRELOCATION under z/VM 6.2.
> The situation is as follows: One SLES 11 SP1 guest is connected via an
> VSWITCH to a CICSO firewall. The vswitch is defined as type layer 2.
> The network connection is working.
>
> When I relocate now the guest to NODE B the SSI cluster where the VSWITCH
> is defined in the same manner as on NODE A the connection is not working
> because of the arp cache in the firewall. It lasts endlessly till the
> firewall flushes the arp cache and reestablish the connection.
>
> Is there some additional setup or manual intervention required on z/VM in
> order to force a clear the arp cache in the firewall or is this a function
> z/VM should handle internally? Does somebody had a similar situation?
>
> Thank you very much in advance.
>
> --
> Best regards
>
> Florian Bilek
>
> --
> 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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Florian Bilek]

Dear all,

Thank you, I will try this tomorrow. Keep you informed.

Regards,
Florian

On Thu, Sep 20, 2012 at 8:11 PM, David Boyes  wrote:

> Can't test this at the moment, but do the system logs tell you if the
> relocation generates a disconnect/reconnect event for the interface in
> question? IMHO, if it doesn't, then it should, since you're doing the
> equivalent of unplugging the machine, moving it, and then reconnecting it.
> Even if it's reconnecting to the same VLAN, the initial ARP to make sure
> you own the associated IP address should happen to avoid a race where a
> duplicate IP address could come online during the migration.
>
> Try running arping on the Linux machine via the 3270 console after the
> migration. If that fixes the problem (and it probably will), configure your
> Linux guests to generate a gratuitous ARP when the network interface state
> changes. That should force the FW to forget the old ARP entry and pickup
> the new one. Why the gratuitous ARP is no longer the default is still a
> mystery (at least to me, anyway) -- I can't conceive of a case where this
> would be the wrong behavior, and a ARP flood is not likely to be caused by
> a loose connector in this scenario (all virtual, all the time).
>
> There is probably a good argument that the VM migration code could/should
> force a proxy ARP for a guest when it gets migrated, though. It has enough
> information to do it (the old and new virtual MACs and the associated real
> OSA MACs) and that would at least force other devices to reevaluate any
> caches that might be present, even if the result ends up with the original
> configuration.
>
> Worth a call to the support center to discuss, anyway.
>
>


--
Best regards

Florian Bilek

--
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: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[Marcy Cortes]

Ask IBM about VM65104 when you call.

This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of David 
Boyes
Sent: Thursday, September 20, 2012 11:12 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Question on z/VM VMRELOCATION of SLES 11 SP1 guest

Can't test this at the moment, but do the system logs tell you if the 
relocation generates a disconnect/reconnect event for the interface in 
question? IMHO, if it doesn't, then it should, since you're doing the 
equivalent of unplugging the machine, moving it, and then reconnecting it. Even 
if it's reconnecting to the same VLAN, the initial ARP to make sure you own the 
associated IP address should happen to avoid a race where a duplicate IP 
address could come online during the migration. 

Try running arping on the Linux machine via the 3270 console after the 
migration. If that fixes the problem (and it probably will), configure your 
Linux guests to generate a gratuitous ARP when the network interface state 
changes. That should force the FW to forget the old ARP entry and pickup the 
new one. Why the gratuitous ARP is no longer the default is still a mystery (at 
least to me, anyway) -- I can't conceive of a case where this would be the 
wrong behavior, and a ARP flood is not likely to be caused by a loose connector 
in this scenario (all virtual, all the time).

There is probably a good argument that the VM migration code could/should force 
a proxy ARP for a guest when it gets migrated, though. It has enough 
information to do it (the old and new virtual MACs and the associated real OSA 
MACs) and that would at least force other devices to reevaluate any caches that 
might be present, even if the result ends up with the original configuration. 

Worth a call to the support center to discuss, anyway. 

Re: Question on z/VM VMRELOCATION of SLES 11 SP1 guest

[David Boyes]

Can't test this at the moment, but do the system logs tell you if the 
relocation generates a disconnect/reconnect event for the interface in 
question? IMHO, if it doesn't, then it should, since you're doing the 
equivalent of unplugging the machine, moving it, and then reconnecting it. Even 
if it's reconnecting to the same VLAN, the initial ARP to make sure you own the 
associated IP address should happen to avoid a race where a duplicate IP 
address could come online during the migration. 

Try running arping on the Linux machine via the 3270 console after the 
migration. If that fixes the problem (and it probably will), configure your 
Linux guests to generate a gratuitous ARP when the network interface state 
changes. That should force the FW to forget the old ARP entry and pickup the 
new one. Why the gratuitous ARP is no longer the default is still a mystery (at 
least to me, anyway) -- I can't conceive of a case where this would be the 
wrong behavior, and a ARP flood is not likely to be caused by a loose connector 
in this scenario (all virtual, all the time).

There is probably a good argument that the VM migration code could/should force 
a proxy ARP for a guest when it gets migrated, though. It has enough 
information to do it (the old and new virtual MACs and the associated real OSA 
MACs) and that would at least force other devices to reevaluate any caches that 
might be present, even if the result ends up with the original configuration. 

Worth a call to the support center to discuss, anyway. 

Re: Question to LDAP/RACF

[Florian Bilek]

Dear Robert,

In the case the nsswitch.conf is correctly set, id delivers also the
membership in posixGroups from LDAP. You have to add ldap next to file in
the config.

I did several tests and the posixGroups work well, while the dynamic groups
are not supported. by pam_ldap.

There is also something with I would like to see:

RACF supports in either OMVS or OVM profile all the relevant
posixAttributes such as uid, gid, shell, home directory. This is also not
supported by pam_ldap. If this would be supported you could manage the
user/groups simply from RACF while in the current situation you must
maintain the LDAP part as well.

For our system administrators it would be much more convenient to manage
users from RACF than to handle any LDAP tools.

Kind regards,
Florian





On Thu, Jun 7, 2012 at 2:12 AM, Robert Hart  wrote:

> Florian,
> Not too familiar with dynamic groups but I'm wondering if your expectations
> are correct. You seem to be expecting that a dynamic group set up in LDAP
> will reflect in the output of the linux id and getent commands. I don't see
> why that should be the case - id and getent display information from the
> file system and databases on the linux machine, not from the LDAP server
> backend.
>
> Regards,
> Robert Hart
> Australia Development Laboratory (ADL), West Perth
> Western Australia
> Internet: pbch...@au1.ibm.com
> Telephone: 61-8-9261-8560   Tie-line: 701-18560
> Fax:  61-8-9261-8453
>
>
>   -
>   Message from
>   Florian
>   Bilek
>   <
> florian.bi...@gmail.com>
>  on Mon, 21 May 2012 22:57:21 +0200 -
>
>
> Subject: Question to LDAP/RACF
>
> Dear all,
>
> I am trying to enable z/VM LDAP/RACF configuration to consolidate to user
> administration into one directory. In principle the thing works fine
> however I have a question regarding the right configuration:
>
> LDAP allows for dynamic groups. Those groups are based on LDAP queries and
> avoid the need of adding/deleting manually users to such groups.
>
> I defined a dynamic group called "users" that would qualify all accounts
> that have the attribute uid.
>
> The memberURL is as follows:
>
> dn: cn=users,dc=xxx
> objectclass: posixGroup
> objectclass: top
> objectclass: ibm-dynamicGroup
> cn: users
> gidnumber: 100
> memberurl: ldap:///dc=xxx??one?(&(objectClass=person)(uid=*))
>
> When I login now with a user I see the following:
>
> $ id
> uid=11002(xbilek) gid=9(usrys) groups=9(usrys)
>
> but it should look like
> id=11002(xbilek) gid=9(usrys) groups=100(users), 9(usrys)
>
> The getent group command shows only the name of the groups but no members:
>
> getent group users
>
> shows only: users:x:100:
>
> getent group usrys:
> shows only: users:x:9:
>
> Maybe the posixGroup is not the best. Is there a howto describing the
> parameters that need to be checked in ldap.conf?
>
> Thank you very much in advance.
>
> --
> Best regards
>
> Florian Bilek
>
> --
> 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/
>



--
Best regards

Florian Bilek

--
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: Question to LDAP/RACF

[Jon Miller]

I'm not familiar with the dynamic groups feature of LDAP but have other
LDAP experience. If I had to guess, the "one?" portion of your memberurl
attribute looks like the scope of the query. Assuming your group members
are down the tree in another OU, I'd try changing that to "sub?" making
your memberurl:
memberurl: ldap:///dc=xxx??sub?(&(objectClass=person)(uid=*))

I typically work out my queries via the "ldapsearch" command. Notice the
"-s " option for more on what I'm talking about. (LESS=Ipsub man
ldapsearch)

-- Jon Miller

On Wed, Jun 6, 2012 at 8:12 PM, Robert Hart  wrote:

> Florian,
> Not too familiar with dynamic groups but I'm wondering if your expectations
> are correct. You seem to be expecting that a dynamic group set up in LDAP
> will reflect in the output of the linux id and getent commands. I don't see
> why that should be the case - id and getent display information from the
> file system and databases on the linux machine, not from the LDAP server
> backend.
>
> Regards,
> Robert Hart
> Australia Development Laboratory (ADL), West Perth
> Western Australia
> Internet: pbch...@au1.ibm.com
> Telephone: 61-8-9261-8560   Tie-line: 701-18560
> Fax:  61-8-9261-8453
>
>
>   -
>   Message from
>   Florian
>   Bilek
>   <
> florian.bi...@gmail.com>
>  on Mon, 21 May 2012 22:57:21 +0200 -
>
>
> Subject: Question to LDAP/RACF
>
> Dear all,
>
> I am trying to enable z/VM LDAP/RACF configuration to consolidate to user
> administration into one directory. In principle the thing works fine
> however I have a question regarding the right configuration:
>
> LDAP allows for dynamic groups. Those groups are based on LDAP queries and
> avoid the need of adding/deleting manually users to such groups.
>
> I defined a dynamic group called "users" that would qualify all accounts
> that have the attribute uid.
>
> The memberURL is as follows:
>
> dn: cn=users,dc=xxx
> objectclass: posixGroup
> objectclass: top
> objectclass: ibm-dynamicGroup
> cn: users
> gidnumber: 100
> memberurl: ldap:///dc=xxx??one?(&(objectClass=person)(uid=*))
>
> When I login now with a user I see the following:
>
> $ id
> uid=11002(xbilek) gid=9(usrys) groups=9(usrys)
>
> but it should look like
> id=11002(xbilek) gid=9(usrys) groups=100(users), 9(usrys)
>
> The getent group command shows only the name of the groups but no members:
>
> getent group users
>
> shows only: users:x:100:
>
> getent group usrys:
> shows only: users:x:9:
>
> Maybe the posixGroup is not the best. Is there a howto describing the
> parameters that need to be checked in ldap.conf?
>
> Thank you very much in advance.
>
> --
> Best regards
>
> Florian Bilek
>
> --
> 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: Question to LDAP/RACF

[Robert Hart]

Florian,
Not too familiar with dynamic groups but I'm wondering if your expectations
are correct. You seem to be expecting that a dynamic group set up in LDAP
will reflect in the output of the linux id and getent commands. I don't see
why that should be the case - id and getent display information from the
file system and databases on the linux machine, not from the LDAP server
backend.

Regards,
Robert Hart
Australia Development Laboratory (ADL), West Perth
Western Australia
Internet: pbch...@au1.ibm.com
Telephone: 61-8-9261-8560   Tie-line: 701-18560
Fax:  61-8-9261-8453


   -
   Message from
   Florian
   Bilek
   

 on Mon, 21 May 2012 22:57:21 +0200 -


Subject: Question to LDAP/RACF

Dear all,

I am trying to enable z/VM LDAP/RACF configuration to consolidate to user
administration into one directory. In principle the thing works fine
however I have a question regarding the right configuration:

LDAP allows for dynamic groups. Those groups are based on LDAP queries and
avoid the need of adding/deleting manually users to such groups.

I defined a dynamic group called "users" that would qualify all accounts
that have the attribute uid.

The memberURL is as follows:

dn: cn=users,dc=xxx
objectclass: posixGroup
objectclass: top
objectclass: ibm-dynamicGroup
cn: users
gidnumber: 100
memberurl: ldap:///dc=xxx??one?(&(objectClass=person)(uid=*))

When I login now with a user I see the following:

$ id
uid=11002(xbilek) gid=9(usrys) groups=9(usrys)

but it should look like
id=11002(xbilek) gid=9(usrys) groups=100(users), 9(usrys)

The getent group command shows only the name of the groups but no members:

getent group users

shows only: users:x:100:

getent group usrys:
shows only: users:x:9:

Maybe the posixGroup is not the best. Is there a howto describing the
parameters that need to be checked in ldap.conf?

Thank you very much in advance.

--
Best regards

Florian Bilek

--
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: question migrating an LPAR full of guests to a new machine

[Rick Barlow]

We went through a z10 to z196 with NPIV in place for about 200 Linux
guests across 6 z/VM LPARs. As mentioned, the WWPN Predictor tool and
CCN were a part of the process.  If you are carrying forward FC
Express I/O cards, be very careful that they are put into the correct
locations in the new machine. If they are not installed correctly, the
vWWPNs will be wrong.  We had this problem and had to scramble during
the swap to fix it. Also, use great Carr in using the WWPN Predictor
tool.  Incorrect input will cause incorrect output.

Rick Barlow
Nationwide

On 5/14/12, David Boyes  wrote:
>> 1. I think the physical and NPIV wwpns will continue to be managed by
>> firmware for security.  There is definitely value in being able to
>> migrate
>> them around a plex though.
>
> This isn't mutually exclusive with telling users "don't be stupid --  using
> anything other than a NPIV address in a FCP guest will cause you reams of
> grief. Don't do it.". You can still manage the hardware addresses in
> firmware as today, until you can come up with a way of migrating the mapping
> of hw addresses to NPIV or user-managed WWPNs.
>
>> 2.  It isn't very easy to add a channel type.  Firmware is free like
>> device
>> drivers ;)  Anyway, that was a good description of iSCSI.  Many things
>> that I
>> didn't know.
>
> Since iSCSI semantics are pretty much identical to FCP semantics, I'm not
> sure why a new channel type would be required -- in fact, since iSCSI is
> just IP packets, you could get rid of one..8-). Perhaps you could ease the
> transitions by adding some new options to the FCP channel type -- that
> option transport could be covered by the current out-of-band-parameter
> communications that are already present in the existing FCP microcode
> process.
>
>> 3. I think this is the most popular solution.  I've heard it at least 5
>> times.  It
>> was my idea when I was a an ignorant new hire.  Every time it comes up
>> there is some reason not to do it.  Maybe it is time for customers to
>> raise
>> the issue in a more official forum.
>
> Been there, done that. 8-)
>
> It came down to "Figure 1: We make a boatload of money licensing FICON and
> ECKD tech. Don't mess with that. Figure 2:  See Figure 1." IBM owns about 2
> dozen different ways to do this (see CKD emulation in the P390 for a
> reasonably high-performance example), but see Figure 1. Or the XIV box.
>
>> 4. We didn't make a ficon data router for various reasons so I don't see
>> us
>> revisiting it in this context.
>
> Not sure what a Ficon router does here. A hw assist for 9336 translation
> would have to be in the I/O CCW evaluation path to be effective, but that
> doesn't imply routing function.
>
>> Good point about Tivoli being an added cost, but it shouldn't be an added
>> cost to just the mainframe.  The idea was to have a tool to manage wwpns
>> across all platforms.
>
> Problem is, most FCP implementations come with one provided by the HW
> vendor, and the hw vendors start finger-pointing if you don't use their
> tools. If there is a Tivoli requirement to play nice with the mainframe,
> that touches a lot more things than just the mainframe, and the assumption
> is that all tools have complete control -- and knowledge -- of the entire
> universe before they can make smart decisions fails miserably in a
> multi-vendor environment -- can't do that if part of the environment is
> managed by one tool, and another part is managed by another tool, and there
> are no effective APIs to communicate between tools.
>
>  There's a lot of cases where the hw vendor tools are included in the price
> of the hardware; an additional Tivoli requirement is a non-starter -- unless
> you guys are willing to go back to the Avanti consortium work and really
> agree on a toolset that HP and Hitachi and Oracle and ALL the other vendors
> can use as a common base for management software. That was a promising
> project -- killed by vendor bickering.
>
> --
> 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/
>

--
Sent from my mobile device

--
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: question migrating an LPAR full of guests to a new machine

[OAKES Roger * SDC]

Regarding machine replacement, if you get newer model OSA's you may change from 
one chpid per port to one chpid per port pair, which will force you to modify 
your definitions in z/VM to point to the correct OSA Port in addition to the 
correct memory range.  

Not a big deal, but an owie if you miss it.  

Roger Oakes  

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Grzegorz 
Powiedziuk
Sent: Tuesday, May 22, 2012 11:42 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: question migrating an LPAR full of guests to a new machine

2012/5/1 Bruce Lightsey 

> In the next two or three weeks we will have to move from our current z9 to
> a z114 and are trying to look for all of the "gotchas" involved.
>


We recently did exactly the same jump. NPIV I guess was explained already
(we actually implemented NPIV and SAN after we moved to z114).  I would
only suggest downloading and applying PTFs for z/vm. There were some pdfs
from IBM which specify which PTFs you have to have in your z/vm 5.4 for
z114. There aren't many but still, you should check this out.

You will have to slightly adjust your IOCP because some chpids changed in
z114.  There are tools out there to remap those but for us, IBM guy did it
 before we plugged in new machine. Guys who were setting up z114, moved all
LPARs configurations and uploaded new iocp.

Generally in our case it all went smooth and after 2hours we were up again.
Good luck

Gregory Powiedziuk





>

--
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: question migrating an LPAR full of guests to a new machine

[Grzegorz Powiedziuk]

2012/5/1 Bruce Lightsey 

> In the next two or three weeks we will have to move from our current z9 to
> a z114 and are trying to look for all of the "gotchas" involved.
>


We recently did exactly the same jump. NPIV I guess was explained already
(we actually implemented NPIV and SAN after we moved to z114).  I would
only suggest downloading and applying PTFs for z/vm. There were some pdfs
from IBM which specify which PTFs you have to have in your z/vm 5.4 for
z114. There aren't many but still, you should check this out.

You will have to slightly adjust your IOCP because some chpids changed in
z114.  There are tools out there to remap those but for us, IBM guy did it
 before we plugged in new machine. Guys who were setting up z114, moved all
LPARs configurations and uploaded new iocp.

Generally in our case it all went smooth and after 2hours we were up again.
Good luck

Gregory Powiedziuk





>

--
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: question migrating an LPAR full of guests to a new machine

[David Boyes]

> 1. I think the physical and NPIV wwpns will continue to be managed by
> firmware for security.  There is definitely value in being able to migrate
> them around a plex though.

This isn't mutually exclusive with telling users "don't be stupid --  using 
anything other than a NPIV address in a FCP guest will cause you reams of 
grief. Don't do it.". You can still manage the hardware addresses in firmware 
as today, until you can come up with a way of migrating the mapping of hw 
addresses to NPIV or user-managed WWPNs. 

> 2.  It isn't very easy to add a channel type.  Firmware is free like device
> drivers ;)  Anyway, that was a good description of iSCSI.  Many things that I
> didn't know.

Since iSCSI semantics are pretty much identical to FCP semantics, I'm not sure 
why a new channel type would be required -- in fact, since iSCSI is just IP 
packets, you could get rid of one..8-). Perhaps you could ease the transitions 
by adding some new options to the FCP channel type -- that option transport 
could be covered by the current out-of-band-parameter communications that are 
already present in the existing FCP microcode process. 

> 3. I think this is the most popular solution.  I've heard it at least 5 
> times.  It
> was my idea when I was a an ignorant new hire.  Every time it comes up
> there is some reason not to do it.  Maybe it is time for customers to raise
> the issue in a more official forum.

Been there, done that. 8-)

It came down to "Figure 1: We make a boatload of money licensing FICON and ECKD 
tech. Don't mess with that. Figure 2:  See Figure 1." IBM owns about 2 dozen 
different ways to do this (see CKD emulation in the P390 for a reasonably 
high-performance example), but see Figure 1. Or the XIV box. 

> 4. We didn't make a ficon data router for various reasons so I don't see us
> revisiting it in this context.

Not sure what a Ficon router does here. A hw assist for 9336 translation would 
have to be in the I/O CCW evaluation path to be effective, but that doesn't 
imply routing function. 

> Good point about Tivoli being an added cost, but it shouldn't be an added
> cost to just the mainframe.  The idea was to have a tool to manage wwpns
> across all platforms.

Problem is, most FCP implementations come with one provided by the HW vendor, 
and the hw vendors start finger-pointing if you don't use their tools. If there 
is a Tivoli requirement to play nice with the mainframe, that touches a lot 
more things than just the mainframe, and the assumption is that all tools have 
complete control -- and knowledge -- of the entire universe before they can 
make smart decisions fails miserably in a multi-vendor environment -- can't do 
that if part of the environment is managed by one tool, and another part is 
managed by another tool, and there are no effective APIs to communicate between 
tools.

 There's a lot of cases where the hw vendor tools are included in the price of 
the hardware; an additional Tivoli requirement is a non-starter -- unless you 
guys are willing to go back to the Avanti consortium work and really agree on a 
toolset that HP and Hitachi and Oracle and ALL the other vendors can use as a 
common base for management software. That was a promising project -- killed by 
vendor bickering.  

--
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: question migrating an LPAR full of guests to a new machine

[Raymond Higgs]

Linux on 390 Port  wrote on 05/07/2012 05:32:11
PM:

> From: David Boyes 
> To: LINUX-390@vm.marist.edu
> Date: 05/07/2012 05:39 PM
> Subject: Re: question migrating an LPAR full of guests to a new machine
> Sent by: Linux on 390 Port 
>
> > > > There should be an IBM
> > > > product that starts with T to fix this problem across all
platforms.
> > >
> > > Bleagh. Please, no. Fix the problem, not the symptoms.
> > That was the original plan, and many ideas have been debated since.
How
> > would you fix the problem?
>
> My suggestions:
>
> 1) Focus implementations on user-assigned WWPNs, which are not bound
> to physical hardware. You're going to end up dealing with
> virtualization solutions anyway, and that seems to be the direction
> the discrete world is headed.
>
> Same reasoning as why you never hardcoded token-ring addresses in
> VTAM -- you don't want to have to go back and fix up this kind of
> stuff during upgrades, and that configuration option can be carried
> between machines.
>
> 2) Add iSCSI support to the device microcode.
>
> Converged networks are the goal for most customers, and being ahead
> of the curve would be smart. iSCSI remedies most of the issues
> recently discussed in a far more portable way, and leverages a lot
> of things that would be highly useful in both z/OS sysplex and the
> VM SSI approach. The work done in the OSA to support some amount of
> TCP offload would be a good basis to start; completing the IP stack
> inside the OSA card would provide a basis for using a converged
> microcode load for both disk and network. Getting the router vendors
> to do this work for you would be even smarter (compare with router
> blades in Bladecenter on Intel) -- they already have line-speed
> converged networking and QoS delivery for 40G and 100G networks as
> shipping product that you don't have design or maintain.
>
> Linux has support for iSCSI baked in, and it is at least (if not
> more) reliable than FCP. Multipathing concerns go away. It's
> possible to easily implement iSCSI to FCP bridges in hardware ASICs.
> Eases the transition to software defined networks. Adds value to z/
> OS in that it would position z/OS as a leading enterprise OS in
> converged storage/data networking.
>
> 3) On real hardware, push the FCP mappings further into IOCP.
>
> Part of the value of the abstract device number concept in the XA I/
> O architecture was to not have to care about stuff like this in the
> OS.  Expanding the virtual FCP device definition in CP for Linux
> hosts similar to what was done for virtual MACs would be valuable
> (again, use the user-administered space for virtual devices and
> perform transforms in CP space to real hardware). The concept of
> virtual IOCPs has been discussed in the past, but was deemed not
> enough business case. This is an example of a good reason to do it.
> Would make the transition for z/OS to FBA a lot easier (could
> silently implement CKD translation to FCP w/o z/OS having to know/care)
>
> 4) Offloading the transformation process in VM for 9336 emulated
> devices to the I/O subsystem. Good candidate for a HW assist.
>
> This code currently runs on the 390 CPUs. This would be an
> accelerator that would benefit not just Linux but other OSes --
> that's one of the major reasons why people don't run totally FBA
> systems (other than the missing FBA support in z/OS). Would make #3
> lots easier.
>
>
> The reason I don't want a Tivoli solution is that the PHBs need to
> see the value of how much simpler to manage the 390 iron is -- they
> would view a requirement for a Tivoli product as another reason why
> the 390 costs more to run and is incompatible with their other
> strategic solutions.  Tivoli has a bad habit of assuming that it's
> the whole universe, and it often doesn't play nice with others in
> terms of API or scalability.

David,

Thank you for the thoughtful suggestions.  This is very good feedback.

1. I think the physical and NPIV wwpns will continue to be managed by
firmware for security.  There is definitely value in being able to migrate
them around a plex though.

2.  It isn't very easy to add a channel type.  Firmware is free like
device drivers ;)  Anyway, that was a good description of iSCSI.  Many
things that I didn't know.

3. I think this is the most popular solution.  I've heard it at least 5
times.  It was my idea when I was a an ignorant new hire.  Every time it
comes up there is some reason not to do it.  Maybe it is time for
customers to raise the issue in a more official forum.

4. We didn't make a ficon data router for various reasons so I don't see
us revisiting it in this

Re: question migrating an LPAR full of guests to a new machine

[David Boyes]

> > > There should be an IBM
> > > product that starts with T to fix this problem across all platforms.
> >
> > Bleagh. Please, no. Fix the problem, not the symptoms. 
> That was the original plan, and many ideas have been debated since.  How
> would you fix the problem?

My suggestions:

1) Focus implementations on user-assigned WWPNs, which are not bound to 
physical hardware. You're going to end up dealing with virtualization solutions 
anyway, and that seems to be the direction the discrete world is headed.

Same reasoning as why you never hardcoded token-ring addresses in VTAM -- you 
don't want to have to go back and fix up this kind of stuff during upgrades, 
and that configuration option can be carried between machines. 

2) Add iSCSI support to the device microcode. 

Converged networks are the goal for most customers, and being ahead of the 
curve would be smart. iSCSI remedies most of the issues recently discussed in a 
far more portable way, and leverages a lot of things that would be highly 
useful in both z/OS sysplex and the VM SSI approach. The work done in the OSA 
to support some amount of TCP offload would be a good basis to start; 
completing the IP stack inside the OSA card would provide a basis for using a 
converged microcode load for both disk and network. Getting the router vendors 
to do this work for you would be even smarter (compare with router blades in 
Bladecenter on Intel) -- they already have line-speed converged networking and 
QoS delivery for 40G and 100G networks as shipping product that you don't have 
design or maintain. 

Linux has support for iSCSI baked in, and it is at least (if not more) reliable 
than FCP. Multipathing concerns go away. It's possible to easily implement 
iSCSI to FCP bridges in hardware ASICs. Eases the transition to software 
defined networks. Adds value to z/OS in that it would position z/OS as a 
leading enterprise OS in converged storage/data networking. 

3) On real hardware, push the FCP mappings further into IOCP. 

Part of the value of the abstract device number concept in the XA I/O 
architecture was to not have to care about stuff like this in the OS.  
Expanding the virtual FCP device definition in CP for Linux hosts similar to 
what was done for virtual MACs would be valuable (again, use the 
user-administered space for virtual devices and perform transforms in CP space 
to real hardware). The concept of virtual IOCPs has been discussed in the past, 
but was deemed not enough business case. This is an example of a good reason to 
do it. Would make the transition for z/OS to FBA a lot easier (could silently 
implement CKD translation to FCP w/o z/OS having to know/care)

4) Offloading the transformation process in VM for 9336 emulated devices to the 
I/O subsystem. Good candidate for a HW assist. 

This code currently runs on the 390 CPUs. This would be an accelerator that 
would benefit not just Linux but other OSes -- that's one of the major reasons 
why people don't run totally FBA systems (other than the missing FBA support in 
z/OS). Would make #3 lots easier. 


The reason I don't want a Tivoli solution is that the PHBs need to see the 
value of how much simpler to manage the 390 iron is -- they would view a 
requirement for a Tivoli product as another reason why the 390 costs more to 
run and is incompatible with their other strategic solutions.  Tivoli has a bad 
habit of assuming that it's the whole universe, and it often doesn't play nice 
with others in terms of API or scalability. 

--
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: question migrating an LPAR full of guests to a new machine

[Raymond Higgs]

Linux on 390 Port  wrote on 05/01/2012 06:04:40
PM:

> From: Mark Post 
> To: LINUX-390@vm.marist.edu
> Date: 05/01/2012 06:17 PM
> Subject: Re: question migrating an LPAR full of guests to a new machine
> Sent by: Linux on 390 Port 
>
> >>> On 5/1/2012 at 05:12 PM, Rob van der Heij  wrote:

> > Also, the NPIV definitions need to be carried from the old LPAR to the
new
> > one. Have a look at the "WWPN tool" (from Resource Link) It should
help
> > preparing the definitions that allow the SAN changes to be made before
the
> > machine is there.
>
> If they're using NPIV.  Not a lot of people have gotten on that
> bandwagon yet, although they should.
>
>
> Mark Post
>

The latest wwpn tool predicts physical wwpns too.  The physical wwpns are
the ones that are used when NPIV is off.  A physical wwpn starts with
several digits of the IO serial number + pchid + 1.  For example, pchid
192 on one of the machines that I have access to is C05076FFFC001921.  I
think physical wwpns are much easier to work with now.

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

--
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: question migrating an LPAR full of guests to a new machine

[Raymond Higgs]

Linux on 390 Port  wrote on 05/02/2012 10:03:22
AM:

> From: David Boyes 
> To: LINUX-390@vm.marist.edu
> Date: 05/02/2012 10:12 AM
> Subject: Re: question migrating an LPAR full of guests to a new machine
> Sent by: Linux on 390 Port 
>
> >>. I find it hard to believe that nobody tried to put a DNS into
> > > the SAN...
>
> SNIA did start a discussion on this, but AFAICT, the project
> dissolved into a lot of internecine sniping between vendors. RFC
> 3721 provides this service for iSCSI, but not for "traditional" FCP.
> I suspect the same approach, appropriately modified, might work fairly
well.
>
> Another good reason to use iSCSI, IMHO.
>
>
> > There should be an IBM
> > product that starts with T to fix this problem across all platforms.
>
> Bleagh. Please, no. Fix the problem, not the symptoms.


That was the original plan, and many ideas have been debated since.  How
would you fix the 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

--
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: question migrating an LPAR full of guests to a new machine

[David Boyes]

>>. I find it hard to believe that nobody tried to put a DNS into
> > the SAN...

SNIA did start a discussion on this, but AFAICT, the project dissolved into a 
lot of internecine sniping between vendors. RFC 3721 provides this service for 
iSCSI, but not for "traditional" FCP.  I suspect the same approach, 
appropriately modified, might work fairly well. 

Another good reason to use iSCSI, IMHO.


> There should be an IBM
> product that starts with T to fix this problem across all platforms.

Bleagh. Please, no. Fix the problem, not the symptoms. 

--
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: question migrating an LPAR full of guests to a new machine

[Moody, Craig]

Whoever created the Config can run the WWPN Prediction Tool and get you the new 
WWPN's in advance. 
The tool is on IBM Resource Link and requires information from the 
configuration. It's been a while but I think I had to provide the configuration 
control number as input to pull the info for a machine that was not installed 
yet. 
Question:
Where can I get more information on the WWPN prediction tool?
Answer:
For more information on setting up a SAN using the WWPN prediction tool, refer 
to the IBM System z
enhancements Hardware Announcement 109-230, dated April 28, 2009.

Craig Moody
System Z Technical Specialist
Levi, Ray and Shoup, Inc
2401 West Monroe St
Springfield, Il 62704
217 793-3800 x1813



-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Tuesday, May 01, 2012 3:12 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: question migrating an LPAR full of guests to a new machine

>>> On 5/1/2012 at 03:38 PM, Bruce Lightsey  wrote: 
> Our storage guy asked about NPIV and WWPN names - all I could do was give him 
> my best dumb look ( I'm a dba, not a sysadmin or systems programmer ). So, 
> what should we expect ?  I don't think networking or CKD dasd will be an 
> issue but I have no idea how the SAN will react to having a different 
> mainframe replacing the one it knows.

You should expect that everything that the SAN sees will be different.  The 
mainframe should see exactly the same things it does now, assuming the SAN 
administrator is able to figure out what the new WWPNs for the z114 are going 
to be.  That would be a tedious job if it weren't a push-pull.  Since it is a 
push-pull, I'm not sure how they 're going to be able to do it in a reasonable 
amount of time.


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: question migrating an LPAR full of guests to a new machine

[Raymond Higgs]

Linux on 390 Port  wrote on 05/01/2012 06:08:43
PM:

> From: Rob van der Heij 
> To: LINUX-390@vm.marist.edu
> Date: 05/01/2012 06:25 PM
> Subject: Re: question migrating an LPAR full of guests to a new machine
> Sent by: Linux on 390 Port 
>
> On Tue, May 1, 2012 at 11:35 PM, Robert J Brenneman
wrote:
>
> > I second what Rob said - the WWPN tool is designed for this very
situation.
> >
>
> No FICON was designed for this ;-)Maybe the FCP folks never
anticipated
> to swap out 100's of servers in a few hours and expecting it to work.
>
> And we have not even told the OP that the opposite (swapping out the
disk
> subsystem) is even more tedious because it requires changes in each
Linux
> guest. I find it hard to believe that nobody tried to put a DNS into the
> SAN...
>
> Rob

Ficon wasn't designed for switch upgrades though...  There should be an
IBM product that starts with T to fix this problem across all platforms.

Lun discovery should alleviate changes in each Linux guest a bit.  The
symbolic wwpn and symbolic wwnn fields in the nameserver could be used for
something like a DNS.  The problem is that they are optional, and the SCSI
machine loader would need a few enhancements.

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

--
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: question migrating an LPAR full of guests to a new machine

[Mark Post]

>>> On 5/1/2012 at 05:12 PM, Rob van der Heij  wrote: 
> Also, the NPIV definitions need to be carried from the old LPAR to the new
> one. Have a look at the "WWPN tool" (from Resource Link) It should help
> preparing the definitions that allow the SAN changes to be made before the
> machine is there.

If they're using NPIV.  Not a lot of people have gotten on that bandwagon yet, 
although they should.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: question migrating an LPAR full of guests to a new machine

[Rob van der Heij]

On Tue, May 1, 2012 at 11:35 PM, Robert J Brenneman wrote:

> I second what Rob said - the WWPN tool is designed for this very situation.
>

No FICON was designed for this ;-)Maybe the FCP folks never anticipated
to swap out 100's of servers in a few hours and expecting it to work.

And we have not even told the OP that the opposite (swapping out the disk
subsystem) is even more tedious because it requires changes in each Linux
guest. I find it hard to believe that nobody tried to put a DNS into the
SAN...

Rob

--
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: question migrating an LPAR full of guests to a new machine

[Sam Bass]

In the WWPN tool you will have to specify the CHPIDs in the same order as you 
turn on NPIV on the CHPIDs or you will not get the proper results.

Sam Bass


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Robert J 
Brenneman
Sent: Tuesday, May 01, 2012 4:36 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: question migrating an LPAR full of guests to a new machine

I second what Rob said - the WWPN tool is designed for this very situation.

> Also, the NPIV definitions need to be carried from the old LPAR to the new
> one. Have a look at the "WWPN tool" (from Resource Link) It should help
> preparing the definitions that allow the SAN changes to be made before the
> machine is there.
>
> Rob



--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
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: question migrating an LPAR full of guests to a new machine

[Raymond Higgs]

Bruce,

There are 2 types of wwpns.  The physicals will change when upgrading from
z9 to z114.  Starting with z196, we generate physicals instead of using
what is burned into the flash on the card.  So next time it will be easier
for physicals.

The NPIV wwpns might stay the same.  What you want to do is carry your IO
serial number forward, and avoid IOCDS changes.  Making logical changes in
the IOCDS for things like the chpid and css will change the NPIV wwpns.

If you can't carry your IO serial number forward, and/or you make IOCDS
changes, there is a tool on resource link called WWPN Tool.  You can use
this to get a spreadsheet of what the wwpns for the new machine will be.
The new machine does not need to be installed at all.

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 05/01/2012 03:38:14
PM:

> From: Bruce Lightsey 
> To: LINUX-390@vm.marist.edu
> Date: 05/01/2012 04:10 PM
> Subject: question migrating an LPAR full of guests to a new machine
> Sent by: Linux on 390 Port 
>
> In the next two or three weeks we will have to move from our current
> z9 to a z114 and are trying to look for all of the "gotchas" involved.
>
> This is supposed to be a "pull-push" type of change with only the
> underlying hardware changing to start.
>
> Our current VM is our first experience with VM. We have never
> migrated a VM lpar to another machine( built new VM lpars on another
> machine, but never migrated).
>
> We are not going to change lpar definitions with one exception - we
> will be adding 1 IFL to the VM lpar.
> We won't be changing versions of zVM or Linux ( or z/OS on the other
> partitions ) or any application software.
> All consoles,network, and storage will be unplugged from the old box
> and plugged into the appropriate ports on the new box.
> All guests will, obviously, be shut down and restarted on the new
> hardware after zVM is up ( VM 5.4 ).
>
> Our storage guy asked about NPIV and WWPN names - all I could do was
> give him my best dumb look ( I'm a dba, not a sysadmin or systems
> programmer ). So, what should we expect ?  I don't think networking
> or CKD dasd will be an issue but I have no idea how the SAN will
> react to having a different mainframe replacing the one it knows.
>
> Thanks for any replies,
>
> Bruce Lightsey
> Database Administrator
> Mississippi Dept. of Information Technology Services
> 3771 Eastwood Drive
> Jackson, Ms 39211
> mailto: bruce.light...@its.ms.gov
> 601-432-8144
>
>
> DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or
> entity to whom they are addressed. If you have received this email
> in error please notify the system manager. This message contains
> confidential information and is intended only for the individual
> named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the
> sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of
> this information is strictly prohibited.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> http://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: question migrating an LPAR full of guests to a new machine

[Robert J Brenneman]

I second what Rob said - the WWPN tool is designed for this very situation.

> Also, the NPIV definitions need to be carried from the old LPAR to the new
> one. Have a look at the "WWPN tool" (from Resource Link) It should help
> preparing the definitions that allow the SAN changes to be made before the
> machine is there.
>
> Rob



--
Jay Brenneman

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: question migrating an LPAR full of guests to a new machine

[Rob van der Heij]

On Tue, May 1, 2012 at 10:12 PM, Mark Post  wrote:

>>> On 5/1/2012 at 03:38 PM, Bruce Lightsey 
> wrote:
> > Our storage guy asked about NPIV and WWPN names - all I could do was
> give him
> > my best dumb look ( I'm a dba, not a sysadmin or systems programmer ).
> So,
> > what should we expect ?  I don't think networking or CKD dasd will be an
> > issue but I have no idea how the SAN will react to having a different
> > mainframe replacing the one it knows.
>
> You should expect that everything that the SAN sees will be different.
>  The mainframe should see exactly the same things it does now, assuming the
> SAN administrator is able to figure out what the new WWPNs for the z114 are
> going to be.  That would be a tedious job if it weren't a push-pull.  Since
> it is a push-pull, I'm not sure how they 're going to be able to do it in a
> reasonable amount of time.
>
>
Also, the NPIV definitions need to be carried from the old LPAR to the new
one. Have a look at the "WWPN tool" (from Resource Link) It should help
preparing the definitions that allow the SAN changes to be made before the
machine is there.

Rob

--
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: question migrating an LPAR full of guests to a new machine

[Mark Post]

>>> On 5/1/2012 at 03:38 PM, Bruce Lightsey  wrote: 
> Our storage guy asked about NPIV and WWPN names - all I could do was give him 
> my best dumb look ( I'm a dba, not a sysadmin or systems programmer ). So, 
> what should we expect ?  I don't think networking or CKD dasd will be an 
> issue but I have no idea how the SAN will react to having a different 
> mainframe replacing the one it knows.

You should expect that everything that the SAN sees will be different.  The 
mainframe should see exactly the same things it does now, assuming the SAN 
administrator is able to figure out what the new WWPNs for the z114 are going 
to be.  That would be a tedious job if it weren't a push-pull.  Since it is a 
push-pull, I'm not sure how they 're going to be able to do it in a reasonable 
amount of time.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Question about zVM and MF configuration

[Michael Simms]

Thanks to all for your input. I really appreciate it!

Take care,
Michael



 From: David Boyes 
To: LINUX-390@VM.MARIST.EDU 
Sent: Monday, January 9, 2012 9:20 AM
Subject: Re: Question about zVM and MF configuration
 
> I have found myself having to defend the way we are now configured  vs. a
> co-worker who has come back from class saying his instructor said we should
> run 2 LPARs, one with zVM and zVSE and the other one house our production
> zLinux and DB2 images. 

This sounds like a recommendation from the time before z/VM could deal with 
LPARs containing mixed kinds of processors. 

As others have pointed out, there's no good technical reason to separate the 
two workloads (if you understand how to use the SET SHARE command in all it's 
myriad features), but there might be a political reason to have the "big wall" 
between the two setups. There are some pricing advantages to having Linux 
workload _really_ separated in terms of the price of z/VM and DB/2, but with 
only 1 CPU you may not be able to take advantage of them, and it's probably not 
worth the effort and annoyance to try to share the CPU at the LPAR level. 

> I have tried to explain how mainframe architecture and zVM have been
> designed as a sharing environment while at the same time protecting against
> influences from any given guest machine, should the configuration be
> configured just right. I might have partially agreed with his instructor had 
> not
> zVM come to support all manner of CPU in recent years, for example
> accommodating both CP and IFLs. We are also on a limited budget and I don’t
> know if we’d be able to purchase more storage or Chpids. Based on my years
> experience, I have poked, prodded and received advice for our system to
> where we have great performance today, both traditional and non-
> traditional workloads.

Ain't broke, don't mess with it. One LPAR is probably the way to go with your 
configuration, and your reasoning is sound in that if/when you add capacity, 
everybody wins.  The only argument for an additional LPAR would be if/when you 
plan to do VM 6.2 and turn on SSI (essentially that would turn your existing 
physical system into a 2 node cluster). The 2nd LPAR would help with 
availability in that case (move the workload over and take the other system out 
of the cluster for maintenance. But, that's different than the problem 
originally proposed. Unless you give guest systems privileges beyond class G 
and don't look regularly at your performance monitor, there's no way you're 
going to be able to do something rude to the rest of the system from a single 
guest.  The management simplification of having only one system to deal with is 
worth any risk that setup will entail.

--
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: Question about zVM and MF configuration

[Michael Simms]

I want to take this time to thank all who have answered with suggestions and 
opinions. All have been very valuable and I thank you, bunches.
Turns out those working behind my back scheduled a meeting with several zVM and 
'zLinux' specialists from IBM and including the 'gotchas' or 'think about 
this...' they agreed with my original assessment and with those who have 
responded here.
Chalk it up to those with the experience sometimes know what they are talking 
about. :-) Not bitter, just find it humorous!! IBM folks kept saying, '...but 
you've got an experienced VM system programmer there!'. It felt good. Ha ha ha.

Again THANKS A BUNCH




From: David Boyes 
To: LINUX-390@VM.MARIST.EDU 
Sent: Monday, January 9, 2012 9:20 AM
Subject: Re: Question about zVM and MF configuration
 
> I have found myself having to defend the way we are now configured  vs. a
> co-worker who has come back from class saying his instructor said we should
> run 2 LPARs, one with zVM and zVSE and the other one house our production
> zLinux and DB2 images. 

This sounds like a recommendation from the time before z/VM could deal with 
LPARs containing mixed kinds of processors. 

As others have pointed out, there's no good technical reason to separate the 
two workloads (if you understand how to use the SET SHARE command in all it's 
myriad features), but there might be a political reason to have the "big wall" 
between the two setups. There are some pricing advantages to having Linux 
workload _really_ separated in terms of the price of z/VM and DB/2, but with 
only 1 CPU you may not be able to take advantage of them, and it's probably not 
worth the effort and annoyance to try to share the CPU at the LPAR level. 

> I have tried to explain how mainframe architecture and zVM have been
> designed as a sharing environment while at the same time protecting against
> influences from any given guest machine, should the configuration be
> configured just right. I might have partially agreed with his instructor had 
> not
> zVM come to support all manner of CPU in recent years, for example
> accommodating both CP and IFLs. We are also on a limited budget and I don’t
> know if we’d be able to purchase more storage or Chpids. Based on my years
> experience, I have poked, prodded and received advice for our system to
> where we have great performance today, both traditional and non-
> traditional workloads.

Ain't broke, don't mess with it. One LPAR is probably the way to go with your 
configuration, and your reasoning is sound in that if/when you add capacity, 
everybody wins.  The only argument for an additional LPAR would be if/when you 
plan to do VM 6.2 and turn on SSI (essentially that would turn your existing 
physical system into a 2 node cluster). The 2nd LPAR would help with 
availability in that case (move the workload over and take the other system out 
of the cluster for maintenance. But, that's different than the problem 
originally proposed. Unless you give guest systems privileges beyond class G 
and don't look regularly at your performance monitor, there's no way you're 
going to be able to do something rude to the rest of the system from a single 
guest.  The management simplification of having only one system to deal with is 
worth any risk that setup will entail.

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