Skip to content

Comments

fix(vm): stabilize the order of network interfaces#2001

Draft
LopatinDmitr wants to merge 1 commit intomainfrom
fix/vm/fix-interfaces-order
Draft

fix(vm): stabilize the order of network interfaces#2001
LopatinDmitr wants to merge 1 commit intomainfrom
fix/vm/fix-interfaces-order

Conversation

@LopatinDmitr
Copy link
Contributor

@LopatinDmitr LopatinDmitr commented Feb 16, 2026

Description

This PR stabilize the order of network interfaces:

  • API: Add optional id field to NetworksSpec and NetworksStatus so each network entry has a stable identifier.

  • Controller: Introduce MacAddressPool and ID-based logic in CreateNetworkSpec: MACs are bound to network name (from status), so reusing the same spec entries (with same IDs) after removal preserves MACs and interface names. Allocate and persist network IDs in the reconciler; validators enforce that existing IDs are immutable and in range 1–16383.

  • e2e: Add test “verifies interface name persistence after removing middle ClusterNetwork”: create VM with Main + two ClusterNetworks, record last interface name via SSH, remove the middle ClusterNetwork from spec (keeping first and third entries so IDs are preserved), reboot via VMOP, then assert the last interface name is unchanged.

Example spec before (Main + two ClusterNetworks):

spec:
  networks:
    - type: Main
      id: 1
    - type: ClusterNetwork
      name: cn-1003-for-e2e-test
      id: 2
    - type: ClusterNetwork
      name: cn-1004-for-e2e-test
      id: 3

After removing the middle network, user keeps the same structs for the remaining networks so IDs (and thus MACs/interface names) stay stable:

spec:
  networks:
    - type: Main
      id: 1
    - type: ClusterNetwork
      name: cn-1004-for-e2e-test
      id: 3

Why do we need it, and what problem does it solve?

When a VM has several additional networks (e.g. Main + two ClusterNetworks) and the user removes one of them from spec.networks, the controller re-builds the interface list. Without stable IDs, the remaining networks could get new MAC addresses and thus new interface names inside the guest (e.g. eth2 becoming eth1). That breaks guest-side configuration (scripts, Netplan, static IPs) and complicates automation.

Checklist

  • The code is covered by unit tests.
  • e2e tests passed.
  • Documentation updated according to the changes.
  • Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vm
type: fix
summary: "Stabilize the order of network interfaces"

@LopatinDmitr LopatinDmitr force-pushed the fix/vm/fix-interfaces-order branch 7 times, most recently from 3cb8cd3 to b6626ac Compare February 17, 2026 12:18
@LopatinDmitr LopatinDmitr modified the milestones: v1.7.0, v1.6.0 Feb 19, 2026
@LopatinDmitr LopatinDmitr force-pushed the fix/vm/fix-interfaces-order branch 2 times, most recently from f4cb252 to 690f777 Compare February 24, 2026 21:27
@LopatinDmitr LopatinDmitr changed the title fix(vm): fix interface's order fix(vm): stable interface's order Feb 24, 2026
@LopatinDmitr LopatinDmitr changed the title fix(vm): stable interface's order fix(vm): stabilize the order of network interfaces Feb 24, 2026
Signed-off-by: Dmitry Lopatin <dmitry.lopatin@flant.com>
@LopatinDmitr LopatinDmitr force-pushed the fix/vm/fix-interfaces-order branch from 690f777 to 1dd9d76 Compare February 24, 2026 21:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant