Re: z/VM & z/OS sharing same DASD
A VM/MVS sysprog with 2 ex-girlfriends??? Definitely fiction. %-) Martha On Wed, 6 Apr 2011 11:20:18 -0400 Alan Altmark said: >On Tuesday, 04/05/2011 at 06:44 EDT, Karl Huf wrote: >> Are there good reasons or am I making mountains where there are no >> molehills? > >When two disjoint entities have access to the same resources, there are >mountains that must be scaled. As others have noted, giving Entity One >access to the resources managed by Entity Two is a decision that you need >to *explicitly* make. Would you do it on other platforms? Is there a >policy? Do you need an approved waiver? A.k.a "Get Out of Jail Free >card." > >I ran across a problem when z/OS had access to z/VM dasd, and a *tape* >volser matched one of the z/VM *dasd* volsers. The tape mount on z/OS >failed. I was using the approved dasd naming convention - the Keepers of >the Convention had overlooked this issue. The MVS folks said, "Just >relabel all your disk volumes." I scoffed in their general direction and >told them to take VM dasd offline to MVS. But at some point the issue has >to be resolved because z/OS will be taking dasd backups of the z/VM >system, which is why it is shared. > >Now, on to Hollywood. Wednesday nights at 9pm on the CBC (Chuckie >Broadcasting System). This episode of "CSI: IT" opens with a VM systems >programmer sitting in a jail cell. We can tell he's a sysprog, btw, >because the guards keep rolling shiny balls in front of the cell, stopping >the sysprog in his tracks. (A bit of opening inside-joke humor while the >intro credits roll by.) As we watch, we find that: > >1. An MVS application is running, containing financial and personal >information of millions of people. Priceless. >(exciting, huh?) >2. A call from a throwaway cell phone (natch, don't bother checking) comes >into the CEO's office demanding $500M for the "return" of the above data >we now realize has been stolen. The voice is unfamiliar, but we >recognize an MVS accent. I think it's the way the caller said "dataset" >as all one word. [Obviously the story writer had been in the biz at some >point.] >3. There is a mad scramble to study the MVS SMF records. Nothing is >found. Squeaky clean. >4. The Class A IT Forensics team (night shift) is called in. [IT forensics >are best done at night, in the dark with the world's smallest flashlight.] >5. They discover shared dasd. Mangement says, "Is that a problem, >Inspector?" >(go to commercial for some new IT Security Software) >6. We "learn" that VM access to the dasd is not mediated by MVS security >controls (duh) >7. We "discover" that the jailed sysprog had unlimited power on VM (yawn >... duh x 2) >(wow...20 more minutes to solve the crime!) >8. Everyone involved gets an attorney and stops talking. (De rigeur for >all police dramas) >9. CSIs establish Means and Opportunity of the hapless sysprog. >10. They lean on the sysprog's gum-chewing ex-girlfriend and find that the >sysprog DID make some drunken statement at a party about the way >Management treated him on his last appraisal. They learn from another >ex-girlfriend that the sysprog spent 15 years working on MVS. They learn >from his mother that "he was always a quiet boy; just played his video >games." >11. Raising suspicions further, the sysprog did NOT advise Management of >the risks of such a configuration. >(go to commercial for platform-specific backup/restore software) > >And now you're caught up. You'll have to watch the rest of the episode to >find out what happens next. It's not what you think > > >Alan Altmark > >z/VM and Linux on System z Consultant >IBM System Lab Services and Training >ibm.com/systems/services/labservices >office: 607.429.3323 >mobile; 607.321.7556 >alan_altm...@us.ibm.com >IBM Endicott
Re: z/VM & z/OS sharing same DASD
Thank you all for the informed responses, they've been most helpful. As we don't have any need for the volumes of either OS to be online to each other I will proceed with a recommendation to segregate the z/VM volumes on to their own LCU(s). ___ 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.
Re: z/VM & z/OS sharing same DASD
On Tuesday, 04/05/2011 at 06:44 EDT, Karl Huf wrote: > Are there good reasons or am I making mountains where there are no > molehills? When two disjoint entities have access to the same resources, there are mountains that must be scaled. As others have noted, giving Entity One access to the resources managed by Entity Two is a decision that you need to *explicitly* make. Would you do it on other platforms? Is there a policy? Do you need an approved waiver? A.k.a "Get Out of Jail Free card." I ran across a problem when z/OS had access to z/VM dasd, and a *tape* volser matched one of the z/VM *dasd* volsers. The tape mount on z/OS failed. I was using the approved dasd naming convention - the Keepers of the Convention had overlooked this issue. The MVS folks said, "Just relabel all your disk volumes." I scoffed in their general direction and told them to take VM dasd offline to MVS. But at some point the issue has to be resolved because z/OS will be taking dasd backups of the z/VM system, which is why it is shared. Now, on to Hollywood. Wednesday nights at 9pm on the CBC (Chuckie Broadcasting System). This episode of "CSI: IT" opens with a VM systems programmer sitting in a jail cell. We can tell he's a sysprog, btw, because the guards keep rolling shiny balls in front of the cell, stopping the sysprog in his tracks. (A bit of opening inside-joke humor while the intro credits roll by.) As we watch, we find that: 1. An MVS application is running, containing financial and personal information of millions of people. Priceless. (exciting, huh?) 2. A call from a throwaway cell phone (natch, don't bother checking) comes into the CEO's office demanding $500M for the "return" of the above data we now realize has been stolen. The voice is unfamiliar, but we recognize an MVS accent. I think it's the way the caller said "dataset" as all one word. [Obviously the story writer had been in the biz at some point.] 3. There is a mad scramble to study the MVS SMF records. Nothing is found. Squeaky clean. 4. The Class A IT Forensics team (night shift) is called in. [IT forensics are best done at night, in the dark with the world's smallest flashlight.] 5. They discover shared dasd. Mangement says, "Is that a problem, Inspector?" (go to commercial for some new IT Security Software) 6. We "learn" that VM access to the dasd is not mediated by MVS security controls (duh) 7. We "discover" that the jailed sysprog had unlimited power on VM (yawn ... duh x 2) (wow...20 more minutes to solve the crime!) 8. Everyone involved gets an attorney and stops talking. (De rigeur for all police dramas) 9. CSIs establish Means and Opportunity of the hapless sysprog. 10. They lean on the sysprog's gum-chewing ex-girlfriend and find that the sysprog DID make some drunken statement at a party about the way Management treated him on his last appraisal. They learn from another ex-girlfriend that the sysprog spent 15 years working on MVS. They learn from his mother that "he was always a quiet boy; just played his video games." 11. Raising suspicions further, the sysprog did NOT advise Management of the risks of such a configuration. (go to commercial for platform-specific backup/restore software) And now you're caught up. You'll have to watch the rest of the episode to find out what happens next. It's not what you think Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: z/VM & z/OS sharing same DASD
On 4/5/2011 18:43, Karl Huf 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. Karl, We have a single z196 CEC, all EMC DASD gen'd on spanned FICON channels, all LPARS and all CSS can see everything. Unique VOLSER naming and documented standards are a must and work well for us. For the most part, we keep z/OS offline to z/VM and z/VM offline to z/OS. Exceptions do exist such as, bring the real z/VM volumes online to z/OS just long enough to do a DCOLLECT of the z/VM volumes then back offline they go. I could rant longer but ..YMMV. Would be glad to discuss offlist.. Regards, Doug
Re: z/VM & z/OS sharing same DASD
I think you can say best practice is on a need to know basis. This is especially important for some industries :) You really can't say you have a security system in place if something else can get there without it going through that security system. Does z/OS *need* to access your disk? (maybe they do if you do backups from there) Does z/VM *need* to access z/OS disks? (we have some isolated volumes that z/OS writes and z/VM reads, so yeah, but only on a very limited basis) Both Richard and Scott are correct (of course!). We do it at a gen level. That's most restrictive. And of course if you are doing it with a gen, then by LCU makes most sense or screwing up LPAR access lists becomes what easier :) You have not made mountains. They do exist :) Richards performance example is another reason. VM's i/o characteristics are shall we say "less friendly" to replication needs than z/Os is and tracking down performance problems are definitely more difficult if more than one o/s is hitting your subsystem. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Huf Sent: Tuesday, April 05, 2011 3:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] z/VM & z/OS sharing same DASD 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.
Re: z/VM & z/OS sharing same DASD
Having been in the same situation, my advice is that it is better to be safe than sorry. We had one individual who, on more than one occasion, formatted MVS volumes for use by TPF test systems. Needles to say, the MVS folks were not happy. I took the power away from him on two fronts when I was given responsibility for VM - 1. I took Class B away from him, and 2. I put all MVS disks that were not intentionally shared in the Not_Accepted list. The DASD Storage Management group, who controlled the world when it came to DASD surface acreage, thought it was a good idea to interleave the devices, giving VM the even numbers and MVS the odd. The MVS folks were trying to time the remote (2000 miles) replication of their DASD during what turned out to be a heavy period for VM. Our pleas to segregate the VM and MVS DASD finally struck home. They were not expecting VM to interfere with them. The outcome was not pretty - there were timeouts, and even failures, of the replication process due to the load that VM was putting on the channels. For me, the best practices are 1. Segregate the dasd, 2. Only have the disks that are intended for use by VM online, and 3. only give the power to ATTACH and DETACH to responsible parties who have a need for doing so. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Huf > Sent: Tuesday, April 05, 2011 3:44 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: z/VM & z/OS sharing same DASD > > 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. >
Re: z/VM & z/OS sharing same DASD
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 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. >
z/VM & z/OS sharing same DASD
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.
