How to Limit Migration and Backup Bandwidth in Proxmox VE (Stop It From Saturating Your Network)

Introduction

Migrate a VM between two nodes in the middle of the day and watch what happens to everything else on that link. A colleague's video call starts breaking up. A file share gets sluggish. Someone asks if the internet is down. It isn't — Proxmox is just moving 40 GB of disk data as fast as the network will physically allow, because by default nothing tells it not to.

The same thing happens with backups pointed at network storage, disk clones, and restores. These are all jobs Proxmox is happy to run flat-out unless you tell it otherwise. The good news is there's a real, built-in way to cap them, and it's been in Proxmox for years — most people just never find it until a migration ruins a meeting. This tutorial covers exactly where that setting lives, what each part of it controls, and how to set values that keep backups and migrations from swallowing your whole network connection.

What You Will Learn

By the end of this guide you'll know how to cap the network and disk I/O used by backup, restore, migration, clone, and disk-move jobs — both from the web interface and from the command line. You'll also learn about a second, completely separate throttle that applies to a running VM's own network traffic, because people mix the two up constantly and then wonder why their fix "didn't work."

We'll cover the datacenter-wide bwlimit setting, one-off overrides for a single backup or restore job, the per-VM network rate limit, and how to check that a limit is actually being respected instead of just hoping it is.

What Is This Feature?

Proxmox VE ships with a bandwidth-limiting mechanism that throttles specific background operations: backups, restores, live migrations, VM clones, and disk moves. It's configured through a value called bwlimit, measured in KiB/s (kibibytes per second), and it lives in a cluster-wide config file at /etc/pve/datacenter.cfg.

Because that file sits on the shared cluster filesystem (pmxcfs), a limit you set on one node applies to every node in the cluster. You don't have to repeat the setup per host.

There's a second, unrelated feature that sounds similar but does something different: the per-VM network interface Rate Limit. That one throttles the live traffic a running virtual machine or container sends and receives over a specific network device — it has nothing to do with backup or migration jobs. We'll cover both, but keep them mentally separate. Mixing them up is the single most common mistake people make with this feature.

Why Would You Use It?

If you're running Proxmox on a single 1 Gbps NIC shared by everything — VM traffic, your own SSH sessions, backups to a USB drive or NAS, and maybe a second node for migrations — you've probably already felt this. A vzdump job to network storage can happily pull 100+ MB/s if nothing stops it, which is more than enough to choke a home network that's also trying to do video calls or stream 4K.

Small businesses run into the same wall with cluster migrations. Move a VM between two nodes during business hours and, without a limit in place, that migration will use as much bandwidth as the link allows — right up until VoIP calls start dropping packets. Setting a sane cap means backups and migrations still finish, just without becoming the loudest thing on the network while they do it.

There's a flip side too: sometimes people rate-limit everything to be safe and then can't figure out why a restore that should take five minutes is taking forty. Knowing exactly which knob does what means you can be generous where it's safe (say, restoring to local NVMe storage at 3 a.m.) and conservative where it matters (migrations during the day).

Prerequisites

Before you start, make sure you have:

• A working Proxmox VE 8.x or 9.x installation — the bwlimit options work the same way across both.
• Access to the web GUI as root@pam, or a user account with the Sys.Modify permission on /.
• At least one VM or LXC container you can safely back up, clone, or migrate to test with — you don't want your first test run to be a production system.
• SSH access to a node, only if you plan to use the command-line method instead of the GUI.

You don't need a cluster to follow most of this. Backup and restore limits work fine on a single standalone node — migration and clone limits only matter once you have more than one node to move things between.

Step-by-Step Tutorial

Step 1: Open the Datacenter Bandwidth Limits Dialog

Log in to the Proxmox web interface and click Datacenter in the left-hand tree. Go to Options, scroll down until you see Bandwidth Limits, select it, and click Edit. This opens a dialog with five separate fields, one for each type of job Proxmox can throttle.

