>> Same issue as ECKD. An OS cannot tell what other OSes/LPARs have >> access to an ECKD dasd volume. ...
> Well, it can to an extent [1][2]: Here's an example of QUERY DASD DETAILS where the first DASD hardware does not have 'Query Host Access'. The second does and it shows that 10 LPARs have access: ==> *q da details 189d* 189D CUTYPE = 2107-E8, DEVTYPE = 3390-0C, VOLSER = FDR3VM, CYLS = 10017 CACHE DETAILS: CACHE NVS CFW DFW PINNED CONCOPY -SUBSYSTEM Y Y Y - N N -DEVICE Y - - Y N N DEVICE DETAILS: CCA = 5D, DDC = --, SS = 0 DUPLEX DETAILS: -- CU DETAILS: SSID = 9002, CUNUM = 9002 ==> *q da details 047c* 047C CUTYPE = 2107-E8, DEVTYPE = 3390-0C, VOLSER = VM189D, CYLS = 10017 CACHE DETAILS: CACHE NVS CFW DFW PINNED CONCOPY -SUBSYSTEM Y Y Y - N N -DEVICE Y - - Y N N DEVICE DETAILS: CCA = 80, DDC = --, SS = 0 DUPLEX DETAILS: -- HYPERPAV DETAILS: BASE VOLUME IN POOL 1 CU DETAILS: SSID = 8101, CUNUM = 8101 * HOST ACCESS: CPU PARTITION GROUPED RESERVED MPATHMODE 9999 09 N N N 9999 04 Y N Y 9999 05 N N N 9999 02 N N N 9999 07 N N N 9999 01 N N N 9999 06 Y N Y -LOCAL 9999 0B Y N Y 9999 0C Y N Y 9999 0A N N N* -Mike M On Tue, May 12, 2015 at 6:27 AM, Peter Oberparleiter < ober...@linux.vnet.ibm.com> wrote: > On 11.05.2015 22:08, Alan Altmark wrote: > > On Monday, 05/11/2015 at 02:57 EDT, "Nix, Robert P." < > nix.rob...@mayo.edu> > > wrote: > >> Plus, even if you could find out if other zVM guests had access to the > >> LUN, that would not tell you what other systems, outside of this zVM > > (I.E. > >> On other zVM¹s, or on Intel or PowerPC systems, Linux or Windows, or > > even > >> Solaris or AIX?) had access to the LUN. > > > > Same issue as ECKD. An OS cannot tell what other OSes/LPARs have access > > to an ECKD dasd volume. > > Well, it can to an extent [1][2]: > > Query Host Access is a new DS8000 function that reports all LPARs > that have established a Path Group Id on a volume, whether in the > grouped state or not. z/VM now offers support to query the CPU > Serial Number and LPAR ID associated with all LPARs that have > established a Path Group Id to a volume, allowing one to determine > all LPARs with access to a volume. > > [1] http://www-01.ibm.com/support/docview.wss?uid=isg1VM65322 > [2] http://www-01.ibm.com/support/docview.wss?uid=isg1OA40720 > > > We simply ignore the issue and put the burden on > > the "hardware people" to limit access. We're lucky in that we generally > > trust the accessing systems. A naive trust, perhaps, but still.... > > > > My issue is that I don't understand the job of the SAN storage > > administrator well enough to judge how hard is is to implement strict > > zoning and LUN masking rules. They have orders of magnitude more > devices > > to deal with. > > > > 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 > > > Regards, > Peter Oberparleiter > > -- > Peter Oberparleiter > Linux on z Systems Development - IBM Germany > > ---------------------------------------------------------------------- > 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/