You've installed CloudLinux, spun up a test account, and watched the kernel modules load without errors. Everything looks green in WHM. Before you migrate real customers onto that box—or flip the switch on an existing shared host—walk through this checklist so LVE isolation works the way you expect.
1. Verify kernel and lve-utils versions
Check which CloudLinux kernel you're running:
uname -r
You should see a kernel string that ends in .lve or .lve.el7 depending on your distro version. If the output is still a stock CentOS or AlmaLinux kernel, the conversion didn't finish or the server hasn't rebooted since installation.
Next confirm the LVE utilities are present:
rpm -qa | grep lve
You want lve-utils, lve-stats, and lvemanager at a minimum. Missing any of those means package installation was incomplete.
2. Check that LVE is actually enabled
Just because the kernel is installed doesn't mean resource limits are being enforced. Confirm the LVE kernel module loaded:
lsmod | grep lve
If you see iolimits, lve_kmod_c7, or similar entries you're good. No output? The module isn't active and accounts run uncaged. A reboot usually fixes that, but double-check your GRUB default entry points to the CloudLinux kernel.
You can also verify enforcement by checking the LVE status for any user:
lvectl list
This shows every LVE on the system. If it returns nothing or errors out, enforcement isn't live.
3. Set sane default LVE limits
Out of the box CloudLinux ships conservative defaults—often too conservative for a modern shared host. Head into WHM → CloudLinux LVE Manager → Options and review:
- SPEED (CPU): default is typically 100% of one core. For a budget shared plan that's reasonable; for a "performance" tier you might go to 150–200%.
- PMEM (physical memory): 1 GB is a common starting point. Watch your average account usage and adjust.
- VMEM (virtual memory): set it to 0 (unlimited) or at least 2× PMEM to avoid unnecessary swap kills.
- IO (disk throughput): 1024 KB/s by default. SSDs can handle more; bump to 2048 or 4096 if your hardware allows.
- IOPS: 1024 is the stock setting. Monitor actual usage for a week before you tweak it.
- NPROC (entry processes): 100 is typical. Too low and you'll choke legitimate WordPress cron jobs.
- EP (concurrent connections): 20 is the default. For high-traffic sites this can be a chokepoint; 40–50 is safer.
Don't just copy another host's numbers. Every server and customer mix is different. The goal is to prevent one account from hogging resources without strangling normal traffic.
4. Create tiered packages in LVE Manager
If you sell multiple hosting plans—say Starter, Business, Pro—define a unique LVE profile for each in LVE Manager → Packages. Map each cPanel package name to its corresponding LVE limits. When you provision a new account CloudLinux reads the package assignment and applies the correct cage automatically.
Without this step every account inherits the system default, and you lose the ability to offer differentiated resource tiers. Check your existing cPanel packages under WHM → Packages and make sure each one has a matching LVE profile.
5. Test a real account under load
Spin up a test cPanel account, install WordPress or a simple PHP app, and hammer it. I usually use Apache Bench:
ab -n 1000 -c 10 http://testdomain.com/
While the test runs watch live stats:
lvetop
You should see the test user's LVE ID, current CPU/MEM/IO usage, and any faults (hits against the limit). If the account never faults even under heavy load your limits might be too high. If it faults constantly under modest traffic they're too tight.
Faults aren't evil—they're the point. A few faults during a spike is normal. Persistent faulting under typical load means the plan is under-provisioned.
6. Enable CageFS and verify isolation
CageFS wraps each user in a virtualized file system so they can't see other accounts' files or snoop /proc. Turn it on globally in LVE Manager → Options → CageFS and initialize it:
cagefsctl --init
cagefsctl --enable-all
Then SSH into your test account (as the cPanel user, not root) and try:
ls /home
You should see only that user's own home directory, not a list of every account on the server. If you see everyone's folders CageFS isn't active for that user. Check:
cagefsctl --list-enabled
and make sure the username appears.
7. Configure MySQL Governor
CloudLinux's MySQL Governor throttles runaway queries so one user can't monopolize the database. Enable it in LVE Manager → Options → MySQL Governor and pick a mode:
- single: one shared MySQL instance with per-user query throttling (most common).
- abusers: only restricts users who cross a threshold.
- all: applies limits to every query.
For shared hosting single mode is the sweet spot. After enabling, restart the dbgovernor:
service db_governor restart
Watch the governor log for a few days:
tail -f /var/log/dbgovernor-error.log
If you see constant restrictions on legitimate sites your MySQL limits might be too aggressive. Adjust them in MySQL Governor → MySQL Governor Mode → Edit MySQL Governor Configuration.
8. Set up PHP Selector (if offering multiple versions)
PHP Selector lets users pick their PHP version and tweak certain php.ini directives within their LVE limits. Install it:
yum install alt-php*
Then enable it in LVE Manager → PHP Selector. Users will see a new interface in cPanel under Select PHP Version. They can raise memory_limit or max_execution_time up to the ceiling you define, but they can't exceed their LVE PMEM or CPU limits.
Make sure your default PHP version (the one in /usr/bin/php) is an alt-php build so LVE tracking works. Stock EasyApache PHP doesn't integrate as cleanly.
9. Review and tune kernel parameters
CloudLinux tweaks a few kernel settings for better isolation. Check them:
sysctl fs.proc_can_see_other_uid
sysctl fs.proc_super_gid
The first should be 0 (users can't see each other's processes). The second is typically 600 or 0 depending on your setup. If proc_can_see_other_uid is 1 users can peek at other accounts' process lists even inside CageFS, which defeats part of the isolation model.
Also verify that the LVE kernel didn't break any custom sysctl tweaks you had in /etc/sysctl.conf. In support tickets I handled the usual culprit was a tuned network buffer size that got reset after the CloudLinux kernel went live.
10. Test account suspend/unsuspend with LVE
When you suspend an account in WHM the LVE should drop to 0% CPU automatically so even if the user's cron or daemon keeps running it gets no cycles. Suspend your test account and check:
lvectl list | grep testuser
The speed limit should show 0. Unsuspend and confirm it returns to the package default. I've seen cases where a misconfigured plugin or script kept the old limit cached; a quick lvectl destroy <id> and reprovisioning the LVE fixed it.
11. Check that lve-stats is collecting data
The LVE Manager dashboard in WHM won't show historical graphs unless lvestats is running and writing to the database. Confirm the service is active:
systemctl status lvestats
If it's dead or disabled, start it:
systemctl enable lvestats --now
Wait a few hours then open WHM → CloudLinux LVE Manager → Statistics. You should see per-user graphs for CPU, memory, and IO. No graphs? Check /var/log/lvestats.log for database connection errors or permission issues.
12. Document your limits and alert thresholds
Before you go live write down the LVE values for each package tier and the reasoning behind them. When a customer complains about a slow site six months from now you'll want to know whether they're hitting their EP limit because the plan was under-spec'd or because their site is legitimrately high-traffic.
Set up alerting (via your monitoring stack or a simple cron + script) for accounts that fault more than a threshold per hour. CloudLinux doesn't email you by default when an account is being throttled; you have to poll lve-stats or parse lvetop output. A quick Bash loop that checks fault counts and posts to Slack or email saves you from discovering resource starvation only after the ticket floods in.
How do I know which limit an account is hitting?
Run lvetop and watch the Fault column. Each resource has a separate fault counter. A high fPMEM count means memory, fEP means concurrent entry processes, fIO is disk throughput. The dashboard in WHM also breaks down faults by type over time.
Can I exclude certain users from LVE limits?
Yes. Add the username to the "unlimted users" list in LVE Manager → Options or via CLI:
lvectl set <username> --speed=0 --pmem=0 --io=0 --iops=0 --nproc=0 --ep=0
Setting a limit to 0 means unlimited for that resource. Use this sparingly; the whole point of CloudLinux is isolation.
What happens if I change a package's LVE limits after accounts are provisioned?
The new limits take effect immediately for all accounts assigned to that package. You don't need to reprovsion or migrate. However if an account was manually adjusted (via lvectl set) that override persists until you remove it.
Do LVE limits apply to root or reseller accounts?
No. Root always runs outside LVE. Resellers are also typically excluded unless you explicitly enable reseller limits in LVE Manager → Options → Manage Reseller Limits.
Why is CageFS breaking my custom cron or daemon?
CageFS mounts a minimal /usr, /lib, and /etc inside each user's cage. If your cron job calls a binary or library that isn't in the CageFS skeleton it will fail with "command not found" or "library not found." Add missing binaries to the CageFS skeleton:
cagefsctl --addrpm <package-name>
cagefsctl --update
or manually copy the file into /usr/share/cagefs-skeleton and update.
What to check after your first week live
Once real traffic hits the server spend a few days in the LVE Manager → Statistics tab and Current Usage view. Look for accounts that fault consistently and compare their traffic logs to the fault timeline. If a site faults every morning at 9 a.m. and that coincides with a scheduled backup or wp-cron you might need to raise NPROC or EP for that user.
Also review the MySQL Governor stats. If you see the same user throttled for hours you've either got a slow query that needs optimization or your MySQL limits are too strict for their workload. Adjust the per-user MySQL limits or help them add indexes and cache layers.
Finally verify that your backup solution (JetBackup, cPanel backup, etc.) isn't tripping LVE limits during its run. Backups can spike IO and IOPS; you may need to exclude the backup user or schedule backups during off-peak hours. A well-tuned LVE setup should handle normal traffic and occasional spikes without constant manual tweaks.