Following up on a thread from November. The subject alone caught my eye.
I share DASD all the time on my home systems.
Related:
With the help of an intern (Rushal Verma), I released an automounter
script called 'vmlink'. Works great on Linux on top of z/VM.
Mainframes have been sharing DASD at the physical layer from the
beginning. [cue Chicago, "Only the Beginning"]
z/VM has been sharing DASD, and slices thereof, at the logical layer
since its beginning.
So when VMware appeared and suddenly we had a hypervisor for a different
architecture, "I wonder ...", could one share virtual disks there too?
YES
It's true for KVM too, and likely most other hypervisors.
Seymour's right ...
Best practice is to not share what you can't protect, whether from
malice or from accident (like content corruption due to dual write; call
that a "write fight").
CMS uses a common IPL disk and at least one other, usually several
others. SHARED READ-ONLY
That's not sexy ... or maybe some of you have a weak appreciation for
"sexy".
Ironically, micro devices have been doing READ-ONLY longer than Unix and
Unix like systems (I'm talkin Linux, read on).
Your smart phone has a chunk of read-only memory. That's not DASD, but
it works the same: it holds a filesystem.
Same for ye olde Palm Pilot, okay prolly not a "filesystem", and even
further back. Remember PocketPC?
But I digress. With micro thingies, the content isn't shared.
So ... CMS does this all the time.
Turns out you can do it with other parts of your z/VM host system to any
number of VM-on-VM guests.
That is, you can share host minidisks, OR full volumes (containing
minidisks), with second level CP, doling out the same minidisks as found
on the host to the guests ... without having to copy the lot. Yes,
Virginia, you can share the CP IPL disk.
Not a big case for production work, but if your staging systems persist
then this hack might have real value. (Wanna get agile?)
Linux distributions picked up on the trick of read-only op sys content,
prolly to support flashable ROM or hand-helds.
Linux can straight away use shared R/O DASD for the op sys.
Linux can mimic CMS. hah
And we haven't even talked about containers.
"But it's gotta be writable."
Does it?
Think about all the R/O content you already have. Think about all the
stuff you don't WANT people writing or updating.
For any op sys, those things are candidates for residing on shared DASD.
It makes sense to manage such content that way even if you don't intend
to share the residence volumes.
But if it must be R/W then there are ways to make that happen.
Just gotta go out-of-band. None of our varied I/O models can fully
isolate mixed updates in the higher levels.
I have two flavors of Linux at home for which the OS disk is shared
across several virtual machines. These run 24x7 and are rock solid.
Guests which don't share the op sys have to be maintained individually.
The time spent baby-sitting them is painful.
These days I use KVM, but have also used VMware and Xen. KVM does allow
for disks to be explicitly "shareable" and "read only". In situations
where KVM cannot enforce R/O then my guests have to behave properly.
(Since I control them, that's less of a problem here.)
Works ... ahhh...
Sharing DASD ... just do it.
EASY for CMS content. Doable for selected parts of VM/CP.
Commonly done with z/OS too.
Should be done more in Linux land. Has also been done with Amdahl's UTS
and AIX/370 (but now I'm showing my gray hair).
That automounter script which I mentioned is here ...
https://github.com/trothr/vmlink/
-- R; <><
On 11/25/22 08:51, Seymour J Metz wrote:
Best practice is to not share what you can't protect. MIM, GRS ring, etc., can
help, but sharing of PDSE or Unix files can lead to data corruption even with
serialization, and sharing between security domains might not only lead to
compromisng data but to legal issues, both civil and criminal. If you're a
financial or medical facility, involve the legal staff in any decision of
sharing data between sysplexes.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Gord Neill [000002ff5f18e15f-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, November 24, 2022 3:54 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: To share or not to share DASD
G'day all,
I've been having discussions with a small shop (single mainframe, 3 separate LPARs, no
Sysplex) regarding best practices for DASD sharing. Their view is to share all DASD
volumes across their 3 LPARs (Prod/Dev/Test) so their developers/sysprogs can get access
to current datasets, but in order to do that, they'll need to use GRS Ring or MIM with
the associated overhead. I don't know of any other serialization products, and since
this is not a Sysplex environment, they can't use GRS Star. I suggested the idea of no
GRS, keeping most DASD volumes isolated to each LPAR, with a "shared string"
available to all LPARs for copying datasets, but it was not well received.
Just curious as to how other shops are handling this. TIA!
Gord Neill | Senior I/T Consultant | GlassHouse Systems
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
