Thinking About Cloud, Self-Service, and Hyper-V Dynamic Memory

I’ve been doing some thinking about how to configure Dynamic Memory (DM) in a Windows Server 2012 Hyper-V cloud.  One of the traits of a cloud is self-service.  And that’s why some thought is required.

If you’re not familiar with Dynamic Memory, then have a look at the paper I wrote on the feature as it was in W2008 R2.  Then take a few minutes to update your knowledge of the changes to DM in WS2012. 

I’ve previously stated that you had to be careful with the Startup RAM setting in a cloud/hosting scenario.  The guest OS can only see the high-water mark of allocated RAM since the VM booted up.  For example:

  • A VM is configured with 512 MB Startup RAM and 8 GB Maximum RAM
  • The VM boots up and the guest OS sees 512 MB RAM
  • The DMVSC integration component starts up
  • Pressure for RAM increases in the guest OS and maybe the VM increases to 768 MB
  • Pressure reduces and the VM is now using 612 MB

Imagine a customer who owns this VM, logs into it, downloads the SQL installer and runs setup.  Setup will fail because the installer requires 1 GB of RAM for SQL to run.  The guest OS can only see 768 MB – the high water mark since the VM booted up.  That’s a helpdesk call.  Now scale that out to hundreds or thousands of VMs.  Imagine all the helpdesk calls.  Sure; you’ve saved some money on RAM, but you’ve had to hire more people to close calls.  Trust me … no wiki or knowledge base article will sort it out.  I’ve been on the hosting service provider side of the fence and I’m a hosting customer too Smile

So my advice for W2008 R2 was to set Startup RAM to be 1 GB of RAM.  Sure, lots of VMs remain idle in a cloud – you’d be amazed how many might never be logged into, even if there is a monthly invoice for them.  You’ve reduced the helldesk calls but you’re still using up RAM.

Enter Windows Server 2012 Hyper-V (and Hyper-V Server 2012) …

We have a new setting called Minimum RAM, allow a VM to balloon down to below the Startup RAM when the VM is idle.  All that idle RAM returns back to the host for reuse.  How about this now:

  • The VM is configured with 1 GB RAM Startup RAM and 8 GM Maximum RAM
  • Minimum RAM is set to 256 MB
  • The VM powers up with 1 GB RAM, goes idle and balloons down to 320 MB RAM
  • After a week, the customer logs into the VM, attempts to install SQL Server.  The RAM high-water mark is 1 GB and the SQL setup has no problems.

No helldesk calls there!  And it’s done without the loss of performance associate with RAM over-commitment and second level paging.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.