NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/bit/listserv/ibmmain/2890

Text File | 1992-12-24 | 5.3 KB | 115 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!psuvax1!psuvm!auvm!IS.RICE.EDU!DBOYES
X-Mailer: ELM [version 2.3 PL11]
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.ibm-main
Date:         Thu, 24 Dec 1992 12:03:37 CST
Sender:       IBM Mainframe Discussion list <[e-mail]>
From:         David E Boyes <[e-mail]>
Subject:      Re: Logical Partitions/Physical Partitions
Comments: To: [e-mail]
In-Reply-To:  <[e-mail]>; from "Michael Stein" at Dec 23,
              92 10:28 pm
Lines: 100

Sigh. This is becoming a religious argument, but once more into
the breach...

> Try IPLing your virtual machine from the "whiz-bang" device.
> Try having VM translate the CLAW never ending channel programs
> without the right support in VM.
> Over the years, it always seems that VM needs updating for new
> devices and it's always after MVS -- unsupported definitions
> don't in general allow full function - even for a guest machine.

If the device is DEDICATEd to the guest, it generally works fine.
The problems you describe occur when you use VM to simulate these
new magic devices -- guests can do whatever they want with
DEDICATEd devices. An example of this is running a guest that can
use 3370/FBA devices under VM/XA -- VM/XA does not support FBA
devices at all, but if you define the 3370s as
DEVTYPE=IBM3370,CLASS=DISK and DEDICATE them to the guest, it
works just great. No support in VM at all, but the guest can use
the device.

I've IPLed VM/SP 5 off a 3370 as a guest of VM/XA at another
employer. Works just fine. Same with MVS/SP and some other odd
devices (MSS, anyone?).

> - VM runs asymmetric multiprocessing, using a master CPU.  So
>   much of VM processing has to run on the master.

Following the introduction of N-way MP support in VM/XA, the
amount of code that *must* execute on the IPL processor is
microscopic, less than a dozen modules. If you have a MP box, you
can choose to dedicate real processors to guests and let them
manage their own usage of the processors. If you have compute
intensive guests under VM, I'd recommend letting VM do the CPU
scheduling instead of dedicating processors, as it lets piggy
guests that need all the cycles they can get to make use of idle
cycles in other guests. I consider this an advantage, although it
does hamper tuning for specific service levels and maximum CPU
fractions.

Your opinion is certainly valid for HPO 5 and earlier, though.

> - VM doesn't have lock recovery code (as does MVS).  If you
>   get a failure in the right place you just spin...

If you fail in a critical code section, MVS on raw iron spins just
as hard. I'm not sure this is really relevant.

> - VM doesn't simulate guest multi-processing correctly.
>   Everytime the guest enters "console function mode" it stops all
>   your virtual machines CPUs.  The real hardware doesn't work
>   this way (to say nothing of getting stuck here...)

Huh??? I've never seen this under VM/XA or VM/ESA.

> With ESCON and multipath controllers for DASD, at least the DASD
> paths for test systems (low usage), aren't all that expensive
> (use 1 of 4 paths for test, leaving 3 for production).

Aren't all that expensive? ESCON-capable equipment in the
used market is at least one order of magnitude more costly;
something that is a very telling blow against mainframe hardware
in general, especially in academic environments where the big
iron is already under fire for costs. Remember, the original
poster in this thread was from a university, one with a *very*
large investment in workstations. In his environment, anything
that prevents having to replicate dedicated hardware is going to
be a win.

> > >    It's easy to say that VM and LPAR should have the same
> > >    overhead, however it may not be.  It's probably easy to start
> > >    using some VM services which have a large impact on the
> > >    performance.  And if you can't use the VM services why pay for
> > >    VM?  (reliability, $, maintenance, support etc).
> >
> > LPARs are a lot easier to tune, I'll admit. I dearly wish for an
> > absolute CPU cap in VM. Most MVS-intensive shops with VM that I know of
> > use VM to replace real CTCA or 3088 hardware and not much else.
> > The maintenance on one real CTCA makes up a significant portion of
> > the cost of VM, especially for academic sites eligible for the
> > HESC discounts.
>
> ESCON removes that need...

ESCON still doesn't address the cost of maintenance on the
replicated hardware, or the inter-LPAR communications issue.
Consider also the reduced complexity in NCP gens (only one
channel interface to deal with, routing tables are simpler, fewer
places to have to maintain VTAMLSTs...) when generating a large
SNA network.

Don't get me wrong -- I'd give my back eyeteeth for a full-up 8
channel ESCON 3990 and a bank of 3390-3's. If I can ever dream up
a sufficient justification for spending .5 or .75 million dollars
on DASD,  there's no way that kind of hardware will fly in an
environment where I have to replicate it or partition access to
it because of the requirement of a machine partitioning scheme
like LPAR. VM lets *all* my users take _full_ advantage of that
investment. I'm also not against LPAR -- it does some stuff that
VM can't do -- but it's not a complete solution, and it's an
expensive solution if you have limited resources.