If you manage shared hosting servers, you've probably encountered the challenge of one account consuming excessive resources and degrading performance for everyone else. CloudLinux addresses this with Lightweight Virtual Environment (LVE) technology. This guide walks you through what LVE is, why it matters, and how to set up your first working configuration.
What Is CloudLinux LVE?
Lightweight Virtual Environment (LVE) is CloudLinux's kernel-level technology that isolates each hosting account into its own container with defined resource limits. Think of it as a lightweight jail that prevents one user from monopolizing CPU, memory, I/O, or processes.
Unlike traditional resource management that kicks in only when the system is under load, LVE enforces limits proactively. Each account operates within its allocated envelope regardless of overall server capacity. This isolation protects your server from resource abuse while maintaining the simplicity of shared hosting.
Key Benefits
- Predictable performance: Each account gets guaranteed minimum resources
- Isolation: One account's spike won't slow down neighbors
- Visibility: See exactly which accounts consume what resources
- Flexibility: Adjust limits per account or package without downtime
- Stability: Prevents server-wide crashes from resource exhaustion
Core LVE Concepts
Before configuring anything, understand these fundamental terms:
CPU Limit
Measured in percentage of a single core. A limit of 100% means one full core. If you set 200%, the account can use up to two cores simultaneously. CloudLinux converts this to CPU units internally.
Virtual Memory (VMEM)
The total address space an account can allocate, including physical RAM plus swap. This prevents memory leaks from consuming all available memory.
Physical Memory (PMEM)
Actual RAM the account can use. Always set this lower than VMEM. Physical memory limits prevent swap thrashing that degrades I/O performance.
Entry Processes (EP)
The number of concurrent processes that can be actively serving requests. For web hosting, this typically means Apache or PHP-FPM workers handling HTTP requests. Background processes like cron jobs don't count toward EP.
Number of Processes (NPROC)
Total processes the account can spawn, including background tasks. Set this higher than EP to allow cron jobs, database connections, and other auxiliary processes.
I/O Limit
Disk throughput measured in KB/s or MB/s. CloudLinux throttles both read and write operations when the account exceeds its limit. This prevents one account from saturating disk I/O.
IOPS Limit
Input/output operations per second. Separate from throughput, IOPS limits prevent excessive small random reads/writes that can degrade performance on spinning disks and SSDs alike.
Prerequisites
Before you begin:
- CloudLinux OS installed: You need CloudLinux 6, 7, 8, or later, not standard CentOS or AlmaLinux
- Active CloudLinux license: Register your server at cloudlinux.com
- Control panel: cPanel, Plesk, or DirectAdmin (this guide uses cPanel examples)
- Root SSH access: All LVE commands require root privileges
Installing LVE Manager
LVE Manager provides both a web interface and command-line tools for managing limits. CloudLinux typically installs it during initial setup, but verify it's present:
rpm -q lvemanager
If not installed:
yum install lvemanager
For cPanel integration:
yum install cPanel-lvemanager
After installation, access LVE Manager through WHM at Home → Plugins → LVE Manager.
Understanding Default Limits
CloudLinux ships with conservative default limits that apply to all accounts until you customize them. Check current defaults:
lvectl list
You'll see output showing the default profile and any custom limits. Typical defaults might look like:
- CPU: 100% (one core)
- VMEM: 1 GB
- PMEM: 1 GB
- EP: 20
- NPROC: 100
- I/O: 1 MB/s
These are intentionally modest to protect the server. You'll adjust them based on your hardware and hosting packages.
Your First LVE Configuration
Let's walk through setting up custom limits for a typical shared hosting package.
Step 1: Plan Your Limits
Before setting numbers, consider:
- Server hardware: How much CPU and RAM do you have?
- Account density: How many accounts will you host?
- Application type: WordPress needs more PHP workers than static sites
- Package tier: Basic vs. premium accounts get different allocations
For a basic shared hosting account on modern hardware, reasonable starting limits are:
- CPU: 150% (1.5 cores)
- VMEM: 2 GB
- PMEM: 1.5 GB
- EP: 30
- NPROC: 150
- I/O: 5 MB/s
- IOPS: 1024
Step 2: Set Limits via Command Line
Set limits for a specific user:
lvectl set username --cpu=150 --pmem=1536M --vmem=2048M --ep=30 --nproc=150 --io=5120 --iops=1024
Replace username with the actual cPanel account username. Memory values are in megabytes. I/O is in kilobytes per second.
Verify the changes:
lvectl list username
Step 3: Create Package-Level Limits
Instead of setting limits per user, define them by cPanel package. This automatically applies limits to all accounts in that package and updates them when you move accounts between packages.
Create a package limit:
lvectl set-package basic_hosting --cpu=150 --pmem=1536M --vmem=2048M --ep=30 --nproc=150 --io=5120 --iops=1024
The package name must match exactly what appears in WHM's package list.
List all package limits:
lvectl package-list
Step 4: Set Default Limits for All Users
To change the fallback limits for accounts without specific or package-based rules:
lvectl set default --cpu=100 --pmem=1024M --vmem=1536M --ep=20 --nproc=100 --io=4096 --iops=1024
This protects your server if you create an account without assigning it to a package.
Using LVE Manager Web Interface
The graphical interface in WHM provides an easier approach for many administrators:
- Log into WHM as root
- Navigate to Plugins → LVE Manager
- Click Packages to see all hosting packages
- Select a package and click Edit
- Adjust the sliders or enter values for each resource
- Click Save to apply
The web interface also shows:
- Real-time resource usage per account
- Historical statistics and graphs
- Faults (times an account hit a limit)
- Quick actions to adjust limits for high-fault accounts
Monitoring and Interpreting Faults
When an account hits a limit, CloudLinux records a fault. Faults don't mean something broke; they indicate the limit is working. However, frequent faults suggest the account needs more resources or has a performance issue.
View faults for an account:
lvectl list username --faults
Check system-wide faults:
lvectl list --faults
In LVE Manager's Current Usage tab, you see real-time data with fault counters. Pay attention to:
- EP faults: User experiencing slow page loads; need more concurrent PHP workers
- PMEM faults: Application might have memory leaks or need optimization
- I/O faults: Database queries or file operations exceeding disk throughput
- CPU faults: Intensive processing; might be legitimate or indicate malware
Adjusting Limits Based on Usage
Start conservative and increase limits based on observed behavior:
- Monitor for one week: Let accounts run under initial limits
- Identify high-fault accounts: Check LVE Manager statistics
- Investigate before increasing: High faults might indicate malware, poorly coded plugins, or legitimate growth
- Increase incrementally: Raise limits by 25-50% at a time
- Re-evaluate: Monitor for another few days
If an account consistently hits CPU or I/O limits but runs legitimate applications, consider:
- Upgrading them to a higher-tier package
- Optimizing their code or database queries
- Moving them to a VPS or dedicated server
Common Configuration Patterns
Three-Tier Package Structure
Basic Package:
lvectl set-package basic --cpu=100 --pmem=1024M --vmem=1536M --ep=20 --nproc=100 --io=4096
Standard Package:
lvectl set-package standard --cpu=200 --pmem=2048M --vmem=3072M --ep=40 --nproc=150 --io=8192
Premium Package:
lvectl set-package premium --cpu=300 --pmem=4096M --vmem=6144M --ep=60 --nproc=200 --io=16384
WordPress-Optimized Limits
WordPress sites need more entry processes for plugin requests:
lvectl set-package wordpress --cpu=200 --pmem=2048M --vmem=3072M --ep=50 --nproc=150 --io=10240
Troubleshooting Common Issues
Users Report Slow Site Performance
Check if they're hitting limits:
lvectl list username --faults
If EP faults are high, increase entry processes. If I/O faults dominate, investigate database queries or consider SSD storage.
LVE Limits Not Applying
Verify the CloudLinux kernel is active:
uname -r
The output should include lve. If not, you're running a standard kernel. Reboot and ensure GRUB defaults to the CloudLinux kernel.
Restart the LVE service:
service lvestats restart
Statistics Not Showing in LVE Manager
The statistics daemon might not be running:
service lvestats status
service lvestats start
Historical data takes a few minutes to populate after starting the service.
Best Practices
Start conservative: It's easier to increase limits than explain why a server crashed.
Use package limits: Per-user limits become unmaintainable at scale. Package-based rules update automatically.
Monitor regularly: Check LVE Manager weekly to spot trends before they become problems.
Document your rationale: Keep notes on why you chose specific limits for each package tier.
Test after changes: After adjusting limits, verify sites in that package still load correctly.
Communicate with users: If you lower limits, warn affected accounts in advance.
Reserve capacity: Don't allocate 100% of server resources to max theoretical accounts. Leave headroom for spikes.
Conclusion
CloudLinux LVE transforms shared hosting from a free-for-all into a stable, predictable environment. By understanding the six core resource types and following the configuration steps in this guide, you've built your first working LVE setup. Start with conservative limits, monitor real usage through LVE Manager, and adjust incrementally based on observed faults. The result is a server where every account gets fair access to resources, problem users are automatically contained, and your hosting platform scales smoothly. As you grow comfortable with LVE, explore advanced features like PHP Selector integration, CageFS, and MySQL Governor for even tighter resource control.