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

Reply via email to