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.
Verify MCE and HyperShift from PRE-10. All pods Running, CLI works.
Additionally: check pod capacity on the SNO node BEFORE creating a Hosted Cluster (default is max 250 pods per node) — a single Hosted Cluster requires approximately 30–40 additional pods for the control plane, independent of free CPU/RAM. If the node is already near the pod limit (e.g. due to many leftover test VMs/deployments from previous test cases), creation fails with 'Too many pods' even though CPU/RAM would be available.
Confirm these before running steps:
1oc get mce
2oc get pods -n hypershift
3hcp version
4oc get hostedcluster -A
oc describe $(oc get nodes -o name) | grep -A3 'Non-terminated Pods'oc get node -o jsonpath='{.items[0].status.allocatable.pods}{"\n"}'5If the maximum pod count per node is 250 and you plan to use a single-node cluster, you will most likely need to increase the limit. Create a KubeletConfig with maxPods set to 500 (full block in the Commands / YAML tab)
6One-time: allow wildcard routes on the management cluster — required later for console access to Hosted Clusters (TC-HCP-002); best done now
oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{"op":"add","path":"/spec/routeAdmission","value":{"wildcardPolicy":"WildcardsAllowed"}}]'⚠️ 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.
Import over OVN-K — bandwidth is shared with OCP traffic on eno2/br-ex in this cluster