The big advantage of VM nowadays is the sharing of real memory. LPARs can share processor and channels and devices. Minidisks are pretty small, for z/OS there is usual ly no particular advantage to them.
So the question is, do you have workloads that can take advantage of shar ed memory? Production z/OS systems with different memory peaks might be complimentary. Test sys tems that are only up part of the time are an even better candidate. If all your z/OS systems h ave peak storage requirements at the same time, then memory savings will be limited. You can overcommit memory -- but the bad news is that when the z/OS gues t takes a page fault, the whole guest stops until the page fault is satisfied. VSE has implemen ted handshaking so that only the particular task whose page is faulted has to stop, but so far z/ OS has never supported that. So for production z/OS guests, you really don't want to take page f aults. For test z/OS guests this may be tolerable. There is a CPU cost to running under z/VM, and reliability will be slight ly lower (?), so you have a trade off between storage savings and other overhead. Also, there is the problem of having yet another operating system, with d ifferent commands and different command syntax, for your operations staff to support. If they h ave no VM experience, then they are likely to oppose you. People who are used to all those comm as get very upset that VM does not use them! Tuning another operating system may also be a probl em for your performance or capacity planning people. We use z/VM to run large numbers of DR and system test z/OS guests. We do not run z/OS production that way. (It somewhat depends on whether you consider DR to b e production or test.) Generally, each group (for example the IMS group, the DB2 group, the z/OS group, etc.) has its own set of z/OS test guests. This has the big advantage that when the pho ne rings and the system programmer has to "leave" to fix a production problem, he (or she) doesn' t lose his (or her) test shot -- when they come back, the guest is waiting where they left off. Mo st of the pages are paged out, so they don't cost much. (Even an "idle" z/OS guest consumes cycles, alas.) Similarly we have DR guests corresponding to real z/OS LPARS. We use Capa city On Demand to add processors when we are going to run a DR test with large numbers of g uests all active at the same time. Another advantage of using VM is that the systems programmers can perform their tests (including "destructive testing") during regular business hours, instead of having to come in nights and weekends for test shots. That saves us quite a bit of overtime. Our D R tests are still run mostly on weekends (the limitation is the number of tape drives, not CPU cycles).
