1. The memory used by Portal can never be swapped; either at the guest or at the hypervisor level.
In a VMWare (or any virtual hosted environment), there is a belief that by sharing resources like CPUs and memory, you get better financial returns. However, because Portals are generally operating under committed SLAs (Service Level Agreements) that guarantee peak response time and load metrics, you have to size the guest resources assuming that they are dedicated. VMWare administrators will typically look at coarse grained usages statistics which average out these peak demands and under-size the dedicated CPU requirements. In VMWare, you need to allocate dedicated, non-sharable CPUs and physical memory to each Portal guest. Note that this also dictates that a running Portal should never be allowed to "vMotion" to another server; vMotion implies both CPU and memory movement which is strictly contrary to performance goals.
2. Prefer only 1 cluster member per Node (i.e. VMWare guest OS). Because of both virtual context switching in the guest along with real context switching in the hypervisor, there are efficiencies in only having 1 active JVM in a VMWare guest.
3. Two virtual CPUs on a production VMWare guest serving any sizeable load is likely insufficient. Because of multi-threaded garbage collection along with multi-threaded workers in Java (a.k.a. "WebContainer" threads), two CPU are generally insufficient to meet most production load requirements. In practice, we've found that a minimum of 4 CPUs per guest with a single cluster member in the guest a requirement.