LVE is the part of CloudLinux that does the actual work. CageFS, PHP Selector and the panel plugins are all built around it. If you run a CloudLinux server, or are about to, this is the mechanism to understand: what an LVE is, which processes end up inside one, and exactly what happens when a limit is reached.
What an LVE is
LVE stands for Lightweight Virtual Environment. It is a kernel-level container, one per hosting account, identified by the account's numeric user ID. It is not a virtual machine and not a Docker container. There is no separate operating system, no separate network stack and no overhead you would notice. The kernel groups the account's processes and enforces limits on that group as a whole.
An LVE is created the moment the user's first process starts and torn down when the account goes idle. The limits come from /etc/container/ve.cfg: a default set that applies to everyone, plus overrides per package and per user. You never edit that file by hand; lvectl and the CloudLinux Manager in your panel write it.
What runs inside it
Every process that runs as the account's user goes into the account's LVE: PHP requests served through mod_lsapi, suPHP, fcgid or PHP-FPM, CGI scripts, SSH shell sessions, cron jobs, and the Passenger processes behind Node.js, Python and Ruby apps. With MySQL Governor installed, the account's share of the database server's CPU and IO is counted against the LVE too, even though the MySQL process itself belongs to the mysql user.
What does not run inside an LVE: Apache or Nginx itself, Exim, Dovecot, the panel, and anything else running as root or a service user. Those are the server's, not the customer's.
The accounting is per account, not per site. An account with three domains shares one LVE, and one of those domains can starve the other two. That is the customer's problem to solve, not their neighbours'.
The seven limits
| Limit | What it measures | Default on a new install |
|---|---|---|
| SPEED | CPU, as a percentage of one core (200% is two cores) | 100% |
| PMEM | physical memory used by all the account's processes together | 1 GB |
| VMEM | virtual memory (address space) | unlimited |
| IO | disk throughput, in KB/s | 1024 KB/s |
| IOPS | disk operations per second | 1024 |
| NPROC | number of processes in the LVE at once | 100 |
| EP | entry processes: concurrent requests entering the LVE | 20 |
VMEM is normally left unlimited on modern setups, because PHP and Node reserve far more address space than they use and a VMEM limit kills them for no reason. The other six are the ones you tune, and setting LVE limits has worked values for them.
What happens at each limit
This is the part that matters when a customer writes in, because each limit fails differently.
SPEED. The kernel throttles the account's processes so that together they never exceed the allowance. Nothing errors. Pages take longer, cron jobs run slower, and a top inside the account shows a suspiciously round CPU figure. Users almost never notice a CPU fault unless the site was already slow.
PMEM. When the account's total resident memory would go over the limit, the allocation is refused. PHP reports Allowed memory size exhausted if its own memory_limit is the lower ceiling; otherwise the process is killed and the error log shows Out of memory. The visible symptom is a blank page or a 500 on a heavy request, typically an image import or a large WooCommerce export.
IO and IOPS. Throttled, like SPEED. A backup plugin or a media library rebuild simply takes longer. No errors.
NPROC. New processes cannot be created. In a shell the user sees fork: Resource temporarily unavailable; in a web request PHP fails to start and the visitor gets a 500 or a 503.
EP. This is the one everybody recognises. Once twenty requests are already running inside the LVE, the twenty-first is refused and Apache returns 508 Resource Limit Is Reached. It is almost always caused by requests being slow rather than by too many visitors: twenty concurrent requests is a lot if each takes 100 ms, and very few if each takes eight seconds.
Every time a limit is hit, the kernel records a fault against the account. Faults are the evidence you work from:
lveinfo --period=1d --by-fault=anyWatching it live
lveps is top for LVEs. Each line is an account, with its CPU, memory, IO and entry-process usage against its limits:
ID EP PNO TNO CPU MEM IO IOPS
1001 3 9 14 98% 412M 240K 8
1004 1 4 6 3% 96M 0K 0
1012 20 37 52 64% 1.2G 3.1M 41Account 1012 has all twenty entry processes in use and is a few megabytes from its memory limit; that is the one whose site is returning 508s and whose owner is about to open a ticket. Account 1001 is running flat out against a 100% CPU allowance and does not know it.
lvectl list shows the limits in force for every LVE, and lveinfo -d gives a per-account summary for the day. Both are also in the panel under the CloudLinux Manager, on the Current Usage and Statistics tabs.
Why noisy-neighbour problems disappear
Look at that lveps output again. Account 1012 is in trouble, but the server is not. It has used its own allowance and is being held there; accounts 1001 and 1004 get exactly the CPU and memory they were promised, and the server's load average has not moved. On a plain server, the same account would have pushed the load to forty and every site on the box would have been slow.
That is the whole of LVE: a customer can only ever hurt themselves. The remaining work is deciding how much each customer gets, which is a pricing question as much as a technical one. On a VPSPioneer managed VPS we can convert the server to CloudLinux and set the initial limits for you as part of the service.