Right. It is not a price difference, it is a resource difference.
Less LPARs (down to 1) vs more LPARs: Less copies of VM running (along with all the service machines) a couple 3390 drives (still may need the same total number of paging/spool packs as well as SFS packs) Less real memory resident due to less copies of VM and service machines. (Letting VM manage the memory vs the fairly non-dynamic way LPARs obtain memory) Less real memory wasted that is needed for lessor used LPARs. Less consoles needed and needed to be monitored. Of course, there are good reasons for having LPARs. In this shop, we were forced into it due to having an IFL engine. I might go back to 1 LPAR for all 390 images and production zLinux images. Occasionally each LPAR starts paging, at different times (for somewhat valid reasons, sometimes not <G>). But then, no one notices enough to complain. The DS6800 can easily handle a few hundred page I/O per second without users complaining. Then things settle down to our normal couple page I/Os per second and life goes on. Nice that VM got back to being able to schedule based on engine type, like VM/SP did <G>. (Yes, I assume that scheduling is much different/better then the old days of VM/SP.) Anyway, I've been thinking about Linux pricing, that is, per engine pricing. Currently, we are being charged based on our single IFL engine. And since the IFL engine was alone in its own LPAR, that would be reasonable. But now, if we mix a 390 engine, with the IFL engine in the same LPAR, would CP sechedule Linux work on a 390 engine (assuming 390 engine wasn't too busy)? Then, would we be in violation of our licensing agreements? I sure wouldn't want to pay full engine price for a 89 MIP, 390 engine <G>. Tom Duerbusch THD Consulting Law of Dinner Table Attendance Cats must attend all meals when anything good is served. >>> Alan Altmark <[EMAIL PROTECTED]> 8/5/2008 3:35 PM >>> On Tuesday, 08/05/2008 at 04:14 EDT, Tom Duerbusch <[EMAIL PROTECTED]> wrote: > 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? Measure. Change. Measure. Compare. But I should mention that when running z/VM in a z/VM LPAR, the license fee is based on the total number of standard CPs and IFLs in the CEC. If you already had z/VM on the CP side and the IFL side, then there's no diff in price. Alan Altmark z/VM Development IBM Endicott
