CloudLinux reseller limits: cap LVE per reseller in WHM

Per-user LVE limits stop a single cPanel account from eating the server. They do nothing to stop a single reseller from doing it with twenty accounts at once. If you sell reseller plans on shared CloudLinux nodes, this is the gap that turns one noisy buyer into a Sunday-afternoon outage.

CloudLinux reseller limits close that gap. You set a pooled CPU, EP, and memory budget for the reseller as a whole, and they sub-allocate within it via WHM. This guide walks through enabling the feature, sizing the pools sensibly, and the two mistakes that make it useless.

What reseller limits actually do

A reseller limit defines a single LVE that all of that reseller's end-user LVEs share inside. Think of it as nested LVEs:

• Outer LVE — the reseller's pool. Capped at, say, 400% CPU and 8 GB PMEM.
• Inner LVEs — one per end-user account under that reseller. Each capped by whatever the reseller (or you) configured in their packages.

When the outer pool is exhausted, every inner LVE under that reseller starts to throttle or fault — even if individually they're under their per-user cap. So a reseller with 50 WordPress sites can't suddenly consume 50 cores by spreading the load thin; the pool ceiling kicks in first.

This is independent of per-user LVE tuning, which still applies. Both must be satisfied: a request hits the inner per-user limit first, and the outer reseller limit second.

When to bother with reseller limits

Don't enable this on a server with no resellers or with two resellers you know personally. It adds a layer of configuration that is wasted effort if you're the only one selling.

Enable it when:

• You're running shared cPanel nodes with three or more paying resellers
• Resellers are selling onwards rather than just managing their own brand's sites
• You've had at least one incident where a reseller's customer base collectively saturated a node

If none of the above is true, plain per-user LVE tuning is enough.

Step 1 — Enable reseller limits in LVE Manager

Reseller limits ship with every CloudLinux license but are off by default. Enable in WHM:

# Or via the UI: WHM → CloudLinux LVE Manager → Options → Reseller Limits
lvectl set-reseller-mode --enable

This adds a [reseller] section to /etc/container/ve.cfg and starts tracking reseller pools. Existing per-user LVEs continue to apply unchanged.

Verify it took effect:

lvectl list-reseller

You should see one entry per reseller WHM account currently on the box, each with UNLIMITED defaults. That's the next thing to fix.

Step 2 — Set a reseller default pool

Before sizing individual resellers, set a default that applies to any reseller without an explicit override. This catches new resellers you provision later.

lvectl set-reseller default \
  --cpu=200 \
  --ep=40 \
  --pmem=4G \
  --nproc=200 \
  --io=8192 \
  --iops=2048

What these numbers say in plain English:

• CPU 200 — the reseller's whole account base can burn two full cores collectively. That's enough for ~10 normal WordPress sites running concurrently.
• EP 40 — forty entry processes pooled across all the reseller's customers. If five of their sites are hit by the same Googlebot crawl, they share the pool.
• PMEM 4G — four gigabytes of resident memory across all child accounts.
• IO/IOPS — double the per-user defaults from the LVE tuning baseline.

These are intentionally conservative — they fit a "small reseller plan" with maybe 10–20 end accounts. Bigger resellers get their own override (next step).

Step 3 — Set per-reseller overrides

For named resellers, set explicit pools that match their plan tier. Look up the reseller's WHM username, then:

# Pool sized for a 100-account reseller
lvectl set-reseller bigreseller \
  --cpu=600 \
  --ep=120 \
  --pmem=12G \
  --nproc=600 \
  --io=16384 \
  --iops=4096

The override applies immediately — no apply all needed for reseller settings.

To inspect what's currently set:

lvectl list-reseller --by-fault=any --order=desc --period=24h

This is the equivalent of lveinfo for resellers — sorted by who's hitting limits hardest in the last 24 hours. The columns to watch: lEP, aCPU, mPMem, and the fault columns (fEP, fCPU, fPMem).

Step 4 — Let resellers sub-allocate (or not)

CloudLinux gives resellers two modes:

1. You set the inner per-user limits via WHM packages. The reseller can't change them; they just choose which of your packages to assign to each customer.
2. The reseller sets their own per-user limits within their WHM LVE Manager interface, bounded by the outer pool you gave them.

Mode 1 is simpler and what most shared hosts run. Mode 2 is rare and only useful if your resellers are sophisticated and you trust them not to set every customer to the pool maximum.

To enable reseller self-service (mode 2), grant the reseller ACL:

whmapi1 saveacllist acllist=resellerwithlve \
  acl-cloudlinux-lve-manager=1

Then assign that ACL list to the resellers you want to enable it for in WHM → Resellers → Edit Reseller Nameservers and Privileges.

Step 5 — Watch for pool faults, not just user faults

Once reseller pools are active, your fault monitoring changes. A customer can report a 508 error that's not their per-user EP fault — it's the reseller pool's EP fault. Standard lveinfo --by-fault=ep won't catch that; the request was throttled at the pool level.

Add reseller pool faults to your daily check:

# Top 10 resellers by EP faults in the last 24 hours
lvectl list-reseller --period=24h --by-fault=ep --order=desc --limit=10

If a reseller is regularly faulting EP at the pool, the fix is to either upsell them to a bigger plan or increase the pool. Increasing it for free is the wrong default — that's revenue you're giving away because the pricing tier was wrong.

Common mistakes

1. Setting the pool to the sum of per-user limits. If you have a reseller plan with 100 accounts at 100% CPU each, you do not want a 10,000% pool. The whole point is statistical multiplexing — pool around realistic concurrent load (5–10×), not the theoretical maximum.
2. Enabling reseller mode without setting a default. Out of the box, the default pool is unlimited, so reseller limits do literally nothing until you set-reseller default.
3. Forgetting the MySQL Governor side. Reseller limits do not pool MySQL CPU or IO — those still apply per database user. A reseller's noisy customer can still tank MySQL even with a tight LVE pool.
4. Tuning pools before per-user limits. Reseller pools are the outer ceiling. If your per-user defaults are loose, the pool is what catches abuse — but you've also lost the ability to identify which account in the pool is the culprit. Tune per-user first.

FAQ

Next steps

• If your per-user defaults aren't dialled in yet, start with CloudLinux LVE tuning without angry customers — reseller pools are the outer ring on top of that
• For the database side of the resource story, see MySQL Governor: BAD queries to abusers mode
• If you're scoping a CloudLinux rollout across a fleet, the CloudLinux vs AlmaLinux decision for hosts covers the licensing-vs-free tradeoff before you commit