On 10/28/2016 08:04 AM, Christer Solskogen wrote:
On Thu, Oct 27, 2016 at 6:55 PM, Alan Altmark <alan_altm...@us.ibm.com>
wrote:
On Thursday, 10/27/2016 at 02:32 GMT, "Cohen, Sam" <sam.co...@lrs.com>
wrote:
If you're not replacing the target SAN disks, then there are no changes
to z/VM or a Linux
connections (as long as the IOADDRS are unchanged). Your SAN fabric has
to change for the new
WWPNS on the z.
The z13 includes support to retain the NPIV WWPNs during an upgrade. Look
for the "Update I/O World Wide Port Number" task. (Read it as "Update I/O
Serial Number Portion of WWPNs".) This was previously an RPQ.
To the extent you keep the same IOCDS definitions and PCHID assignments,
you can keep the same NPIV WWPNs.
But we are changing the target SAN disks as well. And new SAN switches.
Since you seem to be changing both the initiator as well as the target
side, there are two aspects (changing the switches is more or less
transparent except for having to migrate the config of the old switches
over to the new ones, and recabling of course):
Changing the initiator (mainframe) influences SAN switch zoning and
host-mapping/LUN-masking on the storage target side. Alan's suggestion
is to minimize the influences or even make it completely transparent.
See also slides 20, 22, and 48 in [1].
Changing the target (storage) influences SAN switch zoning and path
configuration in Linux. I don't know if storages have similar
possibilities to carry over old storage HBA port WWPNs as described for
the mainframe above; if so it would be transparent.
Else:
If you use zfcp automatic LUN scanning then it would be transparent but
only regarding path detection [1, slides 33 and 38].
Otherwise I would probably recommend to teach your Linuxes the
information for all new (post-storage-migration) paths before doing the
migration [1, slides 35 or 37] so it knows both old and new; just make
sure e.g. via zoning that Linux only ever sees either the old or the new
storage.
I fear the volumes on the new storage will get different WWIDs so they
won't be added to the same path groups as the corresponding old volumes,
so you might either need additional alias entries in multipath.conf or
adapt fstab and kernel parameters to get to know the new multipath
device names [1, slide 25]. If so, I think this must be disruptive, i.e.
Linux shutdown before switchover and Linux boot after switchover (you
need that Linux disruption likely anyway because you also change the
mainframe unless you use something like live guest migration). Linux
multipathing should detect and automatically use the new paths [1, slide
30 and 32]. If you would like to clean up, you could start dynamically
removing the old path information from your Linuxes [1, same slides as
for adding path information above].
It's unfortunately tricky, so I'd recommend to practice this at least
once with a small test environment.
Having the root-fs on DASD makes it at least a bit easier.
[1]
http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf
--
Mit freundlichen Grüßen / Kind regards
Steffen Maier
Linux on z Systems Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
