I always found the Best Practices information interesting, because one performance tuning tip for MS SQL is that the box in general should have as much RAM as it would take to hold your most import/most accessed table entirely in memory. Following that recommendation, the amount of provisioned RAM can get quite large, and then if we follow the recommendation that we reserve all of it too... we're getting close to dedicating a host (or more than one if we're insuring that we have a host for this VM to vMotion to) to this MS SQL box. At that point, it seems to be sort of a toss up of whether you actually want a physical box instead.
In the past what I have done is to reserve 20% or more of the provisioned RAM. I get the 20% number pretty much by arbitrarily doubling the MS SQL recommendation for memory left out of Max Memory for the guest OS (90% for MS SQL; 10% for Windows). This has worked okay for me most of the time, though there have been occasions where more than 20% seemed to required to get/stay out of Swapping/Ballooning territory. Of course all of the above assumes over-commitment in the first place, etc...
IMHO, any number greater than zero can possibly be the right answer. I was just interested to see what others were doing.
