> From: David Boyes <dboyes@sine...>
> To: LINUXemail@example.com... > 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 <LINUXfirstname.lastname@example.org...>
> > > > There should be an IBM
> > > > product that starts with T to fix this problem across all
> > >
> > > Bleagh. Please, no. Fix the problem, not the symptoms.
> > That was the original plan, and many ideas have been debated since.
> > 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.
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 context.
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.
System z FCP Firmware Development
Bld. 706, B42
2455 South Road
Poughkeepsie, NY 12601
(845) 435-8666, T/L 295-8666