Step 2: Understand the Five Limit Types

Each field controls a different operation, and you can set some, none, or all of them. Leaving a field blank means that operation runs at full speed — there's no limit unless you put a number in.

Notice that plain backup jobs (vzdump) aren't in that list as their own category — backups use the default limit unless you override them per-job, which we'll get to in Step 5.

Step 3: Set Your Limits in KiB/s

Every value in this dialog is entered in KiB/s, not MB/s or Mbps. This trips people up constantly. A value of 10240 works out to 10 MiB/s (about 80 Mbps), and 51200 is roughly 50 MiB/s. If you want a rough Mbps figure for your own network, multiply the KiB/s value by roughly 0.0082.

For a typical home 1GbE setup shared with other traffic, something like 30000 (about 30 MiB/s, or 240 Mbps) for migration and 20000 for the default limit leaves plenty of headroom for everything else on the network. Adjust based on what else is competing for that link.

Step 4: Apply It and Confirm

Click OK to save. There's no service to restart — the setting takes effect on the next matching job. You can confirm it saved correctly by checking the raw config file over SSH:

cat /etc/pve/datacenter.cfg

You should see a line that looks something like this:

bwlimit: default=20000,migration=30000

Step 5: Edit the Config File Directly (Optional)

If you'd rather skip the GUI, you can edit the same file by hand:

nano /etc/pve/datacenter.cfg

Add or update the bwlimit line using comma-separated key=value pairs:

bwlimit: default=20000,migration=30000,restore=51200,clone=15000,move=15000

Save the file. Because it lives on pmxcfs, the change is instantly visible to every node in the cluster — you don't need to copy it anywhere.

Step 6: Override the Limit for a Single Backup Job

Sometimes you don't want a permanent limit — you just want one manual backup to stay out of the way. The vzdump command takes its own --bwlimit flag that overrides the datacenter default for that run only:

vzdump 101 --bwlimit 15000

That backs up VM 101 with I/O capped at roughly 15 MiB/s, regardless of whatever the datacenter default says.

Step 7: Override the Limit for a Restore

Restores work the same way. Both qmrestore (for VMs) and pct restore (for containers) accept the flag:

qmrestore vzdump-qemu-101-2026_08_18-02_00_01.vma.zst 101 --bwlimit 51200
pct restore 201 vzdump-lxc-201-2026_08_18-02_15_00.tar.zst --bwlimit 51200

Set --bwlimit 0 if you specifically want to disable all limits for one job — useful when you're restoring something urgently at 3 p.m. and don't care that it briefly maxes out the link.

Step 8: Set a Per-VM Network Rate Limit (A Different Feature)

This is the one people confuse with everything above. If you want to cap how much bandwidth a running VM or container can push through its own virtual network card — not backups, not migrations, just its live traffic — go to the VM, click Hardware, select the Network Device, and click Edit. Check the Advanced box, and you'll see a Rate Limit (MB/s) field. This one uses MB/s, not KiB/s, so don't copy the same numbers you used earlier.

This is handy for a chatty VM that's saturating the link with normal traffic — a torrent box, a backup client pulling from the internet, that sort of thing. It has zero effect on how fast Proxmox's own backup or migration jobs run.

Commands Explained

Common Errors

The most common one isn't really an error message — it's a limit that appears to do nothing. Nine times out of ten, that's because the value was set for the wrong job type. Someone sets migration=30000, then tests it with a manual vzdump backup and wonders why it's still running at full speed. Backups use default unless you also set a backup-specific override, and manual vzdump runs will happily ignore the datacenter setting entirely if you pass your own --bwlimit flag on the command line — the CLI flag always wins.

Another one: entering a value in MB/s when the field expects KiB/s. Somebody wants a 10 MB/s cap, types 10, and ends up with a backup that crawls along at 10 KiB/s — effectively frozen. If a job that used to take twenty minutes now looks like it'll take six hours, check your units before you assume something's broken.

