The symptom
Two Windows Server 2019 virtual machines were no longer properly reachable after they were moved to newer Proxmox hosts.
The timing made the migration itself look suspicious. The VMs had moved, and their network connectivity had failed.
What made it misleading
Several plausible causes fit the initial symptom:
- differences between the old and new Proxmox hosts
- virtual NIC configuration
- bridge configuration
- Windows networking
- migration behavior
- the Ceph and storage context
The incident happened on a weekend. The immediate operational priority was fast service recovery, so restoring service took priority over isolating each variable in the failed state.
Recovery first
A known-good backup was restored as a new VM on the older Proxmox node using ZFS storage. The restored VM became reachable again.
That recovery changed several conditions at once. It changed the VM instance, host placement, storage context, and physical network path. The result proved that the recovery path worked, but it did not show that restoring the backup had repaired the guest.
The actual root cause
The VLAN required by the affected servers was missing from an uplink of the switch serving the newer Proxmox hosts. The older Proxmox node was connected through an older switch path where that VLAN was present.
| Placement | Network path | Required VLAN available | Result |
|---|---|---|---|
| Newer Proxmox hosts | Newer switch path | No | VM not properly reachable |
| Older Proxmox node | Older switch path | Yes | VM reachable |
Ceph was not the root cause. The guest configuration was not the root cause.
Why the restore worked
Restoring the VM on the older node also returned it to the older physical network path. That path carried the required VLAN, so the restored VM was reachable.
A successful rollback does not necessarily prove that VM or hypervisor state was repaired. It may restore another infrastructure dependency at the same time. In this case, moving back to the older node also moved the workload back to a switch path where the VLAN existed.
Diagnostic path
When a VM loses connectivity after migration, trace both the virtual configuration and the physical path:
- Check guest network state. Confirm the guest-visible adapter, address, route, and the scope of the connectivity failure.
- Check Proxmox network configuration. Compare the virtual NIC, bridge attachment, and VLAN settings with the known-good placement.
- Compare source and destination placement. Identify which host the VM left, which host it moved to, and which infrastructure paths differ between them.
- Trace the VLAN end to end. Follow the path through the Proxmox bridge, physical NIC, switch port, trunk or uplink, and any intermediate switching path. Verify that the required VLAN is carried at every step.
- Treat rollback as evidence, not root-cause proof. List every condition changed by the rollback. Use those differences to narrow the fault instead of assuming that the VM itself was repaired.
This path is reusable for migration-related connectivity failures. In this incident, the actual fault was later identified in the switch uplink configuration.
The root cause
The required server VLAN was not carried over the uplink of the switch serving the newer Proxmox hosts.
The lesson
When a VM moves, the relevant change is not limited to the hypervisor. The workload may also move across a different:
- physical NIC
- switch port
- switch
- trunk
- VLAN path
Do not ask only:
What did the migration break inside the VM?
Also ask:
What infrastructure path changed when the VM moved?