We're not hitting the storage issues Jim and Rick are.  Our 4 6-engine LPARs 
are happily on 32G each with zero-little paging... long way to go as far as 
running out of storage.  And that may be because we have some CPU intensive 
workload skewing us the other way.  We also squeeze and tune like crazy our 
test/dev environments because they are traditionally short changed on storage 
... I think at one point we were 5-6:1 on dev/test (100 servers running on 24 
gig).  Better now, but still probably 2.5:1 at the moment (economies of scale 
play out.. Many devs groups can't all be active at the same time).

It is the administrative overhead of z/VM management that I am worried about.  
I have to justify that against whatever capacity is lost due to more 
systems/lpars.  Storage concerns aren't close to a concern yet.


Marcy 

"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."


-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Mark Post
Sent: Saturday, August 08, 2009 5:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] MP effect on z/VM Linux hosting

>>> On 8/8/2009 at 12:07 PM, Marcy Cortes <marcy.d.cor...@wellsfargo.com> 
>>> wrote: 
-snip-
> The real concern is whether to put 6 IFLS on 7 different boxes or do we lose 
> anything by having say 14 IFLs on 3 boxes or 10-10-11-11 on 4 boxes.

Based on what Jim Vincent and Rick Barlow have been saying for some time, and 
adding in what Barton Robinson just  wrote, I would say that you're likely to 
run out of real storage before you run into too much MP effect.  In your case, 
I would say you would need to balance the administrative effort of managing X 
z/VM systems on Y LPARs against how much real storage you need and how many 
CPUs you need.  I would personally tend to go with fewer "larger" z/VM 
instances, but that may not be a concern for you.


Mark Post

Reply via email to