VM suddently stop due to out of memory

[Mirmanium]

Hello,

I have some virtual machines in my node and I realized something weird happen when I try to run more than 3 at the same time.
I guess this is because the 4th one just needs more RAM memory than available but weird part is randomly proxmox stop some of the running ones instead of notifying not enough memory to run the 4th one.
Once I have the 4th up and running if I want to start the one suddently stopped, another different one is stopped (I don't know the sequence/order proxmox follow to randomly stop one of the running ones).
Does it happen only to me or is this just the way proxmox handles when running out of memory?

Thank you,

 

[aaron]

If there is not enough memory available, the Linux OOM (out of memory) killer gets active and selects a process to be killed. Usually this ends up being a VM as they consume a lot of RAM.

In order to avoid this, do not over provision the available RAM and leave a bit free for the host when calculating the RAM available for the guests.

 

[Mirmanium]

Ok, thanks for the advice @aaron.
However, it still sounds weird to me no simple pop-up message to appear warning it and decide to continue or not. It is really easy to forget about it once start a VM that another one will be killed due to OOM.

 

[babla]

Hello, back on this topic as I have recently experienced a similar matter, even though I was expecting some VMs with baloon option on to automatically scale down the memory.

I am running PVE 7.2-11

Is there any option or flag to the VM configuration to set a priority order of killing the process or set a non turn off flag?
Initially I thought that is the "protection" option for, but it seems to not be the case.


Thanks!

 

[Dunuin]

Is there any option or flag to the VM configuration to set a priority order of killing the process or set a non turn off flag?
Initially I thought that is the "protection" option for, but it seems to not be the case.

No. Just stop overprovisioning your RAM

 

[babla]

No. Just stop overprovisioning your RAM

Reasonable, but I think it would be an interesting feature of PVE to block you starting a VM if it will overprovision RAM, instead of randomly stopping someting that could be critical - such a router of access gateway...

PVE developers, any chance something like this to be implemented or possible from a technical point?

 

[aaron]

I thought that is the "protection" option for, but it seems to not be the case.

As a general hint if you are unsure what an option does, click on the nearest help button (either in the pop up window you are currently in, or usually in the top right) and then, if you don't see it right away, search for it. In the case of the "protection" option you should get to this part of the documentation:

protection: <boolean> (default = 0)
Sets the protection flag of the VM. This will disable the remove VM and remove disk operations.

Regarding memory overprovisioning: It is hard to determine how much RAM other VMs will be able to free up and how much the starting one actually needs if many of them do use memory ballooning. The situation is very dynamic and hard to predict.

I cannot promise anything, but with the groundwork getting into place (for example the CRS in the latest 7.3 release), there might be some improvements in the future, especially for clusters.

 

[babla]

As a general hint if you are unsure what an option does, click on the nearest help button (either in the pop up window you are currently in, or usually in the top right) and then, if you don't see it right away, search for it. In the case of the "protection" option you should get to this part of the documentation:


Regarding memory overprovisioning: It is hard to determine how much RAM other VMs will be able to free up and how much the starting one actually needs if many of them do use memory ballooning. The situation is very dynamic and hard to predict.

I cannot promise anything, but with the groundwork getting into place (for example the CRS in the latest 7.3 release), there might be some improvements in the future, especially for clusters.

Thank you for your answer on this matter, aaron. Cheers!