home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmmain / 2881 < prev    next >
Encoding:
Text File  |  1992-12-24  |  3.7 KB  |  85 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!UCLAMVS.BITNET!CSYSMAS
  3. Message-ID: <IBM-MAIN%92122400293355@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Wed, 23 Dec 1992 22:28:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
  8. Subject:      Re: Logical Partitions/Physical Partitions
  9. Lines: 74
  10.  
  11. > >  - support of new hardware
  12. > >    VM tends to have later support for new hardware, thus
  13. > >    restricting you from installing new hardware (and selling the
  14. > >    old while it's still worth something).
  15. >
  16. > I've never had trouble defining new whiz-bang devices to VM as
  17. > unsupported devices. Yes, VM can't use them, but if the object is
  18. > to supply them to a guest MVS, who cares? Let MVS deal with them
  19. > -- 3390 and 3490 support started this way, and it's been
  20. > succesful in our environment with non-blue gear.
  21.  
  22. Try IPLing your virtual machine from the "whiz-bang" device.
  23.  
  24. Try having VM translate the CLAW never ending channel programs
  25. without the right support in VM.
  26.  
  27. Over the years, it always seems that VM needs updating for new
  28. devices and it's always after MVS -- unsupported definitions
  29. don't in general allow full function - even for a guest machine.
  30.  
  31. > >  - complexity
  32. > >    VM is much more complex than LPAR.  Besides taking system
  33. > >    programmer time to support/maintain it, there are more things
  34. > >    which can go wrong (I/O support, CMS which is at least needed
  35. > >    to maintain VM).
  36. >
  37. > I'm not sure I buy this at all. By the time you keep track of the
  38. > microcode in the redundant controllers you need for good LPAR
  39. > support and tune the LPAR configuration to get the right CPU caps
  40. > and allocations, you've spent about as much time as you would
  41. > have installing VM once and been done with it. If you are using
  42. > VM for nothing but running guest MVS machines, you don't have to
  43. > do diddly to VM -- you set up really big V=R/V=F areas and VM
  44. > pretty much stays out of the way and lets MVS do it's thing.
  45.  
  46. VM doesn't *really truely* support multiple CPUs.
  47.  
  48. - VM runs asymmetric multiprocessing, using a master CPU.  So
  49.   much of VM processing has to run on the master.
  50.  
  51. - VM doesn't have lock recovery code (as does MVS).  If you
  52.   get a failure in the right place you just spin...
  53.  
  54. - VM doesn't simulate guest multi-processing correctly.
  55.   Everytime the guest enters "console function mode" it stops all
  56.   your virtual machines CPUs.  The real hardware doesn't work
  57.   this way (to say nothing of getting stuck here...)
  58.  
  59. > There's also a pretty considerable hardware expense involved in
  60. > LPAR operations -- duplicate controllers & devices aren't cheap.
  61.  
  62. With ESCON and multipath controllers for DASD, at least the DASD
  63. paths for test systems (low usage), aren't all that expensive
  64. (use 1 of 4 paths for test, leaving 3 for production).
  65.  
  66. > The cost of a used 3880/3380K on the used market is small and
  67. > VM runs OK in 1 3380 box, compared to duplicating a complete
  68. > system configuration for each LPAR to maintain separation of
  69. > devices.
  70.  
  71. > >    It's easy to say that VM and LPAR should have the same
  72. > >    overhead, however it may not be.  It's probably easy to start
  73. > >    using some VM services which have a large impact on the
  74. > >    performance.  And if you can't use the VM services why pay for
  75. > >    VM?  (reliability, $, maintenance, support etc).
  76. >
  77. > LPARs are a lot easier to tune, I'll admit. I dearly wish for an
  78. > absolute CPU cap in VM. Most MVS-intensive shops with VM that I know of
  79. > use VM to replace real CTCA or 3088 hardware and not much else.
  80. > The maintenance on one real CTCA makes up a significant portion of
  81. > the cost of VM, especially for academic sites eligible for the
  82. > HESC discounts.
  83.  
  84. ESCON removes that need...
  85.