> On Aug 20, 2015, at 9:23 AM, Alan Altmark <alan_altm...@us.ibm.com> wrote: > > The constant in this discussion is that FCP subchannels (device numbers) > with the same EQID are defined to have the same access rights, without > regard to the chpid. This means they are in the same SAN zone and are > masked to the same LUNs. If you are using NPIV, then that is done per > subchannel (zoned with the virtual WWPNs). If you're not using NPIV, then > all subchannels on the chpid have the same access rights (zoned with the > physical WWPN or at the port level). > > Keep an eye out for enhancements that will make pre-zoning much easier, > without the need for a prediction tool. >
Will do! > No, it's the correct thing. If every NPIV-enabled subchannel is zoned > separately, then every subchannel will have a unique EQID. > > For simplicity: > Member A > CHPID 60 6000-61A3 (that's the 420 device limit using 2 CUs) > CHPID 70 7000-71A3 > > Member B > CHPID 60 6000-61A3 > CHPID 70 7000-71A3 > > Virtual machine LINUX1 > DEDICATE 6000 6101 (x101 has been assigned to this guest) > DEDICATE 7000 7101 > Multipath config includes all target WWPNs and LUNs. > > Virtual machine LINUX2 > DEDICATE 6000 6102 (x102 has been assigned to this guest) > DEDICATE 7000 7102 > Multipath config includes all target WWPNs and LUNs. > > Each unique tuple (610x,710x) has been zoned and masked identically and > SYSTEM CONFIG has assigned each tuple the same EQID on all members. As > you relocate back and forth, virtual 6000 and 7000 will be on different > chpids. But the beauty of it is that you don't care which chpid. The > only difference it makes is that the local WWPN will be different. But > since the two WWPNs have the same access rights, no one cares. > > In a simple configuration, you could get away with using the user ID as > the EQID. > > Please note that the above illustrate why we suggest that you use the same > device numbers in your I/O configurations. If you don't, then the COMMAND > ATTACH EQID will be needed. That’s exactly what I did. Same addresses on all LPARS and on every LPAR, 60XX always goes to fabric A and 61XX always go to fabric B (switch A and switch B) So it’s quite easy to figure it out. Thank you one more time. I definitely have learned something here! I think I know what to do now. Gregory > > This all works because relocation causes Linux to re-establish its > connections to the LUNs. > > Alan Altmark > > Senior Managing z/VM and Linux Consultant > Lab Services System z Delivery Practice > IBM Systems & Technology Group > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott > > ---------------------------------------------------------------------- > 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/
