Modern approach without Linux bridge: OVN creates a Layer2 overlay network directly in the software stack. No VLAN on the switch required, no bridge setup on the node.
Feature available in OCP 4.14+.
The Namespace vmtest does not have this label and must never receive it: if set later, EVERY pod/VM in vmtest would be blocked until a primary UDN exists there — that would break all other test cases that use vmtest normally with the default network.
Therefore this test case gets its own dedicated namespace (vmtest-udn-primary), which exists only for the Primary UDN test.
Prerequisites checklist
Confirm these before running steps:
- OCP 4.21 (OVN-K)
- NO existing namespace with pods — label must be set at namespace creation, not retrospectively
1Create dedicated namespace WITH label — the label must be included in the same oc apply call as namespace creation, otherwise it does not take effect per documentation (full block in the Commands / YAML tab)
2→ Copy the complete 'Namespace block' from the Commands / YAML tab and paste into the terminal.
3Verify label
oc get ns vmtest-udn-primary --show-labels→ k8s.ovn.org/primary-user-defined-network must appear in the label list
4Apply UserDefinedNetwork (UDN) CR in the new namespace (block in the Commands / YAML tab)
5→ Copy the complete 'UDN block' from the Commands / YAML tab and paste into the terminal.
6Check UDN status
oc get userdefinednetwork udn-vm-net -n vmtest-udn-primary7Create first VM (VM block in the Commands / YAML tab) — binding to UDN is automatic via namespace label; IMPORTANT: interfaces.binding.name must be l2bridge (NOT masquerade — otherwise the VM silently lands in normal pod networking instead of the UDN)
8Create second VM (vm-udn-2, same namespace, same l2bridge binding)
Paste the same block again, only change 'name: vm-udn-1' to 'name: vm-udn-2'
9Wait until the VMs are Running
watch oc get vmi vm-udn-1 vm-udn-2 -n vmtest-udn-primary10Brief wait until cloud-init has completed and set the password
sleep 30
11Log in via console on vm-udn-1 — works independently of the network tunnel mechanism, as it is purely serial (no SSH/port-forward involved)
virtctl console vm-udn-1 -n vmtest-udn-primaryLogin: fedora / fedora
ip addr # → interface with IP from 10.200.0.0/16, note IPLeave console: Ctrl+]
12Similarly log in on vm-udn-2 and note IP
virtctl console vm-udn-2 -n vmtest-udn-primaryLogin: fedora / fedora
ip addrLeave console: Ctrl+]
13Test communication between the two VMs in the UDN (re-open console session on vm-udn-1)
virtctl console vm-udn-1 -n vmtest-udn-primaryping <ip-of-vm-udn-2>→ successful reply = Layer2 overlay works without bridge setup on the node
14For verification: no additional bridge interface required on the node (difference from TC-MULTUS-001)
NODE=$(oc get node -o name)oc debug $NODE -- chroot /host ip link show | grep -i br-net→ no additional bridge visible for UDN traffic; everything runs as OVN-K Geneve overlay
15Clean up: default — delete entire namespace (removes VM + UDN in one step)
oc delete namespace vmtest-udn-primary16Exception: if the UDN is still needed for later tests, delete ONLY the VMs and keep namespace + UDN
oc delete vm vm-udn-1 vm-udn-2 -n vmtest-udn-primary