periodic-cluster-api-provider-vsphere-e2e-supervisor-main is flaky

[sbueringer]

periodic-cluster-api-provider-vsphere-e2e-supervisor-main is flaky since the multi-network PR was merged.

Here are a few examples:

• https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/periodic-cluster-api-provider-vsphere-e2e-supervisor-main/1959390426087559168
• https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/periodic-cluster-api-provider-vsphere-e2e-supervisor-main/1959028035667628032
• https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/periodic-cluster-api-provider-vsphere-e2e-supervisor-main/1958303252831277056

triage link: https://storage.googleapis.com/k8s-triage/index.html?text=resourceVersions%20didn%27t%20stay%20stable&job=.*cluster-api.*vsphere.*main

In general the test is testing a Cluster upgrade with Runtime SDK. At the end of the test we verify that the resourceVersions stay stable.

The tests are failing because the resourceVersions do not stay stable. It looks like after a while a second IP shows up (in status fields added via the multi-network PR):

  	spec:
  	... // 24 identical lines
  	        addresses:
  	        - address: 192.168.32.228
+ 	          state: preferred
+ 	        - address: 192.168.35.192
  	          state: preferred
  	        - address: fe80::250:56ff:feae:c5b5
  	... // 28 identical lines

Some notes:

• the same additional IP also shows up on the corresponding VirtualMachine CR
• the test is using the dummy network provider

[DanielXiao]

According to status of VirtualMachine, there are 2 IP addresses on the same interface eth0:

  network:
    config:
      dns:
        hostName: k8s-upgrade-wi-bt9zt
      interfaces:
      - ip:
          dhcp:
            ip4:
              enabled: true
        name: eth0
    interfaces:
    - deviceKey: 4000
      ip:
        addresses:
        - address: 192.168.32.114
          state: preferred
        - address: 192.168.35.208
          state: preferred
        - address: fe80::250:56ff:feae:f9dd
          state: unknown
        macAddr: 00:50:56:ae:f9:dd
      name: eth0

VSphereMachine just mirrors the same information:

status:
  addresses:
  - address: 192.168.32.114
    type: InternalIP
  conditions:
  - lastTransitionTime: "2025-08-22T23:27:30Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-08-22T23:27:30Z"
    status: "True"
    type: VMProvisioned
  network:
    interfaces:
    - deviceKey: 4000
      ip:
        addresses:
        - address: 192.168.32.114
          state: preferred
        - address: 192.168.35.208
          state: preferred
        - address: fe80::250:56ff:feae:f9dd
          state: unknown
        macAddr: 00:50:56:ae:f9:dd
      name: eth0
  ready: true

We need to figure out why the VM get 2 IP addresses on the same interface. The additional IP sometimes disappeared, see VirtualMachine and VSphereMachine in another test. The IP addresses on a VM is flaky