Use of memory ballooning for pruduction environment

agapitox

Renowned Member
Dec 3, 2008
24
1
68
Zaragoza, Spain
Hi promox,

I have previously managed virtualization environments with hyper-v and VMware.

In these I always had as a recommendation or good practice not to use ballooning memory as much as possible in production environments.

We only used it for test environments or when the host was very limited in resources.

Generally, this was because of the possible performance losses in the vm's. Especially in applications that have integrated memory management like Java.

However, within my team we have a discussion because in the Proxmox VE documentation, it says that balloning memory usage has no impact on vm's. We can be satisfied with this.

Can you tell us what the best practices are in this regard?

To put you in situation our hosts use zfs with the limit at 16gb, and host vm's with centos with the qemu-guest-agent configured.

Thank you very much, I look forward to hearing from you.
 
You have to ask a clear question, otherwise no one can answer.
 
Thanks,

basically, if it is advisable or not to use memory ballooning, by default in all vm's. Especially for production environment
Follow the documentation, if you see issues, disable it and test again.
 
Follow the documentation, if you see issues, disable it and test again.
Yes, the documentation is read... I refer to it in the first message.

However, I was expecting a more convincing answer. I really remain the same. I don't know what the recommendation is apart from the typical: turn it off and on again.

Thank you.
 
I cannot give you guarantees or an official statement, but this is my personal opinion and experience on the matter: There are no known issues with having the ballooning systems enabled on the host and running in the background. There are also no known issues with Linux VMs, which have this automatically supported in the Linux kernel. There have been reports about Windows VMs, where you need to install a VirtIO driver to get support for ballooning, about reduced performance when actually using it.

Whether you actually enable the use of ballooning can be decided per VM. Therefore, I would suggest to try it with some of your VMs to see if it improves things. As it can easily be turned off without reboot per VM (set the minimum memory equal to the maximum), I don't see any risks from having ballooning supported in production environments. I believe enabling ballooning of one VM should not interfere with ballooning for another VM, unless you need ballooning because you over-commit on memory. That will cause trouble if you cannot ensure that the VM don't try to use all memory at the same time, and is bad practice for production anyway.

I'm not sure what you would consider a convincing answer from a random stranger on the internet? If you don't need ballooning in production, why enable it for any of your VMs? If you have had some issues with ballooning with some kinds of workloads, I would suggest not using it for those workloads.
 
I often had issues with the VMs not seeing all the available memory and that would lead to OOM. Also, if the minimum limit is too low, the VM might not even boot and get into kernel panic directly, as the virtual machine might see only that minium available memory, which I actually don't understand. But maybe I don't fully understand the technology. I've generally avoided it because of these experiences, but I would like to be proved wrong.
 
Last edited:
I'm in the process of migrating production Linux VMs (don't run any Windows VMs) from ESXi to Proxmox. The Linux VMs always were always running latest version of open-vm-tools.

I never did turn off ballooning under ESXi because I never had issues. Now the Linux VMs are running under Promox with latest qemu-guest-agent software with ballooning enabled on by default and again no issues. Quite a few of the VMs are Java application servers. Again, no problems.

Since every organization is different, one should run stress tests and see if things break running under a new virtualization environment. I'm sure there are plenty of tools out there to stress test VM breakage.
 
  • Like
Reactions: lethargos
I often had issues with the VMs not seeing all the available memory and that would lead to OOM.
Yes, thats how ballooning works and expected behavior when overcommiting RAM.

Once hosts RAM exceeds 80% it will steal RAM from all the VMs until either hosts RAM drops below 80% again or till all VMs RAM reached the "min RAM" value. The VM is "not seeing all the available RAM" because the RAM isn't available. What you see is all the RAM the VM got left after it got stolen and added to the host. Ballooning won't care if the VM actually needs that RAM or not. It will simply remove it from the VM and the VM has to handle it. This usually means the VM will kill important processes once there is no more cache available that could be dropped. If you don't want your guestOS to kill stuff don't enable ballooning or make sure that the "Min RAM" is higher than the amount of RAM the guestOS needs at maximum as all times. If your guestOS peaks (without cache) at 8 GB RAM usage, don't set the "Min RAM" lower than 8GB. Don't overcommit your RAM. If you do, with or without enabled ballooning, something might be killed. Either whole VMs by the host that is running out of RAM when disabled or services by the guestOS when the VM is running out of RAM when enabled.
Ballooing is more useful if your host got too much RAM and you don't want to waste it by not using it. So when a VM would run perfectly fine with static 8GB RAM, you could set "Min RAM to 8GB and "Max RAM" to 12GB, so the VM could use the additional 4GBs of RAM for caching instead of the host wasting it.
 
Last edited:
  • Like
Reactions: UdoB
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!