fix(vm): fix flap condition VirtualMachineIPAddressReady

[LopatinDmitr]

Description

The guest-agent merge in KubeVirt processed IPv4 and IPv6 independently and cleared the address of a family from the VMI interface status whenever the guest-agent reported no address for that family. When the guest transiently reported only a link-local address (e.g. fe80::/10) or no address at all while the assigned IPv4 was being (re)acquired via DHCP, the pod-cache IPv4 was wiped from the status. Combined with the cache being repopulated on cycles without guest-agent data, the reported interface IP flapped between the assigned IPv4 and the IPv6 link-local address — which in turn flapped the VirtualMachineIPAddressReady condition.

With the bundled fix, guest-agent IP data augments, but never clears, the existing per-family address: an address already present in the status (originating from the pod cache) is kept even when the guest-agent reports none for that family.

Related: deckhouse/3p-kubevirt#135

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

A VM whose guest reports only an IPv6 link-local address (no IPv4) caused the internal KubeVirt VMI status to flap between the assigned IPv4 and the link-local IPv6:

# k get intvirtvmi -n q2 -w
NAME   AGE     PHASE     IP                          NODENAME         READY
q2     4m19s   Running   10.66.10.77                 d8-virt-node-0   True
q2     5m1s    Running   fe80::f4e1:74ff:fe94:b81a   d8-virt-node-0   True

This flap propagated to the VirtualMachineIPAddressReady condition, which oscillated between True and False:

- lastTransitionTime: "2026-04-09T16:46:29Z"
  message: IP address (10.66.10.77) is not among addresses assigned to 'default'
    network interface (fe80::f4e1:74ff:fe94:b81a)
  reason: VirtualMachineIPAddressNotAssigned
  status: "False"
  type: VirtualMachineIPAddressReady
---
- lastTransitionTime: "2026-04-09T16:43:57Z"
  reason: VirtualMachineIPAddressReady
  status: "True"
  type: VirtualMachineIPAddressReady

The constant condition churn produces noisy transitions and events and makes the VM look unstable.

What is the expected result?

1. Start a VM whose guest agent reports an IPv6 link-local address (or briefly no address) on the default interface.
2. Watch the internal VMI and the VM condition:

   k get intvirtvmi -n <ns> <vm> -w
   k get vm -n <ns> <vm> -o yaml | yq '.status.conditions[] | select(.type=="VirtualMachineIPAddressReady")'
   

3. The reported IP stays the assigned IPv4 and VirtualMachineIPAddressReady stays True — no flapping.

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: core
type: fix
summary: "Fixed flapping of the VirtualMachineIPAddressReady condition when the VM had no guest-agent IP."