Re: VM Best Practices
Gary, You can *ask* about best practice, but in this case no one can say what's universally best, not to mention what's best for you. I still think you got some answers and a few examples of what people are doing. It depends on what events do you want to protect yourself against, how quickly do you want your system or its parts back online, how much of the most recent data are you prepared to lose, and how much can you pay. Answers to these questions can lead to DR strategies ranging from a crumpled piece of paper in your pocket to a spare HAL in the orbit (I'm sure he'd support z/VM if asked politely). With the prices of disk storage and comms channels going down, mirroring to another site gained in popularity, but that's certainly not an answer for everyone. With modern disk systems and their fancy features you can make snapshots during the day and be happy with that. All these things said above are, admittedly, as much of an answer for z/VM as for any other operating system. If you are concerned about software failures or failures of z/VM features, then you first need to know the administrative processes of each feature, and that will give you an idea about a recovery process. In general, tape or virtual tape or disk-to-disk backups are your best friends. If you are concerned about CMS application recovery, then checkpoints are your better friends. Nothing new here. Depending on the amount and type of checkpoint data, you may use GLOBALV command, TDISKs, VDISKs, dataspaces, spool files, messages to "master" virtual machines with databases, and many other ways to achieve this. I, and more knowledgeable people on this list, would really need more specific info from you. Ivica
Re: VM Best Practices
In the movie "In Search of the Holy Grail", the knights who say "nee" could not bear to hear a certain words. One of those words was "it". "It" appears that best practice may be not to ask about - (words redacted). Thanks to all who responded. --. .- .-. -.-- Gary Dennis Mantissa Corporation 0 ... living between the zeros... 0
Re: VM Best Practices
> Mirroring does not replace good backup tapes: an accidental ERASE or FORMAT > is mirrored perfectly well to your DR site. Yes. Mirroring does not make any tape backups redundant, but they do drop to plan B in case of disaster. They remain plan A if you lose a file or a disk and even then FlashCopy and its brothers may give you a quicker solution. They (tapes) are the only plan if you lose both sites. Now, *that* would be a DR test, if someone would pay for it. > Secondly: if you simply have a two copy mirror, performing DR tests means you > break the mirroring during the test and at that time you no longer have a > mirror. Yep. During the test and a few hours after the test until re-sync is done. But those tape backups are still there. Ivica
Re: VM Best Practices
Kris, All true. I just didn't want to go into too much detail to express a simple point. We do use DASD-vendor provided software (neatly avoiding posting the vendor name) which provides writes to all mainframe DASD to be concurrently written to DASD at both campuses. The DASD at each campus is then mirrored at each campus. In preparation for the D.R test, the DASD vendor breaks the software link, causing each campus to have their own set of up-to-date mirrored DASD. Following the test, the vendor restores the link, and the D.R. site DASD (now out of synch) is automatically refreshed from the production copy. I'm the z/VM guy, I won't pretend to know all the technical details about how all that magic is performed, but instead just get to enjoy its benefits. Yet I do sometimes miss those occasional 44-hour+ straight-through-without-sleep bits-and-bytes D.R. tests. That's when the creative problem-solving juices really flow - when something in the D.R. plan breaks and you need to quickly develop a creative solution. Now, with split campuses and "mirrored" (to use the simple term) DASD, it's mostly boring - even if we do get bragging rights every time because that z/VM system is back up within about 20 minutes of being given the LPAR. OTOH, z/OS with DB2 and a "few" more apps is "just slightly" more complicated. ;-) Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Kris Buelens" Sent by: "The IBM z/VM Operating System" 12/16/2009 01:39 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM Best Practices Mirroring does not replace good backup tapes: an accidental ERASE or FORMAT is mirrored perfectly well to your DR site. Secondly: if you simply have a two copy mirror, performing DR tests means you break the mirroring during the test and at that time you no longer have a mirror. 2009/12/16 Ivica Brodaric Mike, I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Of course, mirroring makes that much easier, because your DR system is just waiting to be IPLed. You have to send less stuff off-site, a lot of it can be kept on disks. Anything that you may need *before* you bring up VM, and that answers questions "where is...?" has to be either in the DR manual or in the hardcopy report on the DR site. My recent experience is also with mirroring - two sites running half of production load each, disk mirroring each way. LPAR configs were identical between sites and DR meant logging on one second level VM on each surviving VM(*) and PROFILE and other EXECs would take care of the rest. But I still miss the good ol' days of walking into a DR site and actually *doing something* to restore the system. Oh, wait, maybe I don't. It's just nostalgia. I was just much younger then. :-) Ivica (*) I don't suggest this setup unless you have plenty of storage and zero paging in production LPARs. At least that. -- Kris Buelens, IBM Belgium, VM customer support The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VM Best Practices
> I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Ivica, Well... your post *did* come across as "smart" -- but the **GOOD** form of "smart", adding value to an open subject. There is no need to apologize for adding helpful detail to any subject. There are many new (and future) readers of this list who will benefit from the experiences of those who continue to contribute to the list (some contribute well after they have retired or are forced to leave z/VM). That's what makes this list a true world-wide "z/VM Community" (with the "z/" preface added to eliminate confusion caused by the other late-comer upstart "VM" groups (VMWare, Java VM's, VoiceMail, etc.). I believe that the first use of the term "VM Community" was by Melinda Varian, in her paper "What Mother Never Told You About VM Service, 1983", which while dated by VMSES/E is still a great resource (see: http://www.princeton.edu/~melinda/tutorial.listing ). Your contributions to the list have always been in that welcoming, inclusive spirit. My addition to your post was intended to confirm, and expand upon, what you wrote. My initial response was just to get the ball rolling, expecting that others would continue to contribute from their z/VM D.R. experiences. Thus, those new to z/VM have no reason to experience a disastrous Disaster Recovery, if that's not too redundant. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Ivica Brodaric" Sent by: "The IBM z/VM Operating System" 12/15/2009 06:49 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM Best Practices Mike, I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Of course, mirroring makes that much easier, because your DR system is just waiting to be IPLed. You have to send less stuff off-site, a lot of it can be kept on disks. Anything that you may need *before* you bring up VM, and that answers questions "where is...?" has to be either in the DR manual or in the hardcopy report on the DR site. My recent experience is also with mirroring - two sites running half of production load each, disk mirroring each way. LPAR configs were identical between sites and DR meant logging on one second level VM on each surviving VM(*) and PROFILE and other EXECs would take care of the rest. But I still miss the good ol' days of walking into a DR site and actually *doing something* to restore the system. Oh, wait, maybe I don't. It's just nostalgia. I was just much younger then. :-) Ivica (*) I don't suggest this setup unless you have plenty of storage and zero paging in production LPARs. At least that. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VM Best Practices
Mirroring does not replace good backup tapes: an accidental ERASE or FORMAT is mirrored perfectly well to your DR site. Secondly: if you simply have a two copy mirror, performing DR tests means you break the mirroring during the test and at that time you no longer have a mirror. 2009/12/16 Ivica Brodaric > Mike, > > I didn't mean to be smart, sorry if it came out that way. I just wanted to > stress that everything you need to perform a DR, including hardcopy reports, > utility tapes, DR procedure manual, CD's with software manuals, etc. has to > be on a DR site or in the off-site storage, that's all. > > Of course, mirroring makes that much easier, because your DR system is just > waiting to be IPLed. You have to send less stuff off-site, a lot of it can > be kept on disks. Anything that you may need *before* you bring up VM, and > that answers questions "where is...?" has to be either in the DR manual or > in the hardcopy report on the DR site. > > My recent experience is also with mirroring - two sites running half of > production load each, disk mirroring each way. LPAR configs were identical > between sites and DR meant logging on one second level VM on each surviving > VM(*) and PROFILE and other EXECs would take care of the rest. But I still > miss the good ol' days of walking into a DR site and actually *doing > something* to restore the system. Oh, wait, maybe I don't. It's just > nostalgia. I was just much younger then. :-) > > Ivica > > (*) I don't suggest this setup unless you have plenty of storage and zero > paging in production LPARs. At least that. > -- Kris Buelens, IBM Belgium, VM customer support
Re: VM Best Practices
Mike, I didn't mean to be smart, sorry if it came out that way. I just wanted to stress that everything you need to perform a DR, including hardcopy reports, utility tapes, DR procedure manual, CD's with software manuals, etc. has to be on a DR site or in the off-site storage, that's all. Of course, mirroring makes that much easier, because your DR system is just waiting to be IPLed. You have to send less stuff off-site, a lot of it can be kept on disks. Anything that you may need *before* you bring up VM, and that answers questions "where is...?" has to be either in the DR manual or in the hardcopy report on the DR site. My recent experience is also with mirroring - two sites running half of production load each, disk mirroring each way. LPAR configs were identical between sites and DR meant logging on one second level VM on each surviving VM(*) and PROFILE and other EXECs would take care of the rest. But I still miss the good ol' days of walking into a DR site and actually *doing something* to restore the system. Oh, wait, maybe I don't. It's just nostalgia. I was just much younger then. :-) Ivica (*) I don't suggest this setup unless you have plenty of storage and zero paging in production LPARs. At least that.
Re: VM Best Practices
Do you mean something like this:- http://www.dilbert.com/strips/comic/2008-09-03/ However what is "Best Practice" is to see what you customer needs are and then make sure that you have the appropriate procedures and practices in place to enable you to deliver these under all circumstances. Dave G4UGM > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen > Sent: 14 December 2009 22:34 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VM Best Practices > > > On Mon, 14 Dec 2009 15:09:11 -0500, Alan Altmark > > > wrote: > > >LOL. I am coming to hate the phrase "Best Practices". > > I've hated it for years. What's "best" for you is not > neccesarily "best" > > for me. > > Similarly, "rules of thumb" that get used without understanding their > underpinnings can handcuff you in situations where the "rule" > could have > > been safely ignored. > > Brian Nielsen
Re: VM Best Practices
The mirrored dasd would be nice. However, we do not have it yet. What we do have is writing backups to remote tape units. We do Hidro backups to them because of the speed and lesser line charges. We maintain 5 generations of the backups. When the backups complete, we send a note to a distribution list that includes people at both data centers and at the left-coast site, giving us at least two copies at each of three locations that are from each other by more than 1000 miles. The note contains a listing of all tapes that are available, most recent date first, and a complete set of instructions for restoring the system. We have recently tested the process and will do so annually, even if we change it to use mirrored dasd instead of the tape backups. I hear rumors that it might happen in the next few years, but will not hold my breath while waiting for it. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter > Sent: Monday, December 14, 2009 3:13 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VM Best Practices > > Yep, your updates are good, and in keeping with the opening > sentences of my reply: > > There are probably going to be a large number of replies based on > everyone's own personal experiences. > > Then add to more to item 2d. (if your pockets are deep enough): > "Ship either duplicate tapes, or the two most recent day's worth BY > SEPARATE PLANES and SEPARATE TRUCK." > > We used to ship the two most recent day's worth BY SEPARATE > PLANES. If > one shipment was delayed (or a tape was bad), we could test > with the other > day of tapes. > > Then we heard of case where all the tapes from both planes > ended up on the > same truck for a DR test and that truck went off a bridge, > destroying some > tapes and delaying the rest beyond the D.R. test window. > > After that there was a rumor (unsubstantiated) of two truck > drivers at the > delivery airport having their tapes loaded at the same time. > They loading > was complete at the same time. They competed to see who > could get the > tapes to the D.R. site first, running into each other during > the spirited > race from the airport. I never heard more details and > suspect a techie > folktale, but even if it's not true it's good to at least consider. > > My carry-on luggage always contained about 12 recent > hand-made (outside > the normal schedule) backup cartridges of the sysres and > program product > DASD. One time when a tape was missing from the shipment, we > were able to > continue with the D.R. test using the carry-on tape. The postmortem > report included a note that the (expensive) test would have > been a failure > had we not hand-carried our own copies. Never had another > missing tape > after that. > > Since then we opened a second data center about 3 miles away > as the crow > flies, with mirrored DASD. A D.R. test now is just 'cutting > the link' > (done by the DASD vendor) and IPLing the mirrored DASD (at the same > address!) from a CEC in the surviving data center. Sure > makes D.R. tests > a piece of cake. The z/VM system that we recover is > generally IPLed and > ready for users about 10-20 minutes after we're given the > LPAR (need time > to update a few CPUID-dependent product config files). The > users complete > testing in about an hour, we shutdown and go home to sleep. > Nice! :-) > > Mike Walter > Hewitt Associates > > > > > > "Ivica Brodaric" > > Sent by: "The IBM z/VM Operating System" > 12/14/2009 04:39 PM > Please respond to > "The IBM z/VM Operating System" > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > Re: VM Best Practices > > > > > > > 2) Keep automatically produced daily reports to minidisk, printed to > hardcopy at least weekly, showing: > a) the current location of critical minidisks. The list should be > quickly searchable by sorted userid and mdisk (e.g. "Where's > MAINT's 02C2 > disk with the "USER DIRECT" file? Or... the appropriate DIRMAINT, > VM:Secure, etc. source directory disk)? Where's the backup > catalog disk > located? > b) what's located, and where, on each real DASD (e.g. DASD VMU001 was > trashed, what did we lose?). > c) the allocation bitmap on each DASD. That will show the > DRCT, PAGE, > PARM, PERM, SPOL, or TDSK allocations when you don't have a > way to look > back at what once was. > > It's a go
Re: VM Best Practices
Yep, your updates are good, and in keeping with the opening sentences of my reply: > There are probably going to be a large number of replies based on everyone's own personal experiences. Then add to more to item 2d. (if your pockets are deep enough): "Ship either duplicate tapes, or the two most recent day's worth BY SEPARATE PLANES and SEPARATE TRUCK." We used to ship the two most recent day's worth BY SEPARATE PLANES. If one shipment was delayed (or a tape was bad), we could test with the other day of tapes. Then we heard of case where all the tapes from both planes ended up on the same truck for a DR test and that truck went off a bridge, destroying some tapes and delaying the rest beyond the D.R. test window. After that there was a rumor (unsubstantiated) of two truck drivers at the delivery airport having their tapes loaded at the same time. They loading was complete at the same time. They competed to see who could get the tapes to the D.R. site first, running into each other during the spirited race from the airport. I never heard more details and suspect a techie folktale, but even if it's not true it's good to at least consider. My carry-on luggage always contained about 12 recent hand-made (outside the normal schedule) backup cartridges of the sysres and program product DASD. One time when a tape was missing from the shipment, we were able to continue with the D.R. test using the carry-on tape. The postmortem report included a note that the (expensive) test would have been a failure had we not hand-carried our own copies. Never had another missing tape after that. Since then we opened a second data center about 3 miles away as the crow flies, with mirrored DASD. A D.R. test now is just 'cutting the link' (done by the DASD vendor) and IPLing the mirrored DASD (at the same address!) from a CEC in the surviving data center. Sure makes D.R. tests a piece of cake. The z/VM system that we recover is generally IPLed and ready for users about 10-20 minutes after we're given the LPAR (need time to update a few CPUID-dependent product config files). The users complete testing in about an hour, we shutdown and go home to sleep. Nice! :-) Mike Walter Hewitt Associates "Ivica Brodaric" Sent by: "The IBM z/VM Operating System" 12/14/2009 04:39 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: VM Best Practices 2) Keep automatically produced daily reports to minidisk, printed to hardcopy at least weekly, showing: a) the current location of critical minidisks. The list should be quickly searchable by sorted userid and mdisk (e.g. "Where's MAINT's 02C2 disk with the "USER DIRECT" file? Or... the appropriate DIRMAINT, VM:Secure, etc. source directory disk)? Where's the backup catalog disk located? b) what's located, and where, on each real DASD (e.g. DASD VMU001 was trashed, what did we lose?). c) the allocation bitmap on each DASD. That will show the DRCT, PAGE, PARM, PERM, SPOL, or TDSK allocations when you don't have a way to look back at what once was. It's a good list, but I would add under (2): d) If you are sending the backup tapes to offsite storage, make it a part of operations procedures to produce these critical reports in hardcopy and send them *with* the tapes offsite. Be prepared to do a DR test using only the contents retrieved from the offsite storage and a DR procedure manual stored at the DR site. Empty your pockets, please... OK, a pen is allowed. ;-) Ivica The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VM Best Practices
> > 2) Keep automatically produced daily reports to minidisk, printed to > hardcopy at least weekly, showing: > a) the current location of critical minidisks. The list should be > quickly searchable by sorted userid and mdisk (e.g. "Where's MAINT's 02C2 > disk with the "USER DIRECT" file? Or... the appropriate DIRMAINT, > VM:Secure, etc. source directory disk)? Where's the backup catalog disk > located? > b) what's located, and where, on each real DASD (e.g. DASD VMU001 was > trashed, what did we lose?). > c) the allocation bitmap on each DASD. That will show the DRCT, PAGE, > PARM, PERM, SPOL, or TDSK allocations when you don't have a way to look > back at what once was. > It's a good list, but I would add under (2): d) If you are sending the backup tapes to offsite storage, make it a part of operations procedures to produce these critical reports in hardcopy and send them *with* the tapes offsite. Be prepared to do a DR test using only the contents retrieved from the offsite storage and a DR procedure manual stored at the DR site. Empty your pockets, please... OK, a pen is allowed. ;-) Ivica
Re: VM Best Practices
On Mon, 14 Dec 2009 15:09:11 -0500, Alan Altmark wrote: >LOL. I am coming to hate the phrase "Best Practices". I've hated it for years. What's "best" for you is not neccesarily "best" for me. Similarly, "rules of thumb" that get used without understanding their underpinnings can handcuff you in situations where the "rule" could have been safely ignored. Brian Nielsen
Re: VM Best Practices
Gary, There are probably going to be a large number of replies based on everyone's own personal experiences. Errors of Omission is rather difficult to define, which omission did you mean? If you are not present to reply, raise your hand. ;-)~ My list of "D.R. Best Practices" includes: 1) Have good, and TESTED backup and restore procedures. There are no extra points awarded for having taken backups for years, but never having tried to restore anything without a running z/VM system! Extra points WILL be awarded to writing D.R. procedures so clearly and simply that your CIO can follow to the point of IPLing the restored system. 2) Keep automatically produced daily reports to minidisk, printed to hardcopy at least weekly, showing: a) the current location of critical minidisks. The list should be quickly searchable by sorted userid and mdisk (e.g. "Where's MAINT's 02C2 disk with the "USER DIRECT" file? Or... the appropriate DIRMAINT, VM:Secure, etc. source directory disk)? Where's the backup catalog disk located? b) what's located, and where, on each real DASD (e.g. DASD VMU001 was trashed, what did we lose?). c) the allocation bitmap on each DASD. That will show the DRCT, PAGE, PARM, PERM, SPOL, or TDSK allocations when you don't have a way to look back at what once was. 3) Build a 'one-pack' IPLable system. It does not need all MAINT's disks, but should contain the utility MDISKs. All our VM DASD here is, by policy, labeled to begin with "VM". My one-pack IPLable "Virtual Machine Operating System Hipervisor Tool" DASD is labeled "VMOSHT". 4) Be sure that you can find the syntax for the 'CP DEFINE MDISK' command - and that you have tested its use from MAINT and other D.R. sysprog IDs. CP DEFINE MDISK can be your best friend in a disaster. Getting the proper authorization to get it working can be tricky. 5) Ensure that your IPLable stand-alone UTILITY tapes are current. 6) TEST YOUR D.R. PROCEDURES REGULARLY. Mike Walter Hewitt Associates "Gary M. Dennis" Sent by: "The IBM z/VM Operating System" 12/14/2009 01:43 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject VM Best Practices Watching ?A Christmas Story? makes me wonder if you can ?shoot your eye out? through errors of omission with a VM system. Can anyone point me to a source for z/VM ?Best Practices? that addresses low level system recovery (essentially disaster recovery). Thanks Gary Dennis Mantissa Corporation 0 ... living between the zeros... 0 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VM Best Practices
On Monday, 12/14/2009 at 02:44 EST, "Gary M. Dennis" wrote: > Watching ?A Christmas Story? makes me wonder if you can ?shoot your eye out? > through errors of omission with a VM system. Of course. Computers aren't the brightest bulbs on the string, but they are obedient. Note that they do occassionally leave a mess on the floor, so you can't leave them unattended! There is a phrase: "Our gun, your foot. Keep your finger off the trigger." > Can anyone point me to a source for z/VM ?Best Practices? that addresses low > level system recovery (essentially disaster recovery). LOL. I am coming to hate the phrase "Best Practices". The problem is with "best." It depends on (a) what your recovery requirements are, and (b) how much money you are willing to pay. [1] You need to know: - How quickly must the virtual servers be back on the air? (z/VM is recovered and guests are up.) - How quickly must the virtual servers data be resynched with Last Known Data? (Linux guests have gone through their own recovery.) - How much in-flight data loss can you tolerate? The answers to these questions drive the technology and the cost. Alan Altmark z/VM Development IBM Endicott [1] Same issues come up vis a vis security. Performance. Automation. Provisioning
VM Best Practices
Watching ³A Christmas Story² makes me wonder if you can ³shoot your eye out² through errors of omission with a VM system. Can anyone point me to a source for z/VM ³Best Practices² that addresses low level system recovery (essentially disaster recovery). Thanks Gary Dennis Mantissa Corporation 0 ... living between the zeros... 0
