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.
Controlled removal of hc-demo after creation (TC-HCP-002) and scaling (TC-HCP-003) are complete. Deliberately a separate test case so destroy is not run accidentally too early, and verification of cleanup completeness (namespace gone, VMs gone, pod capacity freed again) is tested as a standalone step — equally important in practice as creation, since leftover remnants directly block pod capacity for the next Hosted Cluster.
Confirm these before running steps:
1Remove Hosted Cluster
hcp destroy cluster kubevirt --name hc-demo --namespace clusters2Observe until everything is truly gone
watch oc get hostedcluster -n clusters3Verify completeness — worker VMs, namespace
oc get vm -n clusters-hc-demooc get ns clusters-hc-demo4Check MetalLB pool state — pool itself remains, directly reusable for the next Hosted Cluster
oc get ipaddresspool external-pool -n metallb-systemoc get svc -A | grep <external-pool-ip> # or: oc get ipaddresspool external-pool -n metallb-system -o yaml5If it hangs (finaliser issue, occurs occasionally when a worker VM sticks during deletion)
oc get hostedcluster hc-demo -n clusters -o jsonpath='{.metadata.finalizers}'oc patch hostedcluster hc-demo -n clusters --type=merge -p '{"metadata":{"finalizers":[]}}'6If multiple Hosted Cluster remnants are suspected in general (e.g. from earlier failed attempts before the SingleReplica fix)
oc get hostedcluster -Aoc get ns | grep clusters-Import over OVN-K — bandwidth is shared with OCP traffic on eno2/br-ex in this cluster