Reduce numbers, maybe, but we will never get it down to one. There are requirements for separating production from development that will prevent it. There are, understandably so, very strict prohibitions against mixing the financial network and the testing and development network. Those prohibitions do not allow them to be connected to the same LPAR, even if they use physically separate OSAs (which they do), attached to different users (which, if it were allowed, would be the case). Furthermore, the SLAs are such that it is unwise to put the production Linux machines under the production z/VM system which supports a special TPF machine. Their outage window requirements, and therefore their SLAs, are incompatible. That leaves us with at least 3 LPARS plus whatever is needed for native TPF test systems. So far, I think that the largest native TPF configuration we have run is 3 LPARS, 2 on the same CEC as VM plus 1 on a different box. So our net gain would be the possible elimination of one LPAR. But even that will evaporate next year, when the second Linux LPAR becomes production.
Do I hear some humming Perry Como's theme song in the background? Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch > Sent: Tuesday, August 05, 2008 1:13 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > As now, we can mix and match 390 engines with IFLs (and other > engine types) in the same LPAR, it might be good to reduce > the number of LPARs back to 1. You gain the memory used by > the other copies of VM, and you only need to add memory to > the LPAR when you buy more memory. > > I do know there are reasons for having multiple LPARs, but > now with mixing engine types, there is 1 less reason. > Everything under vswitch, and no hipersockets. Is that a > performance benefit? > > Now...how about basic mode again? <G> > > Tom Duerbusch > THD Consulting > > >>> Mary Anne Matyaz <[EMAIL PROTECTED]> 8/5/2008 12:25 PM >>> > Uh, I've never seen Linux use LESS memory. It always wants > more. :) I'm happy with the ability to add memory. > MA > > On Tue, Aug 5, 2008 at 12:58 PM, Schuh, Richard > <[EMAIL PROTECTED]> wrote: > > > Yes, it can add, but not subtract without LPAR deactivation. Let me > > know when the ability to dynamically remove previously > added storage > > is available, and I will be more enthusiastic. > > > > Regards, > > Richard Schuh > > > > > > >