Bug 2177586

It looks like a backend bug.

My current understanding:
We need to define the interface in order to keep the macAddress stable.
At the same time I think that there should be no need to create the network.

@phoracek @lyarwood should we introduce a special case where count(interfaces) == 1, then we assume that it should be connected to the default pod network without it being defined?

IOW how can we permit setting the macAddress while not having the requirement to also create the network struct.

(In reply to Fabian Deutsch from comment #1)
> It looks like a backend bug.

IMHO what follows is more of a RFE.
 
> My current understanding:
> We need to define the interface in order to keep the macAddress stable.
> At the same time I think that there should be no need to create the network.
> 
> @phoracek @lyarwood should we introduce a special case
> where count(interfaces) == 1, then we assume that it should be connected to
> the default pod network without it being defined?
> 
> IOW how can we permit setting the macAddress while not having the
> requirement to also create the network struct.

Yeah a special case would make sense but in the context of this bug it would still be up to the UI to define this interface and MAC.

The fact that an interface isn't provided at the moment isn't a bug IMHO, the issue is more with how this default behaviour is being communicated to the end-user through the UI.

In the short term I think all we need is a simple message outlining this behaviour with the ability for a user to customise the VirtualMachine with an interface and associated network if they want different behaviour.

Thoughts?

Good points, Lee.

If #1 from original description is not a functional problem, but only #2 is the problem, then I agree that it's about communicating this properly on the UI.

@gouyang a) does the vm have network connectivity even without the yaml part of #1 and b) is the UI issue the biggest problem you are seeing?

(In reply to Fabian Deutsch from comment #3)

> @gouyang a) does the vm have network connectivity even without the yaml part of #1

The VM have network connectivity without the interface defined in the YAML. 

> b) is the UI issue the biggest problem you are seeing?
Yes, it looks strange when user navigate to network interfaces tab and see "not found", as it used to be pod networking there.
Without the interface defined in the YAML:
1. user cannot edit boot order to select an nic.
2. user cannot edit the pod networking configuration in network interfaces tab

@fdeutsch and @lyarwood how do we expect users that look at the yaml to understand the network without the interface section?
Where can they see things like the MAC address etc.?

(In reply to Ronen from comment #5)
> @fdeutsch and @lyarwood how do we expect users that
> look at the yaml to understand the network without the interface section?
> Where can they see things like the MAC address etc.?

https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/#ports

If an interface etc is not provided by the VirtualMachine then all of that detail will be available in the VirtualMachineInstance at runtime:

./cluster-up/kubectl.sh apply -f examples/vm-cirros.yaml
[..]
./cluster-up/kubectl.sh get vms/vm-cirros -o json | jq .spec.template.spec.domain.devices.interfaces
null
./cluster-up/virtctl.sh start vm-cirros
[..]
./cluster-up/kubectl.sh get vmis/vm-cirros -o json | jq .spec.domain.devices.interfaces
selecting docker as container runtime
[
  {
    "bridge": {},
    "name": "default"
  }
]

Note obviously that macAddress is optional [1] so the default interface doesn't provide one, AFAIK a random MAC is assigned to the underlying guest through libvirt.

Anyway, reiterating my point from above. IMHO the UI needs to highlight this default behaviour clearly on the interface/network tab with some kind of text saying `using default interface and network` while allowing a user to manually define their own interface etc with a static MAC address if they don't want that behaviour.

[1] http://kubevirt.io/api-reference/main/definitions.html#_v1_interface

+1 Lee.

We can picku pth pattern of a namespace without VMs, and display a message alongside:

"""
No interface definitions found.
The VM has no networks and interfaces specified, therefore it's using a default interface and network configuration.

[Create Interface]
"""

Please note:
On the VM level, the domain part is part of a template (VM.spec.template <-- this is the template for the VMI).
Once the VMI is getting launched, then - within the VMI object - the network and interface _is_ getting created.

Thus by looking at the VMI level the correct network and interafces can be observed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Virtualization 4.13.0 Images security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:3205