You're hitting the nail on the head.. 'best practice' is to dedicate the DASD to each LPAR in the IODEF.. but this is best practice when security or data integrity demands 'physical' separation. It keeps you from shooting yourself in the foot and makes it impossible for an LPAR to effect another's DASD (unless the IODEF allows it). It comes at a cost, though.
You also have to take other things into consideration.. Maybe you want to backup your z/VM system volumes from z/OS - maybe you want the flexibility to put a free volume on either LPAR quickly without loading a new IODEF. What are the real requirements and restrictions you have to live under? What makes sense to you in terms of keeping things 'safe'? Some solutions beyond IO definitions (from a z/VM perspective - maybe others can talk about z/OS): - Update SYSTEM CONFIG on z/VM to only put online the addresses that you've designated belong to the z/VM LPAR. Make that your control and update it if you bring DASD dynamically to give to z/VM - Use AUTOLOG1/2 PROFILE EXEC to VARY OFF/ON the appropriate addresses so z/VM only has online what belongs to it. This is now your control over what's online to z/VM or not. The only way to really prevent someone with privs from varying on the DASD is to make the control the IODEF.. the LPAR only sees what belongs to it - period. The real question is 'what are the rules I must abide by'? -- maybe you have a company policy that addresses it - maybe you don't. Within those boundaries (or lack of them) - come up with the safest way to implement with the lowest amount of effort. You're not making mountains -- you have valid questions.. and the valid security/integrity concern of an LPAR having access to another's data. You need some solution to keep it all straight for sure! Scott Rohling On Tue, Apr 5, 2011 at 4:43 PM, Karl Huf <k...@ntrs.com> wrote: > I could have sworn I had seen something about this in a presentation > regarding "best practices" for configuring z/OS & z/VM LPAR's that share > the same DASD subsystems but now that I need it, no joy. > > We have 2 (z10) CEC's, each with z/VM and z/OS LPAR's attached via FICON > Directors to a pair of DS8700's. As currently configured all of the DASD > is defined on common LCU's and all of the DASD is online to all systems. > This makes me nervous but perhaps my fears are unfounded? My gut tells me > that a better configuration would be having the VM DASD segregated onto > dedicated LCU's and the rest of the MVS DASD on their own LCU's - and that > the respective devices not be online to the "foreign" OS's. Due to other > recent discoveries we have some DASD reconfiguration work ahead of us > anyway and, if it's worthwhile, I'd like to pile on with getting the VM > DASD to be isolated as part of that work - but at the moment I can't > quantify to those that would do the work why. > > Are there good reasons or am I making mountains where there are no > molehills? TIA. > > > > _______________________________________________________________________________ > Karl S Huf | Senior Vice President | World Wide Technology > 840 S Canal, Chicago, IL, 60607 | phone (312)630-6287 | k...@ntrs.com > Please visit northerntrust.com > CONFIDENTIALITY NOTICE: This communication is confidential, may be > privileged and is meant only for the intended recipient. If you are not > the intended recipient, please notify the sender ASAP and delete this > message from your system. > > IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment > concerns tax matters, it is not intended to be used and cannot be used by > a taxpayer for the purpose of avoiding penalties that may be imposed by > law. For more information about this notice, see > http://www.northerntrust.com/circular230 > > P Please consider the environment before printing this e-mail. >
