Duplicate DHCP leases after hypervisor DHCP server restart cause VMs to keep stale IPs post-resume

Environment

KVM/QEMU hypervisor host running dnsmasq as a DHCP server for an isolated VM network (192.168.200.0/24). Several paused VMs are resumed after host maintenance; hypervisor's DHCP lease file was rotated and dnsmasq restarted during the maintenance window.

Symptoms

After host maintenance and guest resume, some VMs retain their previous IP configuration but cannot reach other hosts; bridged connectivity works for some VMs while others get 'duplicate address' ARP conflicts. On resumed guests, dhclient log shows 'DHCPACK for 192.168.200.14' followed by 'Could not update lease' and intermittent networking for minutes until manual dhclient -r / dhclient runs resolve the conflict.

Observations

dnsmasq.leases file shows duplicate entries for the same MAC with two different timestamps. ARP tables on bridge show multiple MACs for the same IP during the window. Restarting dnsmasq during lease rotation appears to have created stale lease entries. VMs that were suspended received DHCP lease renewals that matched an old lease record but the host's lease database didn't match the VM's expectation.

Already attempted

Restarted dnsmasq and reloaded leases; removed duplicate entries from lease file and sent SIGHUP to dnsmasq. Performed dhclient -r && dhclient on affected VMs; network recovery succeeded for those guests. Configured libvirt XML to use persistent DHCP reservations for critical VMs. Did not modify MAC addresses on VMs.

Question

What causes duplicate leases after dnsmasq restart during maintenance to produce inconsistent post-resume networking for paused/resumed VMs, and what configuration changes prevent future duplicate-lease issues on the hypervisor-managed virtual network?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

dnsmasq lease file rotation or corruption during restart left duplicate entries for same MAC/IP 95%

dnsmasq was restarted without dumping/reading existing leases properly leading to reissued IPs and timestamp mismatches 90%

VMs resumed with unchanged DHCP state while server had reallocated addresses to other MACs 90%

Summary

When a DHCP server's lease database is rotated or corrupted while clients are suspended, the server and client can end up with inconsistent lease state: the client believes it holds a lease while the server's lease file may have duplicate or stale entries. On resume, a client may attempt a renewal that collides with a stale record or triggers server-side re-allocation, causing ARP conflicts and transient loss. Restoring consistency required removing stale dnsmasq lease entries or forcing clients to release/renew. Preventing recurrence involves ensuring lease persistence across restarts and avoiding lease file editing without proper server reload semantics.

Suggested Fixes

Diagnostic step 1

Before maintenance, gracefully stop dnsmasq and back up /var/lib/misc/dnsmasq.leases (or distro-specific path); after restart, restore lease file and restart dnsmasq to preserve mapping. Test in a maintenance window.

Diagnostic step 2

Enable persistent static DHCP host entries in dnsmasq configuration for critical VMs using MAC→IP mappings to avoid dynamic reallocation on restart.

Diagnostic step 3

When resuming many VMs, stagger resumes and monitor DHCP server logs; consider scripting forced dhclient renewals across guests after dnsmasq reload to sync state.