I am used to work with FreeBSD jails but I wanted to give a try to XenServer 5.5 / Vmware ESXI 5, hoping it can really limit resources per VM, after installing a couple of Virtual Machines, I tried to execute on one small VM (512RAM, 1 VCPU), (server has 8GB ram 2 processors) the following code:
$ cat > fork.c
#include <stdio.h>
int main() { while(1) fork(); }
$ gcc fork.c -o bomb
$ ./bomb
On a FreeBSD server with out virtualization (no Xenserver/Vmware) that code will kill the machine and a hard reset needs to be done, but I was surprised that on XenServer the behavior is "almost" similar causing some damage.
The XenServer started to consume all the CPU available, and the other FreeBSD VM start to have poor performance.
On the other hand, using the latest version of Vmware Exi, the bomb only affected the Virtual machine that fired the fork bomb, the CPU for the full server did not start consuming all the resources, just approximately 40% of it, at a point that it allow me to create a second VM and run a second bomb on it, with out noticing performance on the rest of the VM. Having 2 bombs running at the same time the total use of CPU was of 90%.
In my case I just use FreeBSD but still haven't found away to prevent a fork bomb that can kill the host server, using XenServer did not help much. Vmware looks promising but is out of question because of the cost.
So, any idea of how to fine tune Xenserver or Freebsd to handle fork booms ?
You can effectively prevent fork bombs even on a physical machine with user limits. On FreeBSD, one way to configure this is in
/etc/login.conf
, with themaxproc
parameter.For more infos, refer to the documentation here.
Edit: If this isn't sufficient, you should be able to keep at least the XenServer running with limiting the CPU time any VM can get. See the sections on VCPU params in the Xen CLI doc here.
Limiting the VCPU helped but now i am facing another problem:
how to force stop/delete a VirtualMachine under XenServer (possible bug)
I can't delete/stop/restart instances that contain a customized FreeBSD Kernel (xen options), some how XenServer when booting this kernels looses control of the instance.
update
This fixed the problem: rctl -- display and update resource limits database