Virtualisation on Linux
Posted: Sun Apr 19, 2020 10:14 am
Hi all
Just posting some notes which might be of assistance to anyone else with some spare (server?) compute power thinking about a virtualised FAH container or more.
We're now running 4 of these, 2 using OpenVZ and 2 using LXD. Both work like a charm. Our flavour is Debian but I don't think this will affect things much. You need only install fahclient (see instructions for headless / terminal install) and ensure that your config.xml is set up to allow specified external, public IP(s) to access your container(s) on port 7396. Then you can remote admin from your specified location(s). Using a VPN and a smart phone, I can then tweak this from anywhere. Cute.
Some notes: the FAH stats get confused by the number of cpu cores in some cases. OpenVZ actually gets it right, perversely the more modern LXC/LXD containers are reported as having all available cpu cores available even when this is not the case.
On OpenVZ you can set a limit to available cores using % vzctl set <VEID> --cpus <n> % --save - substituting your own values for <VEID> and <n> of course.
On LXD you use % lxc config set <container name> limits.cpu <n> % - again substitute your preferred values.
Also, FAH stats reports the number of CPUs in use per host machine - we have multiple instances of LXD containers on the same host - some experimentation revealed that this seems to be a more efficient implementation than assigning more cores to fewer containers. 4 cores seems to be optimal if you can achieve it.
Finally, we ensured lm-sensors (Debian, YMMV) was installed on each host (don't forget % sensors-detect % to set things up) and then the command % sensors | grep Core % provides an immediate indicator of how you're "cooking" your CPUs.
Happy to discuss finer points with anyone else who has a rack or two of servers with surplus capacity as did we... PM me!
Just posting some notes which might be of assistance to anyone else with some spare (server?) compute power thinking about a virtualised FAH container or more.
We're now running 4 of these, 2 using OpenVZ and 2 using LXD. Both work like a charm. Our flavour is Debian but I don't think this will affect things much. You need only install fahclient (see instructions for headless / terminal install) and ensure that your config.xml is set up to allow specified external, public IP(s) to access your container(s) on port 7396. Then you can remote admin from your specified location(s). Using a VPN and a smart phone, I can then tweak this from anywhere. Cute.
Some notes: the FAH stats get confused by the number of cpu cores in some cases. OpenVZ actually gets it right, perversely the more modern LXC/LXD containers are reported as having all available cpu cores available even when this is not the case.
On OpenVZ you can set a limit to available cores using % vzctl set <VEID> --cpus <n> % --save - substituting your own values for <VEID> and <n> of course.
On LXD you use % lxc config set <container name> limits.cpu <n> % - again substitute your preferred values.
Also, FAH stats reports the number of CPUs in use per host machine - we have multiple instances of LXD containers on the same host - some experimentation revealed that this seems to be a more efficient implementation than assigning more cores to fewer containers. 4 cores seems to be optimal if you can achieve it.
Finally, we ensured lm-sensors (Debian, YMMV) was installed on each host (don't forget % sensors-detect % to set things up) and then the command % sensors | grep Core % provides an immediate indicator of how you're "cooking" your CPUs.
Happy to discuss finer points with anyone else who has a rack or two of servers with surplus capacity as did we... PM me!