Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Extreme Memory Oversubscription for VMs

Laxitive (10360) writes | more than 4 years ago

4

Laxitive (10360) writes "Virtualization systems currently have a pretty easy time oversubscribing CPUs (running lots of VMs on a few CPUs), but have had a very hard time oversubscribing memory. GridCentric, a virtualization startup, just posted on their blog a video demoing the creation of 16 one-gigabyte desktop VMs (running X) on a computer with just 5 gigs of ram. The blog post includes a good explanation of how this is accomplished, along with a description of how it's different from the major approaches being used today (memory ballooning, VMWare's page sharing, etc.). Their method is based on a combination of lightweight VM cloning (sort of like fork() for VMs) and on-demand paging. Seems like the 'other half' of resource oversubscription for VMs might finally be here."
Link to Original Source

cancel ×

4 comments

Sorry! There are no comments related to the filter you selected.

Over commit is great (0, Flamebait)

nurb432 (527695) | more than 4 years ago | (#33209892)

until your VM's need the resources, then you are hosed and look like an idiot.

Re:Over commit is great (2, Informative)

Laxitive (10360) | more than 4 years ago | (#33210060)

Well, not really. It's the same as operating systems 'overcommitting' memory by giving each process a full virtual address space and filling it on the go. Operating systems solve this problem by... well.. using paging.

The paging approach works well for systems where you expect the in-memory working set to be tight. Mainly you'll see a graceful degradation in performance as you actually start hitting real memory limits and paging comes into effect.

Eventually, I think that can be resolved by taking a hybrid approach: wait until memory pressure builds and paging hits performance more than you'd like, then auto-migrate machines off the host as necessary. You get the best of both worlds: oversubscription when resource usage is low and performance is not affected, and on-demand resource allocation when resources are known to be needed.

-Laxitive

Re:Over commit is great (1)

ToasterMonkey (467067) | more than 4 years ago | (#33211488)

The paging approach works well for systems where you expect the in-memory working set to be tight. Mainly you'll see a graceful degradation in performance as you actually start hitting real memory limits and paging comes into effect.

Graceful? Without ballooning, your whole application's resident set might be swapped out by the VM host. Anyway, I don't think anyone here can say with a straight face that swapping to disk degrades performance _gracefully_. We've all used a system from the Win9x times haven't we?

wait until memory pressure builds and paging hits performance more than you'd like, then auto-migrate machines off the host

That should happen before the host runs out of memory, or very soon after. The other thing is why wouldn't you do this waaay in advance if you have a node who's memory is not overcommitted, and a node that is. All nodes are overcommitted? Then you are basically screwed if you need to evacuate all VM's from a node at once due to failure.

Memory overcommit is just a dangerous game man. I'd only use it in the case where you provisioned resources for X physical node failures, and you have X+ failures. No other choice, and temporary.

Re:Over commit is great (1)

fR0993R-on-Atari-520 (60152) | more than 4 years ago | (#33212046)

wait until memory pressure builds and paging hits performance more than you'd like, then auto-migrate machines off the host

That should happen before the host runs out of memory, or very soon after. The other thing is why wouldn't you do this waaay in advance if you have a node who's memory is not overcommitted, and a node that is. All nodes are overcommitted? Then you are basically screwed if you need to evacuate all VM's from a node at once due to failure.

Memory overcommit is just a dangerous game man. I'd only use it in the case where you provisioned resources for X physical node failures, and you have X+ failures. No other choice, and temporary.

But the demo is showing over-provisioning of desktop machines. Seriously, what enterprise sysadmin cares if it takes an extra two seconds for PowerPoint to load on a user's VDI VM?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>