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.
Worker nodes of the Hosted Cluster are KubeVirt VMs on the SNO. The control plane runs as pods. The only option for fully virtualised clusters on SNO.
Confirm these before running steps:
- TC-HCP-001Verify HyperShift Operator and MCE
- PRE-05Install OpenShift Virtualization Operator
- PRE-06Set up LVM Storage Operator — storage for VMs
- PRE-07Pull secret, import golden image, prepare SSH keys
- min. 8 CPU + 16Gi RAM free
- PRE-09Install MetalLB Operator and configure IP pools (3 options)
- TC-MLB-002Expose VM Services via MetalLB (SSH)
- ⚠️ maxPods set to 500 (SNO node) — default limit of 250 is often insufficient (see first step, CAUSES NODE REBOOT)
3Determine release image from running cluster:
RELEASE=$(oc get clusterversion version -o jsonpath='{.status.desired.image}')oc get svc -A | grep $(oc get ipaddresspool external-pool -n metallb-system -o jsonpath='{.spec.addresses[0]}' | cut -d/ -f1)5Run hcp create cluster kubevirt (full command in Commands / YAML tab)
6Watch worker VMs:
watch oc get vm -n clusters-hc-demo7HostedCluster status:
watch oc get hostedcluster -n clusters8Check etcd pods for verification — with correct SingleReplica configuration, ONLY 1 etcd pod must exist (not 3 with 2 stuck Pending)
oc get pods -n clusters-hc-demo -l app=etcd10Optional: Wait for kube-apiserver Service and patch to the correct pool — the Service is already type=LoadBalancer, only the pool annotation needs to be set
oc get svc kube-apiserver -n clusters-hc-demo -woc patch svc kube-apiserver -n clusters-hc-demo --type=merge -p '{"metadata":{"annotations":{"metallb.io/address-pool":"external-pool"}},"spec":{"loadBalancerIP":null}}'11Create DNS entry or local /etc/hosts entry for the API name (e.g. hc-demo-api.local)
12Retrieve and test kubeconfig
hcp create kubeconfig --namespace clusters --name hc-demo > hc-demo.kubeconfig13Reach Hosted Cluster web console
oc --kubeconfig hc-demo.kubeconfig get routes -n openshift-console14Perform some basic tests:
export KUBECONFIG=hc-demo.kubeconfigoc new-project testoc new-app nginxsleep 10oc get pods -n test15Check IP stability after MetalLB speaker restart (important for production!)
oc delete pod -n metallb-system -l component=speakeroc get svc kube-apiserver -n clusters-hc-demo⚠️ 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