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