Newsgroups: bit.listserv.ibm-main
Date:         Wed, 23 Dec 1992 22:28:00 PST
From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
Subject:      Re: Logical Partitions/Physical Partitions

> >  - support of new hardware
> >    VM tends to have later support for new hardware, thus
> >    restricting you from installing new hardware (and selling the
> >    old while it's still worth something).
>
> I've never had trouble defining new whiz-bang devices to VM as
> unsupported devices. Yes, VM can't use them, but if the object is
> to supply them to a guest MVS, who cares? Let MVS deal with them
> -- 3390 and 3490 support started this way, and it's been
> succesful in our environment with non-blue gear.

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.

> >  - complexity
> >    VM is much more complex than LPAR.  Besides taking system
> >    programmer time to support/maintain it, there are more things
> >    which can go wrong (I/O support, CMS which is at least needed
> >    to maintain VM).
>
> I'm not sure I buy this at all. By the time you keep track of the
> microcode in the redundant controllers you need for good LPAR
> support and tune the LPAR configuration to get the right CPU caps
> and allocations, you've spent about as much time as you would
> have installing VM once and been done with it. If you are using
> VM for nothing but running guest MVS machines, you don't have to
> do diddly to VM -- you set up really big V=R/V=F areas and VM
> pretty much stays out of the way and lets MVS do it's thing.

VM doesn't *really truely* support multiple CPUs.

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

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

- 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...)

> There's also a pretty considerable hardware expense involved in
> LPAR operations -- duplicate controllers & devices aren't cheap.

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).

> The cost of a used 3880/3380K on the used market is small and
> VM runs OK in 1 3380 box, compared to duplicating a complete
> system configuration for each LPAR to maintain separation of
> devices.

> >    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...