Format:

Export:

Test cases(24 of 50)

Show

Priority

Category

0/24 completed0%

Complete prerequisites first ([PRE-01](PRE-01) → [PRE-08](PRE-08) minimum) before running these tests. Go to prerequisites

Verify golden image import and PVC clone

Create and boot first VM from template (RHEL 9)

Masquerade uses OVN-K over eno2/br-ex — no bridge setup required

VM live migration (SNO: expected failure)

NOT POSSIBLE on SNO — live migration requires ≥2 nodes. Documented as an expected failure.

Create VM snapshots and perform restore

Test on local storage

Clone VM and use as template (Golden VM pattern)

Pod network (masquerade) and VM access via Service

Optimal for single-NIC — OVN-K over eno2/br-ex, no bridge setup required

VM directly reachable on LAN (OVN-K localnet) -- ⚠ HETZNER TOS VIOLATION

✗ 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.

SR-IOV – high-performance networking (HW missing)

✗ 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.

Test VLAN isolation — VMs in separate software bridges

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.

Inter-VLAN routing via router VM (br-net1 ↔ br-net2)

purely internal software bridges br-net1/br-net2 (port: []) — no VM MAC leaves the node

VM with 3 Network Interfaces (Management + Data + Storage)

OVN-Kubernetes UserDefinedNetwork (Layer2 Overlay)

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.

Verify MetalLB Basic Functionality

2 Pools: internal-pool binds to br-net1 — external-pool binds to eno2, requires a 2nd public IP

Expose VM Services via MetalLB (SSH)

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

MetalLB BGP Mode with Router Peering

⚠️ 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.

Multiple IP Pools and Namespace Isolation

MetalLB + Isolated Software Bridges: LB IPs per Bridge Interface

L2Advertisement explicitly binds to br-net1/br-net2 — ARP announcements stay node-internal.

Variant A (Hetzner, this SNO): LB IPs are announced per software bridge (br-net1/br-net2), not on eno2.

Variant B (on-prem with real VLAN trunk) would be analogous via eno2.10/eno2.20.

Prerequisites checklist

Confirm these before running steps:

1Check whether vm-net1-a/vm-net1-b/vm-net2-c still exist (e.g. from TC-VLAN-001) — if TC-VLAN-001 cleanup was run, they do NOT exist anymore

oc get vmi vm-net1-a vm-net1-b vm-net2-c -n vmtest

→ if 'NotFound': recreate all three VMs with the 'FALLBACK: recreate VMs' block in the Commands / YAML tab, then continue with the next step

2Apply two dedicated pools per bridge interface (full block in the Commands / YAML tab)

3Verify the pools are created

oc get ipaddresspool -n metallb-system

→ net1-pool (br-net1) and net2-pool (br-net2) must be present as separate ranges

4Verify L2Advertisement per pool — binds the pool to the correct bridge interface

oc get l2advertisement -n metallb-system -o yaml

→ net1-pool: interfaces shows br-net1; net2-pool: interfaces shows br-net2

5Apply service with explicit net1-pool annotation (block in the Commands / YAML tab)

6Verify the service is created

watch oc get svc vm-net1-lb -n vmtest

→ IP must come from the net1-pool range (e.g. 192.168.10.200)

7Verify ARP visibility on the correct bridge interface — RHCOS has NO tcpdump in the host image, toolbox is required

NODE=$(oc get node -o name)

oc project vmtest; oc debug $NODE

In the debug pod: chroot /host, then: toolbox (first start pulls image, 30–60s)

In the toolbox container: tcpdump -i br-net1 -e -c 5 arp

→ ARP requests/replies for the LB IP appear ONLY here, not on br-net2

→ Continue with the next step in the second terminal (see below)

8In a second terminal: from vm-net1-b (same bridge), access the LB IP

virtctl ssh fedora@vm/vm-net1-b -n vmtest -i $HOME/.ssh/ocp-vm-key

nc -zv 192.168.10.200 22

→ successful (same bridge)

9Check VM in vm-net2-c (other bridge)

virtctl ssh fedora@vm/vm-net2-c -n vmtest -i $HOME/.ssh/ocp-vm-key

nc -zv 192.168.10.200 22

→ ⚠️ successful (even on a different bridge)

10Apply NetworkPolicy to block access to the LB IP from the other bridge (full block in the Commands / YAML tab)

11Retest from vm-net1-b (same bridge), access the LB IP

virtctl ssh fedora@vm/vm-net1-b -n vmtest -i $HOME/.ssh/ocp-vm-key

nc -zv 192.168.10.200 22

→ successful (same bridge) - still works

12Check VM in vm-net2-c (other bridge)

virtctl ssh fedora@vm/vm-net2-c -n vmtest -i $HOME/.ssh/ocp-vm-key

nc -zv 192.168.10.200 22

→ ✅ → refused, is now blocked

13Clean up everything

oc delete svc vm-net1-lb -n vmtest

oc delete ipaddresspool net1-pool -n metallb-system

oc delete ipaddresspool net2-pool -n metallb-system

oc delete l2advertisement l2-net1 -n metallb-system

oc delete l2advertisement l2-net2 -n metallb-system

oc delete networkpolicy allow-only-vm-net1-b -n vmtest

oc delete vm vm-net1-a vm-net1-b vm-net2-c -n vmtest

Verify HyperShift Operator and MCE

Single-NIC OK — HyperShift pods use the OVN-K pod network.

⚠️ Check Pod/Node Capacity before starting TC-HCP-002 — see steps below.

Create Hosted Cluster with KubeVirt provider

⚠️ SNO EXAMPLE INSTALLATION: --control-plane-availability-policy SingleReplica is mandatory on a single-node cluster.

Scale NodePool and change VM flavour

⚠️ Be sure enough compute resources are available on the SNO node before starting this test.

Remove Hosted Cluster cleanly (destroy)

DataVolume import from multiple sources

Import over OVN-K — bandwidth is shared with OCP traffic on eno2/br-ex in this cluster

Create VM backup with OADP

Restore VM from OADP backup

/ open searchJ/K next / previous card? keyboard shortcutsEsc close panels

🧪 Test cases(24 of 50)

Test cases(24 of 50)