Could approach this like this as well:

Make your XP VMs, "give" them 2G of memory, but set a limit of 512M.

This a) appears to the guest that they have 2G of RAM, b) allows the hypervisor to allocate less resources to that guest (and TPS can do wonders here), and c) if a user complains about a slow machine, you can dispense the resources as you see fit up to 2G.

It's a pump fake, yes. But I subscribe to the school of "If my users are complaining that they're using 95% of the resources I've given them, I've given them 5% too much".

Good luck!
- Abe

Integritas!

Abe Lister

Just some guy that loves to virtualize
==============================
Ain't gonna lie. I like points. If what I'm saying is something useful to you, consider sliding me some points for it!

Really? I'm pretty sure that I read an article that setting a limit below the allocated amount could cause major performance issues based on how ESX handles this setting. I'll have to research it again, this was a while back.

I saw this in one case myself. I limited a server that was allocated 2.5 GB to 2 GB and performance plummeted even though the machine wasn't actually even consuming 2GB.

Here it is:

Vmguru article

I think that ultimately the scenarios where the unlimited thick box should be "unthicketed" are very niche compared to scenarios where you want it to be "thicketed" and perhaps reserve 50% or 33% (examples) of the assigned + shares to do the VMs ranking.

At the end of the day you want the ultimate "limit" to be the pRAM installed in the box vs a hard set limit on specific VMs (unless you are 100% sure that you won't use more than the reserve you specified (but if you are 100% sure why thicking it anyway as it's the end-user software that is going to limit itself).

I totally agree that this needs to be taken with a grain of salt. There are applications (SQL for example) that will tend to use all the memory that they see no matter what (and that's the assigned.... not the reserved). If all VMs are using software that behaves like this you'd better not even overcommitting memory...

Massimo.