There is also that intangible factor of how each of those 4GB guests make use of memory.. combine that with use of VDISK for things like Linux swapping ... another unpredictable.
That's why 'how many xxGB guests can I run within the maximum architectural limits' isn't really answerable.. all you can really do is come up with a worst case value and estimate. Yet another factor is your willingness to suffer poor performance .. overcommit to 5x and if response times are acceptable -- than you can have twice as many guests running than with an overcommit of 2.5x. (and yes - you need the paging space available to support those overcommit levels) Anyway - unless all those 4GB guests are doing exactly the same thing, and accepting work at exactly the same rate - the number you can support isn't really predictable except within some broad ranges. Cost effective virtualization sort of depends on the hypothesis that there is usually a natural disparity of work between guests moment to moment. Ideally - the peaks and valleys of activity all average into that 'sweet spot' plateau we are all searching for. So - 4 paragraphs to say 'it depends' again. :-) Friday night and time for a nightcap and some sleep.. dreaming of dolphins and swimming after imaginary numbers. Good discussion, I think -- nite all - Scott Rohling On Fri, Oct 1, 2010 at 7:06 PM, Phil Smith <[email protected]> wrote: > Gary M. Dennis asked: > >If the volume limit for a z/VM page volumes is 240+, how does this relate > to > >maximum defined virtual storage for all active guests under a z/VM image? > > Well, in theory, I guess it's > (real storage)+(page space)-(real system requirements) > but that's cutting it close to the line. So it's more like > (real storage)*n > where n is the overcommit ratio, as Scott Rohling indicated -- likely no > more than 3x in production, probably closer to 2x. > > If you're thinking "Ginormous zEnterprise with 3TB of real and one z/VM > system", do the math: > 240 x 48GB* = 11TB, if I'm doing it right. So you're "OK", FSVO "OK". > > Let us know how that baby runs, eh? > > ...phsiii > > * 48GB = 65530*180*4096 >
