To avoid this risk doesn't put all these disks on SYSTEM CONFIG. If you need repeated volsers, is secure to use fullpack dasd defined as MDISK ... DEVNO. VM mounts them only when necessary and volser doesn't matter I know a VM system that process many Disaster Recovery tests simultaneously, where many customers keep your dasds as 530RES by example. Use of DEVNO keep all secure and independent. Of course, the owned dasds have another different volsers and was mounted at lowest addresses. MVS doesn't work this way, so these dasds must be defined as OFFLINE to other MVS LPARs. Regards, Clovis
Alan Altmark
<alan_altm...@us.
ibm.com> To
Sent by: Linux on [email protected]
390 Port cc
<[email protected]
IST.EDU> Subject
Re: Z/Linux CKD DASD migration from
one DASD Subsystem to another
21/01/2009 18:31
Please respond to
Linux on 390 Port
<[email protected]
IST.EDU>
On Wednesday, 01/21/2009 at 02:39 EST, David Boyes <[email protected]>
wrote:
> I also really prefer to let VM manage the actual cyl 0. That may be just
> that I'm ancient and weird, but that way, there's absolutely zero chance
> that something weird in Linux will cause something unpleasant to happen
to a
> disk that some other OS cares about, and there's zero chance of some
yoyo
> creating duplicate volids on the physical system, which could impact the
> operation of the entire environment (cf the discussion about what order
> multiple DRCT areas get interpreted if you want to see how random that
can
> get)
z/VM presumes that you do not have any duplicate volids for any volid that
appears in SYSTEM CONFIG. If you allow duplicate volids, then you place
the system at risk since the system may mount the wrong volume during IPL.
<A Voice, off-stage>
:
11. Thou shalt Not give cylinder 0 unto thine untrusted guests
12. Thou may ignorest #11 if thou will use OFFLINE_AT_IPL and
ONLINE_AT_IPL to ensure that only the RDEVs desired by thee are processed
in SYSTEM CONFIG.
Let not the serpent of Convenience sway you onto a Dark path of
Corruption.
Alan Altmark
z/VM Development
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
<<inline: graycol.gif>>
<<inline: pic13945.gif>>
<<inline: ecblank.gif>>
