Proxmox LXC restores create containers with duplicate MAC addresses causing ARP flaps after backup imports

Environment

Proxmox VE 7.x cluster. Backups created with vzdump and restored to different nodes for quick recovery/testing. Network model is default LXC veth with MAC sometimes specified in config as 'hwaddr:'. Switching node and restore automation used in-house scripts to perform batch restores.

Symptoms

After performing multiple container restores, several containers intermittently lose network connectivity. Downstream switches report duplicate MAC address seen on two different switch ports. ARP tables on other hosts rapidly flip between two MAC-port mappings for a given IP and ping jitter spikes.

Observations

Inside affected LXC containers, ip link show reports identical MAC addresses (link/ether) for two different container IDs. The timestamp on the container config file indicates it was copied from backup without modification. Restoring the same backup to the same node sometimes reproduces duplicate MAC. Manually changing hwaddr in the container config and restarting networking fixes the container until next restore.

Already attempted

Manually edited the restored container's config to remove hwaddr and restarted the container — new MAC generated and conflict cleared. Re-ran a restore with an explicit new VMID and different target node but conflict still occurred occasionally. Examined Proxmox cluster logs; no explicit error and MAC allocation database shows expected entries.

Question

Why do restored LXC containers sometimes end up sharing identical MAC addresses, and how can the backup/restore process be changed to guarantee unique MACs without manual edits?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 3h ago• Trouble ID

Most likely causes

Restore process preserves original 'hwaddr' from backup config, resulting in duplicate MACs when multiple restorations of the same backup occur. 75%

Proxmox predictable MAC generator returns same MAC because VMID was reused or the restore script forces a specific VMID that collides with existing assignments. 50%

Cluster config database did not update MAC allocation on restore due to a temporary cluster quorum issue, allowing duplicate allocation. 25%

Summary

Most likely the backup includes the original container's hwaddr and the restore process is preserving it instead of generating a fresh MAC for the new target VMID. Another possibility is deterministic MAC generation based on VMID or node-specific seed (if VMID reused) causing collisions when restores are scripted. A reversible mitigation is to enforce clearing hwaddr during restore and let Proxmox assign a fresh MAC, or pass a flag to the restore tool to generate unique MACs. Also verify restore scripts do not blindly copy old config files into /etc/pve without adjusting hwaddr.

Suggested Fixes

Diagnostic step 1

Modify restore automation to explicitly remove hwaddr entries from the container config before starting the container so Proxmox generates a new MAC (or use the restore flag that enforces unique MAC allocation).

Diagnostic step 2

If using scripted VMID reuse, stop reusing VMIDs for restores or ensure the MAC generator is seeded per-cluster so generated MACs will be unique; prefer letting Proxmox assign the MAC.

Diagnostic step 3

As a diagnostic, restore a single container and check /etc/pve/nodes/<node>/lxc/<vmid>.conf to confirm whether hwaddr is present; remove it and restart the container to confirm unique MAC assignment.