> 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 [email protected] 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/
