Masquerade uses OVN-K over eno2/br-ex — no bridge setup required
Test cases(24 of 50)
Complete prerequisites first ([PRE-01](PRE-01) → [PRE-08](PRE-08) minimum) before running these tests. Go to prerequisites
NOT POSSIBLE on SNO — live migration requires ≥2 nodes. Documented as an expected failure.
Test on local storage
Optimal for single-NIC — OVN-K over eno2/br-ex, no bridge setup required
✗ NOT TESTABLE ON HETZNER -- TOS violation! OVN-K localnet works technically (verified 30.06.2026: ping successful), but any VM MAC that reaches eno2/the physical switch via this interface is detected and reported by Hetzner as an unauthorised MAC (server suspension threatened). Only the registered server MAC is permitted.
✗ NOT TESTABLE — SR-IOV requires a dedicated second NIC (Intel X710, Mellanox ConnectX). The sole NIC eno2 is consumed by OVN-K and cannot be used for SR-IOV VFs.
Variant A uses pure software bridges br-net1/2/3 (port: []) — no VM MAC leaves eno2/the physical switch, no TOS risk. Variant B (on-premises, trunk port) is relevant only with your own switch.
purely internal software bridges br-net1/br-net2 (port: []) — no VM MAC leaves the node
UserDefinedNetwork with Layer2 topology is a pure overlay (encapsulated Geneve tunnel within OVN-K) — explicitly NOT localnet, so no VM MAC leaves the node.
⚠️ DEDICATED NAMESPACE REQUIRED: see NOTE below.
2 Pools: internal-pool binds to br-net1 — external-pool binds to eno2, requires a 2nd public IP
external-pool uses a provider-registered additional IP (e.g. Hetzner Additional IP); MetalLB speaker announces with the node's own MAC.
⚠️ SHARED RESOURCE: external-pool currently has only ONE IP — Clean up after this test (delete vm-ssh-lb) before starting TC-HCP-002
⚠️ NOT usable by default on the current SNO cluster: there is no customer-controlled router in the path for peering. Left for documentation purposes and future tests.
L2Advertisement explicitly binds to br-net1/br-net2 — ARP announcements stay node-internal.
Single-NIC OK — HyperShift pods use the OVN-K pod network.
⚠️ Check Pod/Node Capacity before starting TC-HCP-002 — see steps below.
⚠️ SNO EXAMPLE INSTALLATION: --control-plane-availability-policy SingleReplica is mandatory on a single-node cluster.
⚠️ Be sure enough compute resources are available on the SNO node before starting this test.
Scale NodePool to 3 replicas and then change flavour (rolling update). Demonstrates elastic capacity without new hardware.
Confirm these before running steps:
- TC-HCP-002Create Hosted Cluster with KubeVirt provider
- Free resources on SNO node (min. 4 CPU + 8Gi extra)
1Current state:
oc get nodepool hc-demo -n clusters3Watch new worker VM:
watch oc get vm -n clusters-hc-demo4Wait until 3 Ready nodes:
oc get nodes --kubeconfig hc-demo.kubeconfigImport over OVN-K — bandwidth is shared with OCP traffic on eno2/br-ex in this cluster