Setting the value to 0 by accident is the opposite problem. In this context, 0 means unlimited, not "as slow as possible." If you meant to throttle something and it's still running flat out, check whether a stray 0 crept into the config.

Troubleshooting

Start by confirming what's actually configured before assuming a limit is broken:

pvesh get /cluster/options --output-format json

If bwlimit doesn't show up at all, nothing has been saved yet — go back and check the GUI dialog again, or re-check your datacenter.cfg edit for typos in the key names.

To see whether a limit is actually being honored during a job, watch the node's Summary tab and its network graph while the job runs, or SSH in and run iftop (install it first with apt install iftop if it's not already there) to watch live throughput on the interface. A job that's respecting a 30000 KiB/s migration limit should show sustained traffic right around 30 MB/s, not spiking well above it.

If you're backing up to a Proxmox Backup Server instance rather than plain vzdump storage, be aware that PBS has its own, separate rate-limiting settings for sync jobs between PBS instances — the datacenter.cfg bwlimit covers PVE-initiated operations, not PBS-to-PBS replication. Don't spend an hour debugging the wrong config file.

Finally, if a migration still seems to ignore your limit, double check you're actually migrating between two nodes and not doing an offline "move disk" within the same host — that operation uses the move limit, not migration.

Best Practices

Don't throttle everything down to the same conservative number out of caution. A restore running against local NVMe storage at 3 a.m. isn't competing with anything — let it run fast. Save the tight limits for operations that cross a shared network link during hours people actually notice, like daytime migrations or backups over WiFi-adjacent switches.

If you have a dedicated migration network on a cluster — a second NIC just for node-to-node traffic — you can usually set the migration limit much higher, or skip it entirely, since it isn't competing with anything else. Check your network setup under Datacenter → Options → Migration Settings before assuming you need to throttle it at all.

Write your bwlimit values down somewhere outside of Proxmox itself. It's an easy setting to forget about, and six months from now when a restore feels unexpectedly slow, you'll want to remember that you set it that way on purpose.

Test any new limit with something low-stakes first. Clone a small test VM or restore a spare backup before you trust the setting on something that actually matters.

Frequently Asked Questions

Does bwlimit affect regular VM network traffic, like a website running on a VM?

No. It only throttles Proxmox's own background jobs — backup, restore, migration, clone, and disk move. Regular guest traffic is untouched unless you set a per-VM Rate Limit on that VM's network device.

What unit does the datacenter bwlimit use?

KiB/s. The per-VM network Rate Limit field uses MB/s instead, which is exactly why the two get mixed up so often.

Can I set a different limit for each node in a cluster?

Not through datacenter.cfg — it's a cluster-wide setting stored on the shared filesystem, so every node uses the same values. Per-job CLI overrides with --bwlimit are your option if one node needs different behavior for a single run.

Will a bwlimit setting slow down my whole network?

No, it only throttles the specific Proxmox job it applies to — the backup, migration, or restore process itself. Nothing else on the network is affected.

Do I need a cluster to use this feature?

No. Backup and restore limits work perfectly fine on a single standalone node. Migration and clone limits only come into play once you have more than one node.

Why did my restore ignore the datacenter bwlimit setting?

Check whether you passed a --bwlimit flag directly on the qmrestore or pct restore command — a job-specific flag always overrides the datacenter default.

Conclusion

Bandwidth limiting in Proxmox VE isn't complicated once you know where the two separate controls live — datacenter.cfg for background jobs like backup, restore, migration, clone, and move, and the per-VM network device for a guest's own live traffic. The hard part is usually just remembering the units are different between the two, and that a leftover --bwlimit flag on a manual command will always beat whatever you set globally.

Set reasonable defaults once, test them on something you don't mind breaking, and you'll stop dreading the moment a nightly backup or a daytime migration decides to eat your entire network connection.