Proxmox traffic limits, quotas and auto-suspend

Proxmox VE is an excellent hypervisor platform, but it has no native concept of a customer "plan": a named bundle that says a guest gets two cores, 4 GB of RAM, 50 GB of disk, 1 TB of monthly traffic, runs for thirty days, and then either renews or gets suspended. If you are using Proxmox to sell or share VPS capacity, you end up building that enforcement logic yourself, usually as a patchwork of cron jobs and manual checks. NexoVirt ships it as a first-class feature.

The Problem: Proxmox Has No Plan Concept

Raw Proxmox resource limits are a good start. You can cap a guest's CPU shares, balloon its memory, and restrict its disk quota. What Proxmox does not do is tie those limits to a time window, track how much network traffic a guest has consumed this month, automatically suspend the guest when it crosses a threshold, and then clean it up after a grace period if nobody renews.

That gap matters the moment you have more than a handful of guests with different customers behind them. Manual enforcement does not scale, and ad-hoc scripts are error-prone and invisible to the rest of your team. Proxmox auto-suspend and Proxmox traffic limits are simply not features the hypervisor provides out of the box.

Plans in NexoVirt: Named Resource Bundles

NexoVirt adds a Plans layer (under Settings) where you define named configurations. Each plan carries:

• CPU cores and memory (MB): injected at provision time via cloud-init or container config.
• Disk (GB): the root volume size.
• Monthly traffic limit (GB): zero means unlimited.
• Runtime days: how long the guest is provisioned for before expiry.
• Grace period (days): how long a suspended guest waits before it is automatically deleted.

When a guest is created from a plan via the NexoVirt wizard, the panel records a guest_assignments row that tracks status, expiry date, suspension date, delete date, and a running traffic counter. That record is the anchor for everything the enforcement engine does later.

Traffic Accounting: Monthly, Counter-Reset-Safe

NexoVirt's metrics collector samples guest network counters (bytes in + bytes out) every few seconds and stores them in a local database. The plan enforcement engine reads those stored metrics, the browser never hits Proxmox directly, and calculates incremental traffic deltas so that a counter reset on the hypervisor side (for example after a guest reboot) does not cause a spike that triggers a false suspension.

Traffic resets monthly. On the first of each month, the accumulated counter for traffic-suspended guests is cleared, and guests that were suspended purely for exceeding their monthly bandwidth allowance are automatically resumed. Guests suspended for expiry are not auto-resumed; those require a manual renewal.

Enforcement Lifecycle

The enforcement engine runs as php spark plans:enforce: a daemon you run alongside the panel. Its job is simple: compare each plan-assigned guest's current state against the rules on its assignment record and act accordingly.

The lifecycle flows in one direction:

1. Active: the guest is running normally within its plan limits.
2. Suspended: the guest has exceeded its monthly traffic limit or its runtime_days expiry has passed. The enforcer stops the guest and records a suspended_at timestamp. A delete_at date is set (suspended_at + grace_days).
3. Deleted: if the guest remains suspended past its delete_at date without a renewal, the enforcer deletes it from Proxmox and removes the assignment record. Nothing is left behind.

Traffic-suspended guests follow a fourth branch: on the monthly reset, if the guest has not also expired, it is automatically resumed and the traffic counter is cleared for the new period.

Email notifications are sent at each transition, suspended, expiry warning, and deleted, using NexoVirt's built-in notification outbox and editable per-event email templates. Alerting rules can also fire on plan_traffic and plan_expiry conditions, delivering to the in-panel inbox, email, or a webhook (Discord and Google Chat included).

Safety: Only Plan-Assigned Guests Are Ever Touched

This is the most important design constraint in the enforcement engine: it only ever acts on guests that have a guest_assignments record. Any VM or container that was not created through NexoVirt's plan workflow, whether it was provisioned directly in Proxmox, imported via the discovery agent, or created through the panel without selecting a plan, has no assignment record and is completely invisible to the enforcer.

You can run the enforcement daemon on a Proxmox host that already has production workloads and it will not touch a single one of them. There is no opt-out flag to set; the safety boundary is structural.

Renew and Resume Controls

The guest detail page in NexoVirt shows a Plan card that surfaces the current assignment status: expiry date, traffic used versus limit, suspension state, and the scheduled delete date if one is set. Admins can renew a guest from that card, which extends the expiry date and clears the suspension, or resume a traffic-suspended guest ahead of the monthly reset.

A honest note on availability: plan enforcement is opt-in. The plans:enforce daemon is off by default; you enable it by setting enforce.enabled = true in your .env and running the daemon. This means you can use Plans purely as a labelling and resource-sizing tool without any automatic suspension, and turn enforcement on only when your workflow is ready for it.

Where This Fits in the Broader NexoVirt Picture

Plans and enforcement are one part of a larger provisioning stack. The same guest that gets its resources from a plan also gets its OS from the cloud-init template library, its IP address from an IPAM zone (IPv4 or IPv6, static or DHCP), and its credentials delivered by email via the notification outbox. The customer who owns it can see it in the portal, manage their SSH keys, and run power actions, without ever having access to the Proxmox web interface. The REST API exposes the full lifecycle for any billing or automation layer sitting above NexoVirt.

NexoVirt is available now. Community Edition is free (up to 2 nodes). If you are running Proxmox to provide VPS capacity and want Proxmox resource quotas, traffic limits, and auto-suspend handled at the panel level rather than by hand, get started free and try it against your own infrastructure.