Well, only if the server uses them. If you have a 1.5G server and it is using 1.5 Gig of swap space in VDISK then it is an impact of 3G virtual, right? If you have a 1.5G server and it is not swapping, it's impact is 1.5G virtual.
So maybe more like (sum (guest virtual storage sizes) + sum (*used* vdisk blocks) ) / central storage. Wouldn't that be pretty simliar to number of pages on DASD method? Expanded storage? Add it to central? Nothing's simple anymore :) Marcy Cortes "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." ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Robert J Brenneman Sent: Monday, May 12, 2008 9:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Overcommit ratio Errr... yeah - them too... The problem will be when you've allocated huge vdisks for all your production systems based on the old "Swap = 2X main memory" ROT. In that example - you're basically tripling your overcommit ratio by including the vdisks. This also can have a large cost in terms of CP memory structures to manage those things. The current guidance is a smallish vdisk for high priority swap space, and a largish low priority real disk/minidisk for occasional use by badly behaved apps. Swapping to the vdisk is fine in normal operations, swapping to the real disk should be unusual and rare. So - overcommit ratio is calculated as follows: ( Sum ( guest virtual storage sizes ) + Sum ( vdisk sizes ) ) / central storage Anything else I've forgotten? -- Jay Brenneman
