Every VM you create in Proxmox VE gets a network card with a MAC address nobody chose. Proxmox picks one at random the moment you add the interface, and for most people that's the last time they ever think about it. Then one day you set up a DHCP reservation on your router, or you clone a VM and the copy silently loses network access, and suddenly that random string of hex digits matters a lot.

This guide covers what a MAC address actually is, when you'd want to pin one down instead of letting Proxmox generate it, and how to do that safely without creating a conflict on your network. None of it is complicated once you see it done once — the part that trips people up is picking a MAC that won't collide with someone else's real hardware.

What You Will Learn

By the end of this you'll know how to find the MAC address Proxmox already assigned to a VM, how to replace it with one of your own choosing, and how to do that from both the web interface and the command line. You'll also learn why a "locally administered" MAC range exists and why you should stick to it, what happens to MAC addresses when you clone a VM, and how to spot and fix the mess that happens when two machines on the same network end up sharing an address.

What Is This Feature?

A MAC address (Media Access Control address) is a 48-bit identifier burned into every network card — physical or virtual — that's used at the lowest level of Ethernet networking to get frames from one device to the correct one on the same local network. It's written as six pairs of hex digits separated by colons, like BC:24:11:4A:7C:02. Your router's DHCP server, your switch's MAC address table, and your local network's ARP cache all use it to keep track of who's who.

When you add a network device to a VM in Proxmox, the interface needs a MAC address just like a physical NIC would. Since there's no real chip to burn one into, Proxmox generates a random one for you and shows it as auto in the hardware configuration. That's fine for the overwhelming majority of VMs. Setting a static MAC address just means overriding that random value with one you picked yourself, and having Proxmox use that exact address every time the VM boots instead of generating a new one.

It's worth knowing that Proxmox's own auto-generated addresses aren't fully random — they start with the prefix BC:24:11, which is the OUI (Organizationally Unique Identifier) registered to Proxmox Server Solutions. Only the last three octets are randomized. That's a small detail, but it's why you'll see that same prefix repeated across every VM on a fresh install if you go looking.

Why Would You Use It?

Honestly, most homelab users never touch this setting. The random MAC Proxmox hands out works fine because nothing on the network cares what it is. A handful of situations change that:

  • DHCP reservations. If your router or a dedicated DHCP server hands out a fixed IP based on MAC address, you need that address to stay the same across reboots, migrations, and reinstalls — not get randomized again if you ever rebuild the VM.
  • Software licensing tied to hardware identity. Some older enterprise software (and the occasional network appliance image) ties its license key to the MAC address of the network interface it was activated on. If you rebuild the VM, you want the same MAC so you don't have to call support and re-license it.
  • Firewall or security appliance rules. Some network gear filters or logs by MAC address rather than IP. If you're running something like that as a VM, a fixed MAC keeps those rules working after a rebuild.
  • Consistency across a cluster. If you script VM creation and want predictable, trackable addresses rather than whatever Proxmox rolls for you, setting them explicitly makes your inventory easier to audit.

If none of that applies to you, leave it on auto. There's no performance benefit either way — a static MAC doesn't make your network faster or your VM more stable. It just makes the address predictable.

Prerequisites

You'll need:

  • A Proxmox VE host with at least one existing VM, or a new one you're about to create.
  • Access to the Proxmox web interface, or SSH/console access to the host if you'd rather use the command line.
  • A rough plan for which MAC address you're going to assign — see the section below on picking one that won't collide with anything.

You don't need the VM to be running for either method below; in fact, for the CLI method, you can make the change with the VM either stopped or running, but the new MAC only takes effect the next time the VM starts.

Step-by-Step Tutorial

1. Pick a MAC address that won't collide with real hardware

This is the step people skip, and it's the one that causes actual problems. Every real network card ships with a MAC address inside a range assigned to its manufacturer — Intel, Realtek, whoever built it. If you make up a random address and it happens to land inside one of those ranges, you risk it eventually colliding with a real device that shows up on your network, which causes genuinely confusing intermittent connectivity issues.

