Projects/auto-ballooning: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed. | This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed. | ||
The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again. | The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again. | ||
That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice. | That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice. | ||
The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning | The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does. | ||
=== KVM Forum 2013 presentation slides === | === KVM Forum 2013 presentation slides === | ||
They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here] | They can be found [http://www.linux-kvm.org/wiki/images/f/f6/Automatic-ballooning-slides.pdf here]. But note that much has changed since this talk. | ||
== | == Patches and Git trees == | ||
=== Latest RFC version posted upstream === | |||
'''Guest kernel:''' [http://marc.info/?l=kvm&m=138988948715638&w=2 [RFC PATCH 0/4] virtio_balloon: add pressure notification via a new virtqueue] | |||
'''QEMU:''' [http://marc.info/?l=kvm&m=138988966315690&w=2 RFC PATCH balloon: add automatic ballooning support] | |||
= | === Git trees === | ||
== Git trees | |||
'''Guest kernel:''' | '''Guest kernel:''' | ||
git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/ | git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/pressure-notification/rfc.v1 | ||
'''QEMU:''' | '''QEMU:''' | ||
git://repo.or.cz/qemu/qmp-unstable.git balloon/ | git://repo.or.cz/qemu/qmp-unstable.git balloon-automatic/handle-all-events/rfc.v1 | ||
== Testing == | == Testing == | ||
Revision as of 15:23, 16 January 2014
Automatic Ballooning
Introduction
The balloon feature allows KVM guests to reduce their memory size (thus relinquishing memory to the host) and to increase back (thus taking memory from the host).
This feature is mainly intended to support memory over-committed hosts. That is, hosts that are running VMs whose total memory size is greater than what the host has physically available. For example, a 2G host running two VMs each with 2G would be over-committed.
The balloon feature is important to support memory over-commitment because it allows for reducing a guest's memory size if needed. Suppose, in the example above, that one of the guests is using 1G and its other 1G is free. We could use the balloon to reduce this guest's size from 2G to 1G, this would free 1G in the host allowing the other VM to use it. Of course, if the reduced guest wants to run an application that consumes more than the 1G it currently has, it has to grow again.
That's the problem with the current balloon feature, it's entirely manual. Someone (or some tool) is supposed to be watching the pressure in the host and guest and then operate the balloon accordingly. This is just not doable in practice.
The balloon has to be automatic in order to be really useful. It could like this: when the host is under pressure, VMs with spare memory automatically reduce their size by some megas. When a VM get into memory pressure (maybe because they relinquished memory to host) it increases its size by some megas. That's exactly what the automatic ballooning patch series does.
KVM Forum 2013 presentation slides
They can be found here. But note that much has changed since this talk.
Patches and Git trees
Latest RFC version posted upstream
Guest kernel: [RFC PATCH 0/4 virtio_balloon: add pressure notification via a new virtqueue]
QEMU: RFC PATCH balloon: add automatic ballooning support
Git trees
Guest kernel:
git://repo.or.cz/linux-2.6/luiz-linux-2.6.git virtio-balloon/pressure-notification/rfc.v1
QEMU:
git://repo.or.cz/qemu/qmp-unstable.git balloon-automatic/handle-all-events/rfc.v1
Testing
You have to setup the following before experimenting with auto-ballooning:
- Install kernel 3.10 or higher in your host. Make sure the kernel options CONFIG_CGROUPS and CONFIG_MEMCG are enabled
- Build and install QEMU from the Git trees section (suggest the RFC one)
- Build and install the guest kernel from the Git trees section (suggest the RFC one)
After setting up the above, do the following to experiment with automatic deflate:
- Pass -balloon virtio,auto-balloon=true when starting QEMU
- Wait for the guest to boot, then generate some memory pressure in the guest (say a kernel build with lots of jobs)
- Switch to QEMU's monitor and shrink the guest (say from 1G to 200MB)
- Watch the guest increase its memory by running "free" within the guest (or "info balloon" in QEMU)
There are two ways to play with automatic inflate:
- The simplest thing is to create a memory constrained cgroup, but this will require code changes in QEMU because it's hardcoded to use the root cgroup (yes, we need a command-line option for that)
- If you don't want to play with cgroups, you can overcommit your host by running several VMs in parallel. The VMs have to run a heavy memory workload