andrijapanicsb opened a new issue, #13704:
URL: https://github.com/apache/cloudstack/issues/13704
**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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