The fix is to use the locally administered address space, which the Ethernet standard sets aside specifically so software can generate addresses without stepping on real hardware. You can tell if an address is in this range by looking at the second hex digit of the first octet: if it's 2, 6, A, or E, the address is locally administered and safe to use for a VM.

So instead of picking something like 00:11:22:33:44:55 (which happens to fall in a real vendor's block), use something like 02:11:22:33:44:55. Same digits, but that leading 02 marks it as locally administered, so it can never collide with a genuine piece of hardware anywhere in the world.

2. Check the VM's current MAC address

Before changing anything, look at what's there now. In the web UI, open the VM, go to the Hardware tab, and double-click the network device (usually labeled net0). You'll see the current MAC address listed, along with an Advanced checkbox that reveals the editable field.

From the shell, the same information is one command away:

qm config 101

Replace 101 with your actual VM ID. Look for a line starting with net0: — the MAC address is the first field after the network model.

3. Set the new MAC address through the web interface

With the network device dialog still open, check Advanced if you haven't already. A MAC Address field appears, pre-filled with the current value. Clear it and type in your chosen address, then click OK.

Nothing changes for the VM immediately — this updates the configuration, but the running VM is still using the old virtual NIC until it restarts.

4. Or set it from the command line with qm set

If you'd rather script this or you're more comfortable in the shell, qm set does the same thing:

qm set 101 --net0 virtio=02:11:22:33:44:55,bridge=vmbr0

This rewrites the entire net0 line, so include the same bridge, VLAN tag, and firewall setting the interface already had — otherwise you'll reset those back to defaults. Run qm config 101 first if you're not sure what the existing line looks like, and copy the other options across.

5. Restart the VM

MAC address changes apply at the virtual hardware level, so a soft reboot from inside the guest OS won't pick it up. Stop the VM and start it again — either from the web UI or with qm stop 101 followed by qm start 101.

6. Confirm the new address inside the guest

Once it's back up, check the interface from inside the operating system to make sure it took. On Linux:

ip link show eth0

On Windows, open PowerShell and run Get-NetAdapter, or check ipconfig /all for the Physical Address field. Either way, it should match exactly what you set in Proxmox.

7. Set up your DHCP reservation, if that's why you're doing this

Now that the MAC is fixed, go into your router or DHCP server and create a reservation binding that MAC address to the IP you want. From this point forward, that VM keeps the same IP no matter how many times you rebuild it, as long as the MAC stays the same.

Commands Explained

CommandWhat it does
qm config <vmid>Prints the VM's current configuration, including the net0 line with its MAC address, bridge, and model.
qm set <vmid> --net0 virtio=<mac>,bridge=vmbr0Rewrites the VM's first network interface, setting the model to VirtIO, the MAC address to the one you specify, and attaching it to vmbr0.
qm stop <vmid> / qm start <vmid>Fully powers the VM off and back on, which is required for a MAC address change to be picked up by the virtual hardware.
ip link show <interface>Run inside a Linux guest to display the interface's current MAC address (listed as link/ether) and confirm the change applied correctly.

Common Errors

  • "Parameter verification failed" / invalid MAC format. qm set is strict about formatting — six colon-separated hex pairs, nothing else. A typo, a missing colon, or an extra character will get rejected outright.
  • The MAC address reverts after a clone. This one isn't a bug — Proxmox deliberately generates a fresh MAC address whenever you clone a VM, precisely to avoid two machines on the same network sharing one. If you need the clone to keep the original's MAC, you have to set it manually afterward, and you should only do that if you're certain the original VM will never run alongside it.
  • Network stops working after changing the MAC on an older Linux guest. Some older distributions (particularly ones still using udev's persistent-net-generator, like older CentOS 6/7 templates) tie the interface name to its MAC address the first time they see it. Change the MAC and the OS may register it as a new interface — eth1 instead of eth0 — leaving the old one configured and the new one blank.
  • Picking an address inside a real vendor's OUI range. If you invent a MAC without setting the locally-administered bit, it might coincidentally match a block owned by a real manufacturer. It'll usually work fine, right up until a real device using that range shows up on the same network.

Troubleshooting

If you're seeing weird, intermittent network behavior after touching MAC addresses, work through these in order.

Two VMs seem to have the same IP or keep disconnecting each other. This is the classic symptom of a MAC address collision — two devices on the same broadcast domain both answering to the same address, which confuses the switch's MAC table and causes packets to bounce between the two machines. Check every VM's configuration at once from the host:

grep -Eo 'net[0-9]:.*' /etc/pve/qemu-server/*.conf

Scan the output for any MAC address that appears more than once. Proxmox doesn't check for duplicates across your cluster when you set one manually, so this is the fastest way to catch a copy-paste mistake.

The guest OS shows the interface as down or unconfigured after a MAC change. Inside the guest, check for a leftover persistent-net rule referencing the old MAC — on older Linux distributions this lives at /etc/udev/rules.d/70-persistent-net.rules. Delete the stale entry (or the whole file, on a template you're about to reconfigure anyway) and reboot the guest so it regenerates the interface mapping against the current MAC.

The DHCP reservation isn't sticking. Confirm the MAC address in your router's reservation table character-for-character against what qm config shows for the VM. A single mistyped digit means the reservation silently applies to nothing.

Best Practices

  • Always use the locally administered range (second hex digit of the first octet is 2, 6, A, or E) for anything you set by hand. There's no reason to gamble on a made-up address landing outside a real vendor's block.
  • Keep a simple list somewhere — a spreadsheet, a text file, whatever — of every MAC address you've manually assigned and what it's for. It's easy to forget six months later why a particular VM has a hardcoded MAC.
  • Don't set static MACs on every VM out of habit. It adds a maintenance burden for no benefit unless you actually have a DHCP reservation, license, or appliance rule that depends on it.
  • If you're building a template meant to be cloned repeatedly, leave the MAC on auto. Trying to force a fixed MAC onto a template defeats the whole point of cloning and will cause exactly the collision problems described above.
  • After cloning a VM you intend to keep permanently, double-check its new MAC actually differs from the source — it will by default, but it's worth a glance if you've been copying configuration files by hand instead of using Proxmox's built-in clone feature.

Frequently Asked Questions

Does a static MAC address affect network performance?

No. Performance is governed by the network model (VirtIO versus emulated e1000, for example) and your physical network, not by whether the MAC is random or fixed.

Can two VMs have the same MAC address if they're never running at the same time?

Technically yes, but it's a bad idea. DHCP leases, ARP caches, and switch MAC tables can all hold onto stale entries longer than you'd expect, so "never running at the same time" is harder to guarantee than it sounds.

Does Proxmox check for duplicate MAC addresses when I set one manually?

No. Proxmox will happily let you set the same MAC on two different VMs without any warning. The responsibility for avoiding collisions is entirely on you.

What MAC address range does Proxmox use for auto-generated addresses?

Auto-generated addresses start with the prefix BC:24:11, Proxmox's registered OUI, followed by three randomized octets.

Will changing the MAC address disconnect an active SSH session to the VM?

Yes, briefly — since the change requires a full VM restart, any active network connection to that VM drops and needs to be re-established once it's back up.

Conclusion

Setting a static MAC address in Proxmox VE takes about two minutes once you know where the field is, and the whole exercise really comes down to one rule: stay inside the locally administered range and you'll never have to think about it again. Most VMs are perfectly happy with whatever random address Proxmox assigns, and there's no reason to change that unless a DHCP reservation, a license key, or a firewall rule specifically needs it.

The one habit worth building is checking for collisions before you copy a MAC address from one VM's config to another — that single mistake causes far more confusing troubleshooting sessions than anything else in this guide. Get that right, and the rest is just filling in a text field.