1. Use what you are familar with. If it was LPAR on the test box, you may lean towards LPAR on your production box.
2. Many of the small to midrange shops never had LPAR. We always ran VM in basic mode, hence we would run VM under VM for testing. Now that IBM forced everyone to LPAR, the small/medium size shops may rethink it. But most still run VM under VM as that is what we know. 3. LPAR dedicates memory. VM under VM only uses the memory when it is running. When second level VM isn't running, the memory can be used for other purposes. Use to be that many resources could not be shared in LPAR. Now it seems to be memory and bus and tag devices. (now that I have an escon channel converter on my bus and tag devices, can I switch my line printers, 3420 tape drives and/or my 3480 tape drives between LPARS? I don't think so, but that may be ancient knowledge.) 4. Very seldom, some things don't lend itself to VM under VM test systems. Say z/VM 5.1 (64 bit) under z/VM 4.1 (31 bit). Not going to happen. 5. Until z/VM 5.2, there was a 2 GB memory problem. If you were close to having that problem, running second level VM systems only made things worse. 6. LPARs not only dedicate real memory but the devices it uses, including shared channel devices, increase the size of your HSA. But what is another half GB of real memory beign taken away from production systems. I just went thru a z/VM 5.1 to z/VM 5.2 conversion. I have two VM systems, a 390 one and an IFL one. So I have two LPARs. In both cases, I brought up z/VM 5.2 under each of the 5.1 systems. And tested. And there was times, that I brought down a second level system (VSE or zLinux) from 5.1 and brought it up under the 5.2 system. i.e. LPAR ==> z/VM 5.1 ==> z/VM 5.2 ==> guest system Trivial when running VM under VM. If you are not using full pack volumes, not so trivial to do this going to another LPAR. 7. If you have more moden hardware, z/890 or above, OSA adapteres, escon or better, modern dasd subsystem, then there isn't much of a resource problem with either LPAR or VM under VM. But if you have any hardware that can only be dedicated to an LPAR and you don't have test hardware, then the only way to test it is VM under VM. 8. Minor thing. Doesn't the creation of an LPAR, still require an IML of the mainframe? You can change things without an IML (dynamic IOCP, and amount of memory for the LPAR), but I don't know if there is dynamic LPAR creation or not. Just a lot of things to consider. And no matter which way you choose, you are wrong! The universe is laughing behind your back. Tom Duerbusch THD Consulting Don't worry, be happy. >>> [EMAIL PROTECTED] 1/19/2007 12:24 PM >>> I'm going to go with one of my favorite answers here and say "it depends....". There are pros and cons for both approaches. Some z/OS centric sites might feel more comfortable using the LPAR approach,as that might fit in better with their over all system management scheme. Running z/VM as a 2nd level guest is more flexible, in terms of how quickly and easily the guest machine's definition can be changed to test new applications and software updates. However, there is a bit (small) of over head in running z/VM under z/VM, so absolute performance will not be as good as running z/VM native in an LPAR. Your mileage may vary, etc. Overall, all things being equal (which they hardly ever are....), my suggestion is to run z/VM as a 2nd level guest...it's easier to set up and maintain, and the over head isn't worth worrying about. Hope this helps. DJ Moeur Tim C wrote: > Good morning List, > > I have a question of general test and production architecture. We > currently have some production zLinux guests running under z/VM 5.1. > z/VM is installed as an LPAR on our single Z9 server. We had, until > recently, a second Z9 on which I was running a test VM which I could use > to apply and verify maintenance and program fixes. After those fixes > have been deemed OK, we'd move them to the production VM system > (VMPROD). Now, The VMTEST Z9 has gone away and now I'm faced with a > choice of creating a second LPAR for VMTEST, or to run VMTEST as a guest > under VMPROD. > > So the question is - is running my VMTEST as a guest of VMPROD good > practice? Are there exposures to flawed maintenance or program fixes > that wouldn't surface when the platform is running as a VM Guest? How > are those of you with current production and test VM systems doing this? > > Tim > [EMAIL PROTECTED] > > > > ---------------------------------------------------------------------- > 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
