Stop stale saved/appended startup-configs from hijacking the management IP

[alxrxs]

Summary

Every vrnetlab launcher configures the node's management interface itself, every boot, from the container's actual clab-assigned IP -- that's the real source of truth for management addressing. Several launchers also apply a user-supplied startup-config after that (commonly one produced by containerlab save, which captures the full running-config including whatever the device currently has on its management interface). When both configure the same interface, the appended one competes with the launcher's: on IOS-family platforms (IOS-XR/IOS-XE/NX-OS/ASA) a later address under the same interface replaces it, so a stale one makes the node unreachable; on Junos it is added alongside (Junos keeps multiple addresses per interface), so the node stays reachable via the launcher's address but carries a stale/foreign one. Either way the launcher's address should be the interface's only one.

If that's a stale saved address -- which happens whenever the container is later assigned a different mgmt IP (a partial --node-filter deploy, Docker IPAM handing out a different address, etc.), or when a hand-written config carries its own mgmt address -- the node comes up completely healthy and functional but with the wrong (or an extra) address on its management interface -- unreachable at the IP clab/DNS expect on the IOS-family kinds, and carrying a stale/duplicate mgmt address on Junos. Nothing in the container healthcheck or the launcher's readiness signal catches this: from clab's point of view the node is "healthy."

I hit and root-caused this on my own lab running the XRd vRouter kind: containerlab save had captured a running-config with MgmtEth0/RP0/CPU0/0 pinned to one IP; a later redeploy gave the container a different IP; the node reported healthy and nothing answered ARP for the address clab reported. I filed a companion save-side fix in containerlab (srl-labs/containerlab#3263) so containerlab save stops writing the mgmt address into the saved config in the first place -- this PR is the launcher-side half, which also covers configs already saved with an address, or hand-written ones.

Approach: strip the mgmt interface's address by name

common/vrnetlab.py gains strip_mgmt_interface_config(config_text, mgmt_intf, style), and each launcher calls it on the startup-config it's about to append/merge, passing its own management interface name.

It's keyed on the interface name, not the address value, and that distinction is the whole point: the failure is a stale address -- a different value than the one the launcher just configured -- so a value-based filter can never catch it (it would only match when the appended address already equals the current one, i.e. exactly when there's no conflict). The interface identity is the only invariant, so the filter drops every address the appended config puts on that interface, whatever the value, leaving the launcher's own as the only one.

Structure-aware, not a blind line delete:

• style="ios" (IOS / IOS-XE / IOS-XR / NX-OS / ASA): walks the interface <name> block and drops ip/ipv4/ipv6 address leaves, keeping the interface header and any other per-interface config. The name match is whitespace/case-insensitive (IOS-XR accepts MgmtEth 0/RP0/CPU0/0 and MgmtEth0/RP0/CPU0/0 interchangeably and launchers emit both).
• style="junos": handles both hierarchical (<name> { ... address x; ... }, brace-scoped, with address x { ... } option-blocks removed whole so braces stay balanced) and flat set-style, matching the family inet[6] address element so a description that merely mentions "address" is left alone.

launcher	interface	style
xrd-vrouter, xrv9k	MgmtEth0/RP0/CPU0/0	ios
xrv	MgmtEth0/0/CPU0/0	ios
csr1000v, c8000v	GigabitEthernet1	ios
cat9kv	GigabitEthernet0/0	ios
n9kv, nxos	mgmt0	ios
asav	Management0/0	ios
vjunosevolved	re0:mgmt-0	junos
vjunosrouter, vjunosswitch, vsrx, vmx	fxp0	junos
vqfx	em0	junos

vios (its entire config, mgmt interface included, comes from the startup-config alone -- no launcher stanza to protect) and c8000v's MIME-wrapped startup-config branch are deliberately left untouched; stripping either would remove the only source of mgmt config.

Also in this PR (XRd-vRouter reliability, how I found the bug)

• qemu-guest-agent channel (common/vrnetlab.py) -- a virtio-serial chardev on a per-VM unix socket (/run/qga<n>.sock) wired to org.qemu.guest_agent.0, plus qemu-guest-agent installed in the xrd-vrouter golden image. A unix socket (rather than a TCP port) avoids any collision with the host-forwarded mgmt ports no matter how many VMs a node runs; nothing in the launcher connects to it -- it's reached by docker exec-ing into the container and talking to the socket. This is what let me pull the actual root cause out of a node that was "healthy" but unreachable, whose serial console has no interactive getty. Inert on other kinds unless they install the agent.
• xrd-vrouter honest health -- guest-init.sh's wait loop emitted the readiness marker on timeout even if MgmtEth never came up, so the launcher reported healthy regardless. Now the marker is gated on a real Up/Up check; on failure it dumps diagnostics to the console instead.
• xrd-vrouter Dockerfile now names vrnetlab.py in its COPY. Unlike kinds that COPY *.py /, this Dockerfile lists files explicitly, so without it the image kept the older /vrnetlab.py from the pinned base and launch.py's calls into the current common lib crashed with AttributeError.

Testing

The strip_mgmt_interface_config helper was verified against a standalone matrix of adversarial inputs (this repo has no Python test harness, so it is not committed as a CI test): IOS-XR/IOS-XE/NX-OS leaf drops with the header preserved; whitespace-tolerant name match; a stale address different from anything passed in still dropped because the match is on the interface name; other-interface-untouched; a flush-left address leaf (with and without a preceding non-address leaf); Junos hierarchical leaf + dual-stack + address { ... } option-block; Junos set-style; and a description carrying both the mgmt IP and the word "address" (IOS, Junos hierarchical, and Junos set-style) left alone. (The containerlab companion PR does commit an equivalent Go test, nodes/vr_node_mgmtfilter_test.go.)

End-to-end on a real containerlab lab, both platforms I run, from images built via this branch's build path:

• XRd vRouter: deployed with a startup-config carrying a stale MgmtEth0/RP0/CPU0/0 v4 and v6 address. Both stripped from the built first-boot.cfg; MgmtEth came up Up/Up at the real container IP on both families; ssh clab@<real-ip> works.
• vJunosEvolved: deployed with a stale re0:mgmt-0 address. Stripped from the built juniper.conf; re0:mgmt-0 kept the launcher value; ssh admin@<real-ip> works.

I don't have running instances of the other 13 patched kinds, so those are verified by reading each launcher's actual config-application path before changing it (not assumed from a sibling) plus python -m ast on every file. Happy to adjust anything that doesn't match a maintainer's closer knowledge of a specific platform.