TopicGems: Why Moving a VM Can Change Its Network Behavior

I moved a client's staging server between two Proxmox nodes on a Tuesday afternoon. Routine hardware refresh, nothing exciting. The VM came back up in under a minute; the console looked fine, ping It worked; the disk was intact.

Then the client messaged me: "site's down."

The VM was alive. The OS hadn't changed a single file. But for about eighteen minutes, almost nobody outside my own network could reach it, and I couldn't figure out why a machine that clearly worked was acting like it didn't exist.

Turned out three separate things had quietly broken at once, and none of them were the VM's fault. They were all networking, and they all trace back to one fact people don't think about enough: a VM's identity travels with it when you move it, but its network context doesn't.

The part that doesn't move with the VM

When you migrate, clone, or re-host a virtual machine, the disk image moves. The RAM state might move (if it's a live migration). The CPU config, the OS, the installed software — all of it survives the trip.

What doesn't automatically survive is everything outside the VM that was built around its old location: which switch port it was plugged into, which firewall rule was watching that port, what the router's ARP table thought its MAC address mapped to, and what DNS believed its IP address was.

Also read: The Invisible Layer That Turns One Server Into Many

Here's the breakdown I now keep taped inside my own head before any migration:

Network Element	Moves With the VM?	Why It Can Break
MAC address	Usually yes, if not regenerated	Old switch/router entries still point to the old physical port
IP address	Only if you configure it to	New subnet or DHCP scope may not match
Default gateway	No — it's tied to the network, not the VM	Wrong gateway means no route out, even with a valid IP
Firewall/security group rules	No, unless explicitly reattached	Rules bound to old interface, bridge, or zone stop applying
DNS records	No	Old A record still points to the old IP until manually updated
VLAN tag/port group	No	New host may not have the same VLAN trunked

That table is basically the whole article. Everything below is just one row of it happening in real life.

Problem one: the switch still remembered the old port

My new Proxmox node sat on the same physical switch, different port. The VM kept its MAC address, because I hadn't told it to generate a new one.

Switches build a table (a MAC address table, sometimes called a CAM table) that says "this MAC lives behind this port." That table doesn't update itself instantly. Mine had an aging timer of five minutes, and until it expired, traffic aimed at the VM's MAC kept getting forwarded to the old, now-empty port.

This is different from ARP, which is a Layer 3-to-Layer 2 lookup that devices use to find a MAC address for an IP. ARP tables on routers and other hosts can also go stale the same way — a device remembers "this IP = this MAC" and doesn't recheck until its own cache expires.

The fix, once I understood what was happening, was simple: from the VM itself, I could have sent a gratuitous ARP (basically the VM announcing "I'm here, update your tables") right after boot. Most hypervisors do this automatically on a live migration. Mine was a cold migration — VM powered off, moved, powered back on — and cold migrations don't always trigger it.

On Linux, you can check what a device currently believes with:

ip neigh show

or the older, still-common:

arp -a

On Windows, arp -a works the same way, and clearing it is:

arp -d *

If a VM is reachable from some machines but not others right after a move, this is usually why. The machines that already talked to it are relying on old ARP or switch-table entries.

Problem two: the firewall rule never followed it

The second issue was mine to catch and I missed it. My firewall (pfSense, running as its own VM) had a rule scoped to a specific interface — basically "allow traffic on this bridge to reach that VM." When I moved the staging server to the new node, it landed on a different virtual bridge with a similar name but a different interface ID underneath.

Also Read: Why VMs Suddenly Restart

The rule looked identical in the GUI. It just wasn't attached to anything real anymore.

This is a very common trap with security groups in cloud environments too — AWS, Azure, GCP all let you scope rules to a specific network interface, subnet, or resource group. Move the VM (or in cloud terms, sometimes even resize or recreate it) and the rule can silently stop applying, because it was never actually watching the VM. It was watching the network object the VM used to sit inside.

Lesson: firewall rules that reference an IP or a specific interface are fragile. Rules that reference the VM's identity (a tag, a security group membership) survive a move much better.

Problem three: DNS was still telling people the old address

Even after the switch table cleared and the firewall rule was fixed, some visitors still couldn't load the site. That one was boring: the internal DNS record for the staging subdomain still pointed at the VM's IP on the old subnet, because the move had also meant a new IP address.

DNS doesn't know a VM moved. It only knows what you told it, and it'll happily keep telling that same story until you update the record — and even after you do, anyone who already resolved the old address might keep using it until their local cache's TTL (time to live) expires.

On a Windows machine, you can force a fresh look with:

ipconfig /flushdns

On Linux, depending on the resolver:

sudo systemd-resolve --flush-caches

If you're migrating something with a low tolerance for downtime, lowering the DNS TTL a day or two before the move (so caches expire quickly) is a small trick that saves a lot of "it's not loading for me" messages afterward.

The quieter ways a move changes network behavior

Those three were my afternoon. A few other things I've run into on other jobs, worth knowing even if they didn't bite me that day:

New host, different virtual switch type. Moving a VM from a host using a standard vSwitch to one using a distributed switch (in VMware terms) can change how traffic is tagged or filtered, even with "the same" VLAN number configured.
NIC driver mismatch. Exporting a VM from VirtualBox and importing it into VMware or Hyper-V sometimes swaps the virtual network adapter type. The guest OS may need a driver it doesn't have yet, and the interface comes up with no link at all until you reinstall Guest Tools/Integration Services.
DHCP reservations tied to MAC. If you clone a VM instead of moving it, and the clone keeps the same MAC (common if you didn't explicitly regenerate it), you can end up with two machines fighting over one DHCP reservation. One of them will "randomly" lose its IP.
Cloud metadata services. On AWS/Azure/GCP, some in-guest network configuration is pulled from a metadata service tied to the instance's current location. Move or resize the wrong way, and cloud-init can reapply old network settings on next boot.

The checklist I run before moving anything now

Write down what the VM currently depends on — its IP, gateway, VLAN, any firewall rules that mention it by name or IP.
Decide if the MAC should change. Cloning a template → yes, regenerate it. Migrating the same VM → usually no, keep it.
Check the destination's VLAN/port group matches before powering on, not after.
Re-point firewall rules to the VM's new location, or better, rewrite them to reference the VM by tag/group instead of IP or interface.
Lower DNS TTLs a day ahead if the move involves a new IP and downtime matters.
After boot, don't trust "it pinged once." Test from a machine that hasn't talked to it recently, not just from the console.
Flush ARP/DNS caches on your own test machine before declaring victory — otherwise you're checking your own stale cache, not the VM.

Where this usually goes wrong

If I had to bet on why a freshly-moved VM "isn't working," in order of likelihood from what I've seen:

Firewall rule scoped to the wrong interface or the old IP
Stale ARP/switch-table entry making it briefly unreachable
DNS still pointing at the old address
VLAN not trunked to the new host
MAC address collision from a clone that wasn't given a fresh one

Almost none of these show up as an error anywhere. The VM boots clean. The logs are quiet. Everything looks fine from inside the guest, because from the guest's point of view, nothing is wrong. It's the network around it that hasn't caught up.

That's really the whole idea to carry away from this: moving a VM is easy. Moving everything the network built around that VM's old address, port, and identity is the part that actually takes planning. Next time something goes quiet right after a migration, I check the switch and the firewall before I ever touch the VM itself.