A VM that must speak on the LAN (real IP, reachable from outside, no NAT) needs its own MAC address — otherwise the switch cannot tell which traffic belongs to the host and which belongs to the VM. macvtap (a KubeVirt upstream feature) solves this via a virtual interface directly on the physical NIC. Correction: on this cluster, macvtap was attempted — registering it via the HyperConverged CR fails ('unknown field spec.networking'), and VM start fails with 'couldn't find configuration for network binding: macvtap'. OpenShift Virtualization does not support macvtap as a network binding plugin. Official documentation (OCP 4.20) confirms: Bridge CNI and VLAN are not supported; OVN-Kubernetes secondary overlay networks are recommended instead.
- OVN-K localnet: officially supported, documented, works even when the NIC is already in use
- Uses the existing br-ex infrastructure — no additional bridge required
- NetworkPolicies and other OVN-K features remain available
- macvtap: NOT supported in OCP — the NAD can be created, but VM start fails
- OVN-K localnet requires a NodeNetworkConfigurationPolicy with bridge-mappings (NMState >= 2.2.x)
- Somewhat more configuration effort than a simple macvtap NAD
On this Hetzner SNO, eno2 is already fully consumed by OVN-K on br-ex. An additional Linux bridge directly on eno2 is not possible. macvtap would have bypassed that in theory, but is not usable in OCP — the official and tested path is OVN-K localnet (see TC-NET-002), which works via br-ex without occupying the NIC again. Verified on 30 Jun 2026: the NNCP with ovn.bridge-mappings was applied successfully on this cluster (Status Available, 'successfully reconciled') — the correct field name is bridge (not bridge-mapping, a common pitfall).