As a general rule you want to know that under worst case conditions there is just enough physical RAM for all the standard functions to operate reliably from RAM. What that magic number is varies from OS to OS and varies widely depending on the uses you put the guest OS to. You can happily boot a Windows 2003 Server with a couple of hundred meg of RAM, some Linux compact distros with 30Meg or less and so on but if you want to run SQL Server in your guest with multi-gigabyte databases then you're going to want to make sure that it actually has real RAM backing up the couple of Gig of RAM it thinks it has.
How the Hypervisor handles RAM varies a lot between vendors and products. Hyper-V does not support what's called memory-overcommiting so you are limited to allocating RAM based on what you have physically available. VMware's ESX allows for over-committing, setting rules for contention arbitration (shares) in order to control what happens when the VM's get busy and the total amount of physical RAM is insufficient to meet the load. In a Hyper-V environment you don't have this level of control so you have to assign sufficient RAM up front.
VMware have a couple of other tricks to help with memory over-commit; Transparent Page Sharing and Memory Ballooning.
Transparent Page Sharing is basically single instance storage for RAM - the Hypervisor monitors the blocks of RAM allocated to each VM and if it finds common blocks exist in multiple VM's it only keeps a single copy and points all the VM's at that - if any VM subsequently attempts to write to that block it splits off a copy so that bad things don't happen. In a homogeneous VM environment this can save a fair amount of RAM without impacting perfromance.
Memory Ballooning is a mechanism that allows the Hypervisor to "borrow" RAM allocated to one VM and give it to a more important one by using a Guest OS driver in the former that allocates a (large) chunk of memory within that Guest. Once it is allocated the Hypervisor can safely reallocate the physical RAM backing the memory the balloon driver has allocated to it. The advantage of doing this compared to the direct approach where the Hypervisor just swaps the Guest VM's memory to disk in order to reallocate the RAM is that the Guest that is losing the physical RAM is aware that the memory is in use by something and there is a significantly reduced risk that the "borrowed" RAM will have been allocated to any important system functions within the Guest.
Edited to add:
I've never tried to see what happens with Hyper-V when you attempt to start up VM's that will take the memory requirements beyond the amount of physical RAM available, all the documentation I can find states that the VM's get all the RAM you have configured for them and then the Hypervisor and host OS get allocated what's left. Hyper-V does not have any mechanism to apply a minimum reserve of RAM to a VM, and then have the remainder allocated from a pool, although it does provide such a mechanism for CPU resources. Again VMware's ESX\ESXi does provide this option.
It's worth remembering that you also need to plan for the physical memory that is needed by both the Hypervisor and the host OS (disregard the latter if you are running the bare metal Hyper-V server).
Microsoft's performance tuning advice for Hyper-V states that in addition to the XGig of RAM you have in your VM's you need to have:
- 300 MB for the Hypervisor
- plus 32 MB for the first GB of RAM
allocated to each virtual machine
- plus another 8 MB for every
additional GB of RAM allocated to
each virtual machine
- plus 512 MB for the host operating
system running on the root partition
If you don't have enough physical RAM for these then performance will be seriously affected, and possibly stability too.