VMware→KVM import: preserve guest static IP (registry/config-aware re-addressing)

[andrijapanicsb]

Type: Enhancement / follow-up
Related: follow-up to #13656 (VMware→KVM cold/warm migration into Ceph/RBD & Linstor). #13656
deliberately scopes this out; this issue tracks doing it properly.

Problem

When a VMware guest is imported/migrated to KVM, virt-v2v swaps the NIC hardware to virtio. The
guest therefore comes up with a new network adapter that has default (DHCP) configuration — a
guest that was statically addressed on VMware does not automatically keep that static IP inside
the OS after conversion.

CloudStack preserves the MAC and assigns the NIC an IP in its own IPAM, but nothing re-applies the
guest's in-guest static configuration (address / mask / gateway / DNS).

Where this matters — and where it doesn't

This is the key point, because it bounds the whole feature:

• Irrelevant on a CloudStack-managed network (has a VR / DHCP). The MAC is preserved and the
  virtual router hands the guest exactly the IP CloudStack allocated (a DHCP reservation keyed on the
  MAC). The guest DHCPs and gets a correct, stable, deterministic address with no in-guest work.
  This covers the large majority of deployments.
• Relevant on L2 / unmanaged / external networks with no DHCP, or where the guest must remain
  internally statically configured (appliances, compliance, apps bound to a fixed local config).
  Here the converted guest comes up with no usable address (or a DHCP lease it shouldn't have) and
  loses connectivity until someone reconfigures it inside the OS.

So this is not a universal gap — it's specifically the no-DHCP / must-stay-static case that an
operator hits on layer-2 style networks.

Why the simple approach isn't enough

An early iteration in #13656 passed virt-v2v --mac <mac>:ip:<addr> built from VMware Tools data. It
was removed because it is fundamentally unreliable:

• It only sees anything when the source is powered on with Tools (nothing for a cold/powered-off
  source), and even then, via the deprecated flat field, it recovers only the address — no
  prefix/gateway/DNS.
• It cannot distinguish static from DHCP — it would happily pin a DHCP lease as a static address.
• virt-v2v's --mac ip: is effectively Windows-only anyway.

Result: an address-only, default-off, guess that promises more than it delivers. Correct handling
needs ground-truth about each NIC's addressing, independent of power state.

Recommended approach

Determine each NIC's real addressing from the guest itself, then apply it deterministically on the
migrated NIC, keyed by the preserved MAC.

Windows — read the SYSTEM registry hive offline (works regardless of power state, no Tools needed):

• …\Services\Tcpip\Parameters\Interfaces\{GUID} per interface: EnableDHCP (static vs DHCP —
  ground truth), IPAddress / SubnetMask, DefaultGateway, NameServer.
• Correlate interface ↔ NIC by MAC (NetworkSetup2 kernel address / class NetworkAddress).
• Apply the static config on first boot via a MAC-keyed netsh script (and/or virt-v2v --mac).

Linux — the analogous idea is renderer/config inspection (ifcfg / NetworkManager keyfiles /
netplan / systemd-networkd), or, simpler and bounded, an explicit "normalize to DHCP" option so the
VR reservation delivers the IP. (Linux static configs are text files that survive on disk but break on
interface rename; MAC-matched configs are the robust form.)

Destination-network authority (the routing trap). Gateway and prefix are properties of the
destination subnet, not the source guest (classic same-subnet-different-gateway breakage). Take
gateway/prefix from the mapped destination network; keep the source IP/DNS. Guard: "be sure, or don't
touch it" — if the source IP does not fit the destination subnet (or the prefix disagrees),
disable preservation for that NIC rather than half-applying a config that can't route, and report
why.

Design principles

• Opt-in and per-NIC. Off by default; the operator (or a per-NIC decision) turns it on.
• Fail-safe. Never half-apply; on any uncertainty, leave the guest to DHCP and log the reason.
• Operator override. Allow choosing the IP / DHCP-vs-static per NIC, backed by the detected
  ground truth.
• Cold and warm should behave identically (registry/config read is off the disk, power-independent).

Non-goals

• Not required for managed networks with a VR (already deterministic via MAC + DHCP reservation).
• Not a general in-guest network-management framework — scoped to preserving/normalising addressing at
  import time.

Acceptance criteria (high level)

• A statically-addressed Windows guest migrated onto a no-DHCP destination boots with its intended
  static config (address/mask/gateway/DNS) on the new virtio NIC — or, if it can't be applied safely,
  is left DHCP with a clear log line (never a broken half-config).
• DHCP guests and managed-network guests are unaffected.
• Static/DHCP is decided from guest ground truth, not a runtime IP guess.
• Behaviour is identical for cold and warm migrations.