There are a few best practice white papers out there which make valid points. However most of them are rosy in nature and written by VMWare with the desire to prove that you can host your J2EE app on ESX. Not all J2EE apps are the same, and VMWare never publish their JVM parameters in these white papers.
My experience is this:
1. Reserve the entire memory allocation and CPU resources for the VM. This stops the Balloning driver kicking in which is vital when the JVM manages your memory.
2. In Windows, use grouppolicy editor to allow the user running the JVM to lock large pages in memory. Then reboot the VM (people forget to reboot)
3. Remember what ESX does well. It allows you to overcommit memory. ie run VM's with more memory than the host contains. It does this by looking for pages that are shared between VM's. There is an algorithm to run round looking for potentially shareable pages based on hash values. If it finds two pages with the same hash, it inspects the memory to see if they can be shared between VM's. This is great for OS memory resident drivers and the like, but not so wonderful on a large constantly churning heap. These algorthms can be disabled in ESX, but only at the server level, not at VM level. Later versions of ESX seem to be better at this stuff. Maximum performance is achieved by disabling this, at the cost of loosing one of the great selling points of ESX.
4. In the white papers the marketing department often confuse SAN disks and multiple NIC's with VMWare. You can add SAN and NIC's to your physical server.
5. Lets assume you have tuned your J2EE app for some physical kit and then your customer decides to virtualise said hardware. You WILL need to re-tune your JVM parameters. There is no getting away from this unless your J2EE app is small and not very parallel.
e.g. on physical you may use parallel eden and tenured collectors and a huge heap with a 3/8th new gen guarentee. This will run X users at the required pace given Y cpu's and Z heap memory. If you virtualise this server, it will almost certainly perform like a stunned slug if Y > 2 and Z > 2Gb
Instead you will probably end up with a config where you scale horizontally with lots of VM's given 4Gb ram each, 2 cores each and run a serial collector with a 2GB heap. Add VM's until you achieve similar performance to the single physical server. You will benefit from DR (although if a VM ever moves between hosts, the response time will be terrible during the move), but you will have to pay for lots of windows licences/management vs just one on the physical server with lots of cores.
The upshot of this is, there are many J2EE apps that work very nicely on VMWare. If yours is not one of them, prepare yourself for a lot of time spent performance tuning for ESX. If you want to guarentee (as far as you can with Java) consistent performance then use physical hardware.
