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

**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 :ip:` 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.