Static IP Lost After a VM Restore or Virtual NIC Change

Direct answer: When a VM is restored, converted, moved to a new hardware version or given a different virtual network adapter, the guest may see a new network device, and settings stored against the old device do not follow it. On Windows, the old adapter can remain as a hidden, non-present device that still holds the static address; Windows then warns that the address "is already assigned to another adapter" when you set it on the new adapter. On Linux, the interface can get a new name or MAC address, so configuration written for the old one no longer matches. A DHCP or 169.254 address alone does not prove which of these happened. Record the old settings, identify the exact device that holds them with read-only listings, then move the configuration. Removing a Windows device or changing Linux naming is a change made from the console with the settings saved first.

Why it matters

The server is reachable from the console but not from the network, or it answers on an address nothing else knows. Services, firewall rules, DNS records and monitoring all expect the old address. On Linux the server may boot with no address at all.

How it works

Windows: settings per adapter instance

Windows stores TCP/IP settings per network adapter. A new virtual adapter is a new device. The previous adapter, if no longer present, can remain in the registry.

Microsoft's KB 269155 describes the warning:

The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working.

Microsoft's stated cause: "a network adapter with the same IP address is in the registry but is hidden in Device Manager." Its example is moving an adapter to another PCI slot. On the warning's choices, Microsoft says: "If you select No, the IP address is assigned to the network adapter," both adapters then hold the same address, and "In most cases, this causes no problems, because the driver is disabled." The hidden adapter does not by itself block the new adapter from working; it leaves a stale entry for the next hardware change.

Broadcom KB 343044 lists VMware triggers for the same condition: upgrading virtual network adapters when a VM moves to a newer VMware version (including hardware version or VMware Tools upgrades), adding and removing network adapters several times, and P2V conversions that leave physical NICs and drivers present. It lists the symptom that after a reboot the guest NIC can get a private IP address, and notes that "Show hidden devices" in Device Manager does not always show the ghosted adapter.

Linux: names and MAC addresses can change

Since systemd v197, udev assigns predictable interface names. The systemd documentation explains why: the old eth0, eth1 order depended on driver probing and "can have serious security implications, for example in firewall rules". The default policy prefers names from firmware onboard index, then PCI Express hotplug slot index (example ens1), then physical location, and falls back to the kernel name.

Names can change for several reasons:

• the device appears in a different slot, is a different virtual NIC type, or is removed and added again;
• the naming scheme changes. The systemd.net-naming-scheme page states that newer versions of systemd-udevd take more attributes into account, "improving (and thus possibly changing) the names and addresses used for the same devices"; distributions choose the default scheme, and net.naming_scheme= can override it.

Configuration that names the interface then stops applying. Netplan's reference states that when the device ID does not match a real interface name, you must use match to identify the device, and that set-name gives a matched device a chosen name. A configuration matched by MAC address fails in turn if the restore generated a new MAC address. No single property is guaranteed to survive every later change.

Read-only checks

None of these was run for this article.

Windows

1. Record the current state: ipconfig /all. Note which adapter has which address. An unexpected DHCP or 169.254 address on the new adapter is a symptom to explain, not proof of a hidden adapter.
2. Adapters, including hidden ones, in Windows PowerShell: Get-NetAdapter -Name * -IncludeHidden | Format-List -Property Name, InterfaceDescription, InterfaceName, Status
3. Non-present network devices with PnPUtil. The reference states /enum-devices and its /disconnected and /class flags are available "starting in Windows 10, version 1903"; it gives no Windows Server mapping, so check that pnputil /? on the exact server lists them before relying on it: pnputil /enum-devices /class Net /disconnected Record the instance ID and description of every non-present adapter.
4. Device Manager view, per Microsoft's method: from an elevated prompt run set devmgr_show_nonpresent_devices=1, then start devmgmt.msc, then View, Show Hidden Devices, and expand Network adapters. Dimmed entries are non-present. Broadcom notes this view does not always show the ghosted adapter.
5. Which device holds the address: Microsoft's KB names the adapter in the warning text itself. Match that name to an instance ID from step 3. Without a positive match, do not treat any one dimmed entry as the holder.
6. VM side: in vCenter, compare the VM's network adapter type and MAC address with the record from before the restore or change.

Linux

1. Interface names and MAC addresses now: ip link. Compare with the name and any MAC match in the network configuration.
2. Why the name was chosen: udevadm test-builtin net_id /sys/class/net/<name> shows the naming properties (ID_NET_NAME_SLOT, ID_NET_NAME_PATH and others). Check the kernel command line (cat /proc/cmdline) for net.naming_scheme= or net.ifnames=.
3. Configuration: read the Netplan YAML under /etc/netplan/, any .link files in /etc/systemd/network/, or the NetworkManager connection, and note whether each matches by name or by MAC address.
4. Boot journal: read this boot's network service messages for the interface that was not configured.

