Forgot your password?
typodupeerror

+ - Extreme Memory Oversubscription for VMs-> 4

Submitted by Laxitive
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
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

Extreme Memory Oversubscription for VMs

Comments Filter:
  • by nurb432 (527695)

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

    • Re: (Score:3, Informative)

      by Laxitive (10360)

      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 hybri

      • 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 ov

        • 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?

In order to dial out, it is necessary to broaden one's dimension.

Working...