Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer
    
Nice concise definition of Transparent Page Sharing and Memory Ballooning (terms I was unfamiliar with). "Couple if hundred meg of RAM", "Linux compact distros with 30Meg" is more what I was looking for. If you allocate the minimum, it seems like there ought to be a way to "pool" additional resources for the various VM's to use first come first served? I found the Performance Tuning Guidelines for Windows Server 2008 R2 (microsoft.com/downloads/…). I will see what I can glean from that. –  Brett Stottlemyer Jan 23 '10 at 18:57
    
I've added some more detail on the minimum\pooling idea, not an answer for what you're looking for though unfortunately. –  Helvick Jan 23 '10 at 19:36
    
Thanks for the edit. I had just read that myself, I think it helps the answer to have that posted here. –  Brett Stottlemyer Jan 23 '10 at 20:13

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.

share|improve this answer
    
Ok, I understand the need to monitor and iterate to optimize based on real world performance. However, you do need a starting value which is what I was looking for. Thanks for pointing out that my question is specific to Hyper-V. –  Brett Stottlemyer Jan 23 '10 at 18:59

Hyper-V in Windows Server 2008 R2 does support a Dynamic Memory feature (I'm running SP1 - not sure if it was in the RTM version). I realise your question is quite old so it probably didn't when you asked it.

I started out allocating static memory to each guest VM, but quickly maxed out my server. Dynamic memory lets you assign an initial (perhaps low) amount and a maximum amount per VM. It will then allocate memory on demand and will also recover unused memory. You have to edit each VM's settings to set this up - it's not available when creating a new VM. I've just reconfigured a bunch of VMs to use Dynamic Memory and reduced my overall memory commitment by nearly half.

Hyper-V Manager screenshot showing assigned memory

The VMs which I have configured for Dynamic Memory show the current memory demand and status. The highlighted VM is still running within its initial allocation of 1 GB. The Exchange server (second from top) is a big fat pig and has blown its initial 1GB and been allocated a couple more. The feature allows for a configurable buffer (20% by default) so Hyper-V has given Exchange the amount it demands plus some extra.

share|improve this answer
    
There are many drawbacks to using Dynamic Memory, it's generally recommened against unless you really know what you're doing. Running Exchange with Dynamic Memory is a pretty bad idea as both IIS and the Jet DB Engine do their own memory management that will be completely screwed up by changing memory amounts. Other processes do similar things... –  Chris S Jan 10 '13 at 14:58
    
Hi Chris S. It's been working perfectly so far. You don't say what the drawbacks are, so I can't confirm or deny them. No issues to report so far. Will come back and update if the server melts or something. It seems that the feature still isn't supported for Linux guests though - they only take the initial allocation and never request more. :-( Only tried CentOS 6.3. –  robaker Jan 22 '13 at 9:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.