FAQ

FAQ

What is the difference between this and the VM autoscaler?

Different guest type, different mechanism. This daemon scales LXC containers through pct, reading cgroup counters on the host. proxmox-vm-autoscale scales virtual machines over SSH through qm, using hotplug and balloon. There is also proxmox-lxc-autoscale-ml, which drives LXC scaling with a model instead of thresholds.

Does it need LXCFS?

Not for normal operation. CPU and memory come from host-side cgroup accounting, which needs nothing inside the container. LXCFS only matters for the /proc/stat fallback, and then it needs the -l flag. See How usage is measured.

Does it run commands inside my containers?

No. Metrics are file reads on the host, and scaling goes through pct. That is why it works on containers with a minimal userland.

Can I use it without giving it root on the host?

Not really, today. The daemon drives pct and needs the privileges pct needs, which is root on the node. The non-root Docker path depends on the REST backend, and that backend is not connected to the running daemon, so configuring it that way yields a daemon that cannot act at all (#56). Config values do support ${ENV_VAR} expansion, so secrets need not sit in the file. Note that the log masking filter is attached to the root logger and therefore does not apply to records from the daemon's own modules, which is where nearly all output comes from (#90).

Is CPU pinning usable?

Yes, on main. It was not until recently: three defects meant that no pin was ever written, that p-cores resolved to every core on every host, and that an invalid explicit range could stop a container from starting. All three are fixed and closed, and l3:N and numa:N groups were added for non-hybrid CPUs.

Two caveats. The fixes are not in a tagged release yet, so an installation pinned to v2.0.2 still has them; and a cpuset written by the old bug stays in the container config until it is replaced or cleared by hand. Both are covered in Feature status.

What does "experimental" mean for horizontal scaling?

That it can create containers and that its defects tend to be structural rather than cosmetic: at various points every clone got the same static IP, and a documented minimum was ignored. Both are fixed, and a full redesign is in progress under the ASG issues. Pilot it, watch what it creates, and keep it away from anything load-bearing.

What is boost and revert mode?

A temporary resource boost that reverts automatically after a configured duration, for known short spikes, instead of leaving the container permanently larger. Configuration is in the guide.

It is installed and nothing scales

In order: is the service running (systemctl status lxc_autoscale.service), is the container in ignore_lxc, is the host hitting its reserved CPU or memory floor, is off-peak energy mode active, and is usage actually crossing a threshold. If all of that looks right, the number the daemon is acting on may be wrong rather than your configuration: start at How usage is measured.

Which Proxmox versions are supported?

Proxmox VE 8.x and 9.x, tested on 8.3.3 and on 9.1.7, with Python 3.10 or newer. The daemon does not start on 3.9, which is what Proxmox VE 7 ships: a lock is built at import time and binds an event loop the runtime then replaces. Container metrics depend on cgroup layout, so a version far from those is the first thing to mention in a report.