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 <dbo...@sinenomine.net> 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/

Reply via email to