Re: question migrating an LPAR full of guests to a new machine

2012-05-26 Thread Rick Barlow
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/


Re: Crypto question

2012-05-26 Thread Marcy Cortes
So some file on disk that could presumably be restored if one knew where it 
was, correct?


Marcy.  Sent from my BlackBerry. 


- Original Message -
From: Alan Altmark [mailto:alan_altm...@us.ibm.com]
Sent: Friday, May 25, 2012 10:28 PM
To: LINUX-390@VM.MARIST.EDU LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Crypto question

Your pins are kept in the guest.  Only for secure-key ops (APDED, not
APVIRT) does the hardware retain keys.  VM does not keep any pins or key
material.

Regards,

Alan Altmark
IBM Lab Services

-
Sent from my BlackBerry Handheld.

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

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