I restored VM in an LPAR at DR tests twice a year for over 15 years and
never had a problem with it. Everybody says that performance is not an
issue at a DR test, until people complain about it or you can't finish th
e
test in the alloted time slot! Believe me, performance can be an issue,
(more on the z/OS side than VM, of course). During most of my DR tests,
the box VM was running on was generally bigger than what I had on the hom
e
system! :-)>
The real key to running VM in an LPAR at DR is to make sure that all
required changes are well documented. Try to keep all the virtual
addresses the same at DR as the home system and remember that the real
addresses may vary from DR site to DR site and even from test to test, (i
n
other words don't hard code anything unless you are prepared to change it
).
if you can keep the virtual addresses the same and it's the same type of
device, then you shouldn't need to change any configuration files. Make
sure you have some way to bring your VM system up without starting any
virtual machines, (AUTOLOG1 should do nothing or very little), until you
have had a chance to make directory changes and configuration file
changes, (if necessary). One way to do this is to query the CPUID and
only do a "normal" start up if you are running on your home system.
Our "normal" IPL only starts a few machines, the operator has to enter a
STARTVM command to bring everything up. This is useful for weekend
testing also!
--
Dale R. Smith
"Even when the experts all agree, they may well be mistaken."
- Bertrand Russell
On Tue, 11 Mar 2008 13:21:10 -0400, Bill Munson <[EMAIL PROTECTED]>
wrote:
>I would have to agree with Adam, it is a Disaster Recovery TEST,
>performance is not your primary concern.
>
>Bill Munson
>VM System Programmer
>201-418-7588
>
>President MVMUA
>http://www2.marist.edu/~mvmua/
>
>
>
>
>
>Karl Kingston <[EMAIL PROTECTED]>
>Sent by: The IBM z/VM Operating System <[email protected]>
>03/11/2008 01:08 PM
>Please respond to
>The IBM z/VM Operating System <[email protected]>
>
>
>To
>[email protected]
>cc
>
>Subject
>Re: Disaster Recovery Scenarios
>
>
>
>
>
>
>
>OK we are running zLinux under zVM here. So from what I'm reading, z/v
m
>-> z/vm -> zlinux is not a very good idea???
>
>
>
>
>Adam Thornton <[EMAIL PROTECTED]>
>Sent by: The IBM z/VM Operating System <[email protected]>
>03/11/2008 09:53 AM
>
>Please respond to
>The IBM z/VM Operating System <[email protected]>
>
>
>To
>[email protected]
>cc
>
>Subject
>Re: Disaster Recovery Scenarios
>
>
>
>
>
>
>
>
>
>On Mar 11, 2008, at 6:59 AM, Karl Kingston wrote:
>
>
>Thanks for the responses to my DR question. Helpful information!
>
>So basically, I have 2 methods of bringing z/VM up at our DR site:
>
>1) Run it under the z/VM Floor System (we use Sungard as our DR service)
.
>
>2) Bring z/VM up in an LPAR.
>
>To me, option one is probably the BEST and EASIEST to implement as I don
't
>have to make changes to our running system to be able to run at the DR
>site.
>
>So: If I bring z/VM up under z/VM, what's the performance aspects of it
?
>Will it affect performance more than if z/vm was running in an LPAR?
>
>You'll take a few percent hit, versus identical hardware, but the larger
>difference is going to be the difference in hardware and load on the
>machine at the DR site.
>
>But seriously, being a VM user and *not* using a virtualized second-leve
l
>system for recovery is...silly.
>
>It's a *DISASTER* you're talking about. Getting the system back up--eve
n
>running slower--is most of what counts. You can recreate a faithful cop
y
>of your environment very, very easily using VM, and it's very, very much
>harder on the metal. DR procedures should be as simple as possible,
>because people are panicky during a disaster and there shouldn't be much
>that CAN go wrong. In that case, VM and an identical (even if
>second-level) environment is a clear win.
>
>Adam
>
>*************************** IMPORTANT
>NOTE***************************** The opinions expressed in this
>message and/or any attachments are those of the author and not
>necessarily those of Brown Brothers Harriman & Co., its
>subsidiaries and affiliates ("BBH"). There is no guarantee that
>this message is either private or confidential, and it may have
>been altered by unauthorized sources without your or our knowledge.
>Nothing in the message is capable or intended to create any legally
>binding obligations on either party and it is not intended to
>provide legal advice. BBH accepts no responsibility for loss or
>damage from its use, including damage from virus.
>************************************************************************
>========================
=========================
========================
