And then, all of a sudden one of your production volumes is gone (e.g.
someone changed its label, or it was too slow to respond during IPL)
what causes the gold image copy to become online... Oups .... an
unpredicatble mess is what you get.

Without the presence of the golden image disks, your system would not
come up completely, but you'd notice it quickly and no data get
destroyed.
You know: my customer's operators caused such a mess in a disaster
test weekend: the PPRC copy pairs were broken; the VM selected  system
was IPLed at the remote site, application tests were performed.  All
was well.  Then when returning to the normal situation the forgot to
re-establish the remote copy pairs and IPLed the "normal" resident.
As a result: mosts disks except the resident were taken from the
remote site, this VM system started getting DB2 and SFS abends caused
by the mix.  Neither of the 2 disk sets was still OK: time to restore
the disaster backups.
Happily, the VM system they selected to test with was no longer in
production, no real harm done, but we slipped through the eye of a
need: someone had planned to use a real production system for this
test..

Since then: the server (running some REXX code) to break PPRC pairs
has been changed to directly relabel one of the packs after a PPRC
disable.

2009/1/30 Michael MacIsaac <[email protected]>:
>
>>> Second, if one's intent is to run
>>> nearly identical "cloned" VM images across some number of LPARS on some
>>> number of CECs, would there be a simple way to do this from one Master
>>> read-only RES pack containing various CPLOAD modules and system
>>> configuration files, sort of like our z/OS brethren do?
>
>> I am curious if the second question from Jonathan can be answered?
>
> I do this - not sure that it's best practices, but it seems to work :))
>
> I install a z/VM 5.4 system at the DASD with the *5 largest* address numbers
> of all the 3390-3s that are accessible to the LPARs (All DASD are accessible
> to all LPARs).
>
> I don't modify this system whatsoever, shut it down, and never IPL it again.
> Call this the golden VM.  I *believe* this ensures that if there are
> duplicate volsers, the golden VM will always be found later.
>
> I then close the door, shut down email, get off IM and then unhook the phone
> (OK, not literally :)). I then "clone" the golden VM to a target set of DASD
> - just FLASHCOPY or DDR the 5 volumes. I IPL the target and do see a warning
> about duplicate volsers - but it seems to be OK because the newly-cloned VM
> volumes are picked up first. I run IPWIZARD so I can get a 3270 session over
> the network. I then immediately relablel the volsers of the clone and I'm
> back to no duplicates volsers.  So the life of the duplicate volsers should
> be an hour or less.
>
> Hope this helps.
>
> "Mike MacIsaac" <[email protected]>   (845) 433-7061



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to