Candidate causes

Decision guidance

Everything here is a change, needs a change record and console access, and was not executed for this article.

Before any change:

• Record the old address, mask, gateway and DNS from documentation or the backup record.
• Confirm the original VM is not running on the same network; two copies with one address is a real conflict no guest change solves.
• On Windows, record the instance ID of the adapter that holds the address (step 5) and its settings.

Windows. Set the static address on the new adapter. If the warning appears and the holder is positively identified, Microsoft's Method 1 is to uninstall that dimmed adapter in Device Manager. The PnPUtil reference documents pnputil /remove-device <instance ID> as available "starting in Windows 10, version 2004"; confirm with pnputil /? that the server supports it. Remove only the identified adapter. If you choose No at the warning, which Microsoft says "In most cases" causes no problems, record the stale adapter for the next hardware change.

Linux, preferred. Update the configuration to the current interface, or rewrite it to match a property you have chosen deliberately. In Netplan, match with macaddress plus set-name is the documented way to give a matched device a fixed name. Validate with the distribution's own tooling before applying, from the console.

Linux, .link file as a design option. A .link file in /etc/systemd/network/ can match a device and name it, but the systemd.link page sets conditions that a simple file does not meet on its own: a user file must sort before 99-default.link to have any effect; Name= "has lower precedence than NamePolicy=", so it applies only when NamePolicy is unset, empty or all its policies fail; and some distributions copy .link files into the initramfs, so local changes may need manual steps to stay consistent with early boot. Treat it as a design choice, follow your distribution's documentation, and rehearse it on a copy before production.

Prove. Restart in a window and confirm the address, gateway, DNS and the services that depend on them.

What not to do

• Do not uninstall hidden devices in bulk. Remove only the adapter positively identified as holding the address.
• Do not treat a 169.254 or DHCP address as proof of which device holds the configuration.
• Do not disable predictable naming with net.ifnames=0 as a quick fix; it returns to kernel names whose order can change between boots.
• Do not edit network configuration over the connection you are changing.
• Do not assign the old address while the original VM may still be running.

Limitations

• No command was run for this article; lab validation is outstanding.
• Microsoft's KB is written for Windows Server 2012; the PnPUtil reference gives Windows 10 version thresholds without a Server mapping.
• The Broadcom KB's date was not displayed in the retrieved copy, and its environment line is the P2V Assistant, although its causes cover virtual hardware upgrades.
• NetworkManager keyfile syntax and distribution-specific .link and initramfs handling are not covered.
• Network identity on a domain controller is covered by the domain controller article.

Acceptance checklist

• [ ] Pre-change network settings are recorded.
• [ ] Only one running copy of the VM uses the address.
• [ ] Any Windows device removed was identified by instance ID as the holder of the address.
• [ ] The Linux configuration matches the interface by a property chosen and recorded deliberately.
• [ ] Address, gateway and DNS are correct after a restart.
• [ ] Dependent services, firewall rules and monitoring respond on the address.

Sources

Displayed dates as shown when accessed on 30 October 2026.

• Microsoft Learn, Error message when you try to set an IP address on a network adapter (KB 269155), 2026-02-12
• Broadcom Knowledge, Networking Error: IP address already assigned to another adapter (343044), not displayed in retrieved copy
• Microsoft Learn, PnPUtil command syntax, 2024-01-08
• Microsoft Learn, Get-NetAdapter, no date in retrieved copy
• systemd, Predictable Network Interface Names, no date in retrieved copy
• systemd manual, systemd.net-naming-scheme, systemd 262, no date
• systemd manual, systemd.link, systemd 262, no date
• Netplan documentation, YAML configuration, Jul 20, 2026

Related articles

• Windows firewall rules stopped working after a move: network profile switched to Public
• VM will not boot after a disk controller change: INACCESSIBLE_BOOT_DEVICE and missing initramfs drivers
• Linux VM drops to emergency mode after a disk change: fstab, UUIDs and nofail

Learning notes

1. A new virtual NIC can be a new device to the guest; settings stay with the old device.
2. A duplicate address on a hidden adapter is not by itself an outage; identify the holder before removing anything.
3. Linux names can change with the device's location or with the naming scheme.
4. Configuration matched by name or MAC breaks when that property changes; choose and record the property.
5. Remove only the adapter identified by instance ID, and prove with a restart.