Recommendations on VM memory allocation General/Hyper-V

Question

I've got a basic question on VM setup. I'm using Hyper-V, but I think the question is pretty generic. This is for a home office, I want to get reasonably good performance on the VMs without a lot of work. I use the VMs for testing/debugging my software. Ideally I would have all of the OS's started, but only one (probably zero most of the time) would be getting active use at a time.

Are there some general guidelines for memory allocation to VM's? On one extreme, you could divide the total memory by the number of VM's (4 GB total, 4 VM's -> 1 GB each). At the other end of the extreme you could give every VM full memory and let the OS arbitrate. I would guess both are wrong! I'm looking for a "rule of thumb" for reasonable performance. I have no idea how the VM server manages memory for the VM's.

[edit] I asked this question because I incorrectly assumed that Hyper-V (2008 R2 version) could dynamically provide additional memory to VMs if additional was available. My thought was that I could over allocate the memory, as long as my usage only peaked one VM at a time. Since Hyper-V wants to allocate the fixed memory for each VM when they are started, I need to either have some VM's shut down and only run the ones I need, or set the VM's to lower memory allocations and make sure the physical memory is enough for all of the allocations plus the Hyper-V process and (possibly) the host OS.

It sounds like VMWare has more options along these lines, as noted in the answers provided. [/edit]

Thanks, Brett

Answer 1

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.

Answer 2

It's not a generic question because Hyper-V can't do memory page sharing as VMWare can, that technology can enormously change the way in which VM memory is allocated. If Hyper-V supports it I would suggest you allocate your VMs a starting amount and then look at actual usage over time per VM, altering allocation as you discover more about its behaviour.