A Home Assistant VM can restart on another Proxmox node while its USB Zigbee coordinator stays plugged into the failed host. Home Assistant may come back online, but Zigbee2MQTT cannot reach the radio. Planned live migration runs into the same physical dependency: Proxmox blocks migration while a local USB device is passed through.
The problem is the dongle’s location. Proxmox can move the VM, but it cannot move a device between physical USB ports. This applies to other software using USB passthrough too.
The options below keep the coordinator reachable during a VM move, or separate its uptime from the cluster. They solve different failures, so it helps to decide whether you need VM recovery, radio recovery, or both.
Why local USB passthrough blocks migration
Planned migration and recovery after a node failure are different operations. Neither transfers the physical USB dongle.
Live migration is blocked by local USB passthrough. Proxmox’s VM documentation lists passed-through USB devices among the resources that prevent live migration; a support-forum report shows the mapped-device error. A stopped VM can be moved, but you still need its USB configuration and coordinator available on the destination. Simply removing passthrough to permit migration interrupts Zigbee access.
Node failures are restarts, not migrations. When a node dies, the Proxmox HA manager fences it and restarts its HA-managed VMs on a surviving node. The VM boots fresh on new hardware, and whatever was plugged into the dead node’s USB ports stays there.
Resource mappings let one cluster-wide name refer to a USB device on each eligible node. They help a stopped VM start with the intended local device, but do not transfer the device or its Zigbee network data. A second dongle is not automatically a standby coordinator: the network identity, security data and Zigbee2MQTT data must match a supported recovery procedure, and only one coordinator for that network may be active.
This applies to any device passed through over USB on a Proxmox HA cluster, not just Zigbee coordinators. A USB Z-Wave stick or a USB TV tuner hits the same wall. For a Zigbee coordinator, the failure is especially visible because device control stops with it.
This article covers Home Assistant running on a Proxmox VE cluster with HA enabled, where the Zigbee coordinator is a USB dongle passed through to the VM. If your coordinator connects over Ethernet or Wi-Fi instead of USB, most of what follows doesn’t apply to you, and you should skip ahead to the network-attached section below.
What actually happens when it breaks
A user running Home Assistant on a five-node Proxmox cluster with HA enabled described the exact failure in Zigbee2MQTT discussion #18332. Their Sonoff Zigbee coordinator was physically attached to one node, so when HA moved the VM to another node, the coordinator stayed behind and Zigbee stopped working entirely. The VM itself was fine, running on different hardware, just without the one device the Zigbee mesh depended on.
That discussion, last active in 2023, proposed sharing the dongle over TCP/IP using USBIP through a dedicated Raspberry Pi, so the coordinator would stay reachable regardless of which node the VM landed on. The original poster didn’t confirm it as a solved outcome, just a promising direction.
Discussion #7142 explores standby adapters on different nodes, shared configuration and a way to choose the active radio. A commenter reported a prototype, but the discussion is not an installation guide. Zigbee uses one coordinator per network; a standby design needs compatible restored network data and a reliable way to prevent both radios operating at once. Shared storage by itself provides neither.
In Discussion #25926, a user chose an SMLIGHT SLZB-06 network coordinator for a redundant Home Assistant arrangement. Moving radio access onto the network avoids the USB-host dependency, although the coordinator remains one physical device.
Three ways people have tried to fix it, and what each one costs
These three approaches keep the original coordinator available without expecting Proxmox to move a USB device.
Share the USB device over the network with USBIP. Run USBIP on a small, always-on device, a Raspberry Pi in the one reported case, that stays physically connected to the coordinator, and expose it over TCP/IP so a VM on any Proxmox node can attach to it regardless of where the VM currently lives. This avoids touching the coordinator’s own configuration, but it introduces a new single point of failure. The Pi running USBIP has to stay up for the coordinator to be reachable at all.
Run ser2net on every node plus a floating virtual IP. This is the most concrete workaround, documented in the Proxmox forum thread on remote Zigbee/Z-Wave controllers. Install ser2net on every Proxmox node so whichever one currently has the dongle plugged in exposes it over IP, then use keepalived to run a virtual IP that follows the node holding the dongle. Home Assistant and Zigbee2MQTT connect to the VIP, not to a node-specific address, so the VM can land on any node. Note what follows what: the VIP tracks the dongle, not the VM. If the node the dongle is plugged into dies, you move the stick to another node by hand and the VIP comes up there. The dongle remains a single point of failure. A separate standby-radio design would also need coordinated access to the Zigbee2MQTT data and compatible radio backups; the VIP alone does not provide that.
Decouple Zigbee radio uptime from Home Assistant uptime entirely. A third option in the same thread starts from the fact that a single USB Zigbee coordinator is always a single point of failure, however the software around it is arranged. Run it on separate, non-clustered hardware, such as a Raspberry Pi, outside the Proxmox HA pool. Home Assistant stays highly available. The Zigbee radio doesn’t, and that’s treated as a separate, differently-solved problem rather than a defect in the HA setup.
| Approach | What it solves | What it doesn’t |
|---|---|---|
| USBIP over a dedicated Pi | Coordinator reachable from whichever node the VM moves to | The Pi itself becomes a new single point of failure; not confirmed as solved by the reporting user |
| ser2net on every node + keepalived VIP | Home Assistant/Zigbee2MQTT always connects to a stable address, wherever the VM runs | The dongle must be moved by hand if its node dies; the VIP alone does not provide standby-radio failover or protect against dongle failure |
| Run the coordinator outside the HA pool entirely | Simplest to reason about; Home Assistant and radio uptime become separate problems | The Zigbee radio itself still has no failover of its own |
These are community proposals and reports. The USBIP proposal was not confirmed by its original poster; the ser2net/VIP author reported it working, with manual relocation of the dongle when necessary. We have not built either setup.
Using a network-attached coordinator
An Ethernet or PoE coordinator such as the SMLIGHT SLZB-06 gives Zigbee2MQTT a network address instead of a USB passthrough device. The VM can reconnect to that same address from another cluster node. Configure Zigbee2MQTT’s serial port as the adapter’s tcp:// address and port; our SLZB-06 setup guide covers the setup.
This is the setup the 2025 discussion above chose. This removes the local USB resource that blocks migration. An HA restart still interrupts the Zigbee2MQTT process until it boots and reconnects, and a migration can briefly disturb its network connection. The coordinator’s own network path, meaning its switch port and its PoE source, becomes the dependency to keep outside any single node’s failure domain.
If you’re not running a Proxmox cluster and just want Zigbee2MQTT off your Home Assistant host on a single machine, our UGREEN NAS Docker-vs-VM passthrough guide covers the single-node version of this problem, without the clustering and failover layer this article adds.
A network-attached coordinator removes the USB-passthrough problem specifically. It does not make your Zigbee radio itself redundant. If the coordinator hardware fails, you still lose the mesh until you replace it and restore from a backup. Zigbee2MQTT supports coordinator backups for zstack and ember, subject to the documented firmware and migration requirements. Match the exact adapter and backup compatibility before replacing it. See our coordinator backup and restore guide for how to prepare for that ahead of time.
What “high availability” should actually mean for your Zigbee network
Write down the failures you want to cover. Proxmox HA can recover the VM after a host fails, provided the remaining cluster, storage and networking meet its requirements. A network coordinator keeps the radio outside that host failure, but the coordinator, its power supply, switch and MQTT broker still need their own recovery plans.
For planned maintenance, test moving the VM and reconnecting Zigbee2MQTT. For a host outage, test the restart path. Keep only one running Zigbee2MQTT process connected to a coordinator, and keep a compatible coordinator backup as well as the instance’s data backup. These checks tell you more than whether the VM has an HA label.
Common questions
- Can I run Zigbee2MQTT’s coordinator in Proxmox HA and have it survive live migration? Not with a USB coordinator, without extra infrastructure. Proxmox won’t live-migrate a running VM with a passed-through USB device, and an HA restart after a node failure leaves the dongle in the dead node. Community workarounds exist (USBIP, ser2net plus a floating VIP), but none of them are official Proxmox or Zigbee2MQTT features, and each comes with its own limitation.
- Does an Ethernet/PoE Zigbee coordinator like the SLZB-06 solve the Proxmox HA passthrough problem? It removes the local USB-passthrough dependency. The VM can reach the same network address from another node, but its Zigbee2MQTT process still has to reconnect after a restart or interrupted connection. It does not provide redundant radio hardware.
- What is ser2net and do I need it for Zigbee2MQTT on Proxmox?
ser2netexposes a serial device, like a USB Zigbee dongle, over a network connection. On a Proxmox HA cluster, running it on every node plus a floating virtual IP viakeepalivedis a documented community workaround for the passthrough problem, though the dongle still has to be moved by hand if its node dies. It isn’t required if you use a network-attached coordinator instead, which sidesteps the issue entirely. - Is my Zigbee network a single point of failure even with Proxmox HA enabled? Yes, as long as there’s exactly one coordinator. Proxmox HA protects the Home Assistant VM. It does nothing for the physical Zigbee radio unless you specifically design around that, and none of the community approaches above make the radio itself redundant, only reachable.
- Can two Zigbee2MQTT instances share one coordinator database for failover? Standby-radio arrangements have been proposed and some users report their own working builds, but sharing a database alone is insufficient. Radio backups must be compatible, network identity and security data must be correct, and the old process/radio must be stopped before the standby takes over. There is no generic automatic-failover setting. Two independently configured instances normally mean separate networks; our multiple-coordinators explainer covers that setup.
What this covers, and what’s still open
The migration and recovery behavior comes from Proxmox’s VM and HA documentation. USBIP, the floating-VIP arrangement and standby-radio ideas come from the linked discussions. No Proxmox HA cluster was built or tested for this article.
The Proxmox forum has newer reports from October 2026: one user describes two ZBT-2 radios with copied identity and tested host failures; another reports moving a VM using an SMLIGHT PoE adapter. Those are individual outcomes, not a supported failover procedure or proof that the same arrangement works with every adapter. The thread still does not provide a complete generic standby-radio build. A network coordinator is the simpler way to remove the USB dependency; radio failure remains a separate recovery task.