I just want to reconcile what the People here are saying with what the folk on
the list say regarding what constitutes a 3rd level guest....
I'm being told by our head sysprog AND someone else with considerably more VM
experience (he's the new guy) that in Basic mode, the DR VM system is
first Level, our VM is second level and therefore any guests running under OUR
VM are second level.
It sounds to me like people here on the are saying that the DR VM system is
first level, OUR VM system is second level, and the Linux Guests running
under our VM under the DR vendor VM are in fact executing third level, and
hitting the SIE not in hardware problem.
Which is correct?
David Kreuter <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
<[email protected]>
To
[email protected]
cc
05/03/2006 09:06 AM
Subject
Re: What
configurations are people using for Disaster Recovery for Linux under
Please respond to z/VM
Linux on 390 Port <[email protected]>
Thanks for the update. It's the 3rd level dispatches killing your
response time. Even if response time were to be slower due to hardware
differences, your amount of slowdown is too drastic. Try recovering to
an LPAR.
David
James Melin wrote:
>I am going to address everyone's responses (thank you all) in this e-mail
>rather than reply multiple times:
>
>David Kreuter wrote:
>
>I would first look at any waiting, queueing, etc from the 1st and 2nd
>level system.
>I am willing to speculate without seeing data that your world of hurt is
>due the configuration of zvm under zvm. For a linux machine to get a
>dispatch it is going through two levels of CP. Years ago this caused
>extreme pain.
>David
>
>------------------------------------
>
>That was the first thing we looked at using the recovery system's perfkit
>(which I'm told the vendor allowed us to use on a ONE time basis - we wont
>have this) and our own perfkit.
>
>We saw lots of SIE, but no queueing or waiting. The Top level VM had the CP's
>dedicated so from it's perspective they were always 100% busy cuz it
was
>'spinnig' waiting for work.
>We also saw that there was lots of activity in moving things below the 2 GB
>line and back. But was that abnormal? Can't say.
>
>-------------------------------------
>
>Alan Altmark wrote:
>
>I would suggest devising a scenario wherein the guests of the failed z/VM
>system are recovered as first-level guests on the recovery system.
>
>Once the DR vendor turns the crank on the hardware to a later generation
>box, basic mode is gone and the SIE hardware assist for the (now) 3rd
>level guests is not available.
>
>------------------------------------
>
>I had this discussion yesterday. Our head systems programmer wants to pursue
>the problem from the configuration that we have in place (broken) and
let
>support services determine why Java performance is slow in the Linux under
>z/VM under z/VM environment. I tried to make the case, using the State of
>Minnesota as an example - They don't run their recovered VM under the DR
>vendor VM. The people who make the ultimate decision on how we will recover
>don't seem to think that it matters how the State does it, or that nobody else
>seems to do it the way we do it either. I think they are of the
opinion
>that to pursue multiple different scenarios will make things confusing. I
>think it would reveal things to look at REGARDLESS of what happens.
>Performance improves? It's a VM under VM thing. Performance does NOT improve,
>it's a base configuration problem on the recovery system that is the
>doing of the DR vendor.
>
>------------------------------------
>
>Marcy Cortes wrote:
>
>We recover the VM system to an LPAR, not under VM. Because VM senses
>all the i/o, the only changes we need to make for addressing differences
>is to DFSMS RMS & VMTAPE for tape drive numbers and to TCPIP for OSA
>differences (we have alternate tcpip profile which goes into effect
>based on node name change based on cpuid so that's pretty automatic).
>
>I take that back a little bit - we do recover VM system volumes under a
>VM starter system, then we IPL that restored system to an LPAR (not VM
>under VM).
>
>We do it inhouse though, so we aren't under any vendor constraints.
>
>Do you also run a z900 in production? Java perf is much better on
>z990's and even better on z9.
>
>------------------------------------
>
>Sadly, we're running on a z900. With the new z9 offerings, I suspect that we
>might be able to get one in here to replace the z900 but again that's
out
>of my hands. If there would be no performance hit to our z/OS recovery, I'd
>LOVE to recover in LPAR mode - using the current VM setup in one LPAR.
>That way our z/OS recovery doesn't need to change (we've played into that
>environment quite nicely) but our VM can then come up in an LPAR with
>minimal tailoring. We could even do the tailoring on the guest we currently
>used to run it - shut it down and IPL it in the LPAR.
>
>Anyway, thanks for the feedback. It seems to support my position better than
>the other folks.
>
>-J
>
>----------------------------------------------------------------------
>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
----------------------------------------------------------------------
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
