CloudLinux LVE is supposed to contain resource usage per user, preventing one account from choking the entire server. When it breaks, you see faults in the logs, users hit mysterious limits, and tickets pile up fast.
Most failures trace back to the same handful of configuration errors. I've seen these patterns repeat across hundreds of servers. Here are the nine mistakes that break LVE containment and the exact fix for each one.
1. Setting per-user limits higher than server capacity
The most common mistake is configuring LVE limits that add up to more than the physical hardware. If you have 8 CPU cores and set each of 50 users to a 2-core limit, you've promised 100 cores you don't have.
CloudLinux will honor these limits, which means under load the kernel scheduler thrashes trying to satisfy impossible constraints. You'll see high load averages, slow response times, and LVE faults that don't make sense.
Check your total allocation:
lvectl list --show-all | awk '{sum+=$3} END {print sum}'
That shows the sum of all CPU limits. It should stay well below your physical core count multiplied by 100 (LVE measures CPU in percentage points). For an 8-core server, keep the total under 600-700.
The fix is simple: lower individual limits or reduce the number of accounts. I usually set shared hosting accounts to 100 CPU (one full core) and 1GB RAM, then adjust from there based on actual usage patterns.
2. Forgetting to apply limits after changing them in LVE Manager
LVE Manager's web interface lets you change limits, but those changes don't take effect immediately. The configuration writes to disk, yet running processes keep their old limits until you explicitly apply the new values.
You change a limit, the user still hits the old threshold, they complain, and you check LVE Manager only to see the limit you just set. Confusing.
After changing limits in the UI, run:
lvectl apply all
That pushes the new limits to all active LVEs. You can also restart individual user LVEs with lvectl destroy <uid>, but apply all is faster when you've changed multiple accounts.
Some admins add a cron job that runs lvectl apply all every five minutes. That's overkill for most environments, but it does prevent this mistake.
3. Running CageFS without proper mounts
CageFS isolates each user's filesystem view, which is necessary for LVE to work correctly in shared hosting. But if CageFS is enabled and certain directories aren't properly mounted into each cage, you get silent breakage.
Applications can't find libraries, PHP extensions vanish, mail delivery fails. Users see cryptic "file not found" errors for things that definitely exist on the server.
Verify CageFS mounts:
cagefsctl --check-mounts
That command reports missing or incorrect mounts. If it finds problems, reinitialize:
cagefsctl --remount-all
After adding new software or PHP versions, always update CageFS:
cagefsctl --update
I've seen servers where someone installed a custom PHP build and skipped the CageFS update. Half the accounts worked fine, half threw errors, and the pattern made no sense until we checked which users had already logged in and triggered a cage rebuild.
4. Setting I/O limits without understanding the baseline
CloudLinux LVE includes I/O throttling, measured in KB/s and IOPS. Setting these limits too low kills performance; too high and they don't contain anything.
The mistake is picking a number that sounds reasonable without measuring what normal usage actually looks like. A WordPress site doing image processing might legitimately need 20MB/s during peak operation. If you set a 5MB/s limit, that job will crawl.
Before setting I/O limits, check current usage:
lvetop
Let that run during peak hours and note the I/O values in the rightmost columns. Your limits should sit above the 95th percentile of normal usage, catching only the true outliers.
For most shared hosting, I start with 10MB/s throughput and 1024 IOPS, then adjust based on observed faults. Reseller accounts often need higher limits because they aggregate multiple sites.
5. Not excluding system users from LVE
By default, CloudLinux can assign LVE limits to any UID. If you're not careful, system processes end up limited, which breaks background jobs, monitoring agents, and mail delivery.
The symptoms are weird: cron jobs time out, mail queues grow, backups fail. You check the limits and they look fine for user accounts, but meanwhile root's mail delivery process is hitting an LVE fault.
Exclude system users explicitly:
lvectl set --ignore=yes root
lvectl set --ignore=yes nobody
lvectl set --ignore=yes mailnull
Check your /etc/passwd file for other system accounts and exclude anything below UID 1000 that might run significant processes.
Some control panels create special users (like cpanelphppgadmin or dovecot). Those need exclusion too.
6. Enabling MySQL Governor without adjusting database tuning
MySQL Governor sits on top of LVE and limits per-user database queries. It's a great feature, but it changes how MySQL uses resources.
The mistake is enabling Governor, setting limits, and leaving your MySQL configuration unchanged. Now you have two resource management systems fighting each other, and query performance becomes unpredictable.
After enabling Governor, you typically need to raise MySQL's max_connections because Governor will queue slow queries instead of letting them pile up inside MySQL. You also want to lower innodb_buffer_pool_size slightly because Governor adds memory overhead.
Check current Governor settings:
dbctl get all
And verify MySQL is configured to handle the connection patterns Governor creates:
mysqladmin -u root -p variables | grep max_connections
I usually bump max_connections by 50% after enabling Governor and monitor for connection refusals.
So what about reseller accounts?
Reseller accounts need special handling. A reseller's UID owns multiple websites, and if you apply a single LVE to that UID, all their clients share one resource pool.
The mistake is treating reseller accounts like regular users. You set a limit, the reseller's biggest client uses all of it, and their other sites starve.
For resellers, either:
- Use the reseller limits feature:
lvectl set <uid> --reseller-limit=1024 - Or create separate LVEs for each end-user under that reseller
The second approach is cleaner but requires mod_hostinglimits configuration to map each domain to the correct LVE.
Check if a user is marked as a reseller:
lvectl list | grep -A2 reseller
7. Ignoring LVE faults in logs without investigating the cause
LVE logs every fault: when a user hits their CPU limit, memory limit, or I/O threshold. These show up in /var/log/lve-stats.log and through the LVE Manager interface.
The mistake is seeing faults, assuming they're working as intended, and moving on. Sometimes faults indicate legitimate resource exhaustion that needs optimization. Other times they reveal misconfiguration.
A user hitting CPU faults every single minute probably has a runaway process or a misconfigured cron job, not a legitimate traffic spike. A site hitting memory faults only at 3am might have a backup script that needs tuning.
Check recent faults:
lve-stats --period=1d --order-by=faults
That shows which users hit limits most often. Investigate the top three. Look at their running processes, check their cron jobs, examine their access logs.
Often you'll find a WordPress site running a poorly coded plugin, or a mail script stuck in a loop, or a backup job that tries to compress 50GB without streaming.
8. Disabling CageFS for "compatibility" without understanding the implications
Some admins disable CageFS because an application claims it needs full filesystem access, or because troubleshooting an issue is easier without the cage.
That's a mistake. CageFS is part of the LVE security model. Without it, users can see each other's processes, read each other's environment variables, and potentially escape resource limits through various kernel interfaces.
If an application truly can't work inside CageFS, the right fix is to add the required paths to the CageFS mount list, not disable CageFS entirely.
Add a custom mount:
echo "/custom/path" >> /etc/cagefs/custom.etc/custom.mounts
cagefsctl --remount-all
I've yet to encounter a legitimate web application that actually needs CageFS disabled. Usually the issue is a missing library path or a hardcoded reference to /home that needs adjustment.
9. Not monitoring LVE statistics over time
LVE collects detailed usage stats, but most admins only look at them when someone complains. You're flying blind.
The mistake is reactive management. By the time a user hits limits and opens a ticket, you've already lost revenue, wasted time, and annoyed a customer.
Set up regular monitoring:
lve-stats --period=1d --show=cpu,mem,io | mail -s "Daily LVE Report" [email protected]
Add that to cron and review it weekly. You'll spot trends: an account gradually using more resources month over month, a user who hits limits every Tuesday, or a site that suddenly spiked after a plugin update.
LVE Manager also offers a web interface that graphs usage over time. Use it. Five minutes of reviewing graphs will prevent hours of reactive troubleshooting.
Common questions
Q: Can I set different LVE limits per domain instead of per user?
Not directly through LVE, but mod_hostinglimits lets you map domains to separate LVE IDs. That requires additional configuration beyond basic LVE setup.
Q: What happens when a user hits their LVE limit?
The process slows down but doesn't get killed. CPU-limited processes get less scheduler time, memory-limited processes might swap, and I/O-limited processes queue their disk operations. The site stays up but performs poorly.
Q: Do LVE limits apply to SSH sessions?
Yes, if the user SSHs in, their shell and any processes they launch count against their LVE. This prevents users from bypassing limits by running resource-intensive scripts over SSH.
Q: Can I temporarily raise a user's limit during a known traffic spike?
Absolutely. Use lvectl set <uid> --cpu=200 to double their limit, then set it back afterward. Or use LVE Manager's web interface to adjust and apply.
What to check first when LVE breaks
If LVE suddenly stops working or users start hitting unexpected limits, run through this checklist:
- Verify the kernel module is loaded:
lsmod | grep lve - Check that LVE is enabled globally:
lvectl limits - Confirm CageFS is running:
cagefsctl --check-cagefs - Look for recent limit changes:
grep lvectl /var/log/messages - Review the top fault-generating accounts:
lve-stats --period=1d --order-by=faults
Most issues trace back to one of the nine mistakes above. The ones I see most often are mismatched capacity planning, forgotten limit application, and CageFS mount problems. Fix those three and you'll resolve 80% of LVE issues without needing deeper troubleshooting.