VM with three interfaces: masquerade (management/SSH), br-net1 (application data), br-net2 (storage replication). Separation of traffic types as in production environments — on this Hetzner SNO via pure software bridges (Variant A), not real VLANs.
Prerequisites checklist
Confirm these before running steps:
1Re-verify prerequisites: NNCP and NetworkAttachmentDefinitions (NADs) must exist
oc get nncp→ ONE NNCP named sno-software-bridges must show STATUS=Available (defines br-net1/2/3 together, not three separate NNCPs)
oc get network-attachment-definition -n vmtest→ net1-bridge, net2-bridge and net3-bridge must be listed (NOT vlan10-bridge/vlan20-bridge — that is Variant B/on-premise)
2Verify SSH key secret — without it login is not possible, as the Fedora containerDisk image has no console password by default
oc get secret vm-ssh-key -n vmtest→ if missing: create from PRE-07 (ssh-keygen + oc create secret generic vm-ssh-key --from-file=key=...)
3Apply VM manifest — already includes accessCredentials with the SSH key from vm-ssh-key
4Wait for VM start until Phase Running is reached
oc get vmi multi-nic-vm -n vmtest -w→ PHASE: Scheduling → Scheduled → Running (typically under 60 seconds)
5Brief wait for key propagation — cloud-init must boot and set the SELinux boolean before qemu-guest-agent accepts the SSH key
sleep 30
6Log in via SSH
virtctl ssh fedora@vm/multi-nic-vm -n vmtest -i ~/.ssh/ocp-vm-key7List all three interfaces and verify initial state
ip addr (while in SSH session)→ enp1s0 already has an IP (10.0.2.x, from masquerade)
→ enp2s0/enp3s0 are UP but without IP
8Assign static IPs on enp2s0 and enp3s0 (these networks have no DHCP server)
sudo ip addr add 192.168.10.50/24 dev enp2s0sudo ip addr add 192.168.20.50/24 dev enp3s0sudo ip link set enp2s0 upsudo ip link set enp3s0 up9Verify configuration — all three interfaces must now show an IP
ip addr→ enp1s0: 10.0.2.x
→ enp2s0: 192.168.10.50/24
→ enp3s0: 192.168.20.50/24
10Traffic separation is already structurally given by the static IPs on separate, isolated bridges (no cross-traffic between br-net1/br-net2 possible, see TC-VLAN-001)
11Optional, for deeper proof at packet level: tcpdump on the node — RHCOS has NO tcpdump in the host image (deliberately minimal), toolbox container is required
NODE=$(oc get node -o name)oc debug $NODEIn the debug pod:
chroot /hostThen:
toolbox→ first start pulls a RHEL tools container image (registry.redhat.io/rhel9/support-tools), takes 30–60s
In the toolbox container:
tcpdump -i br-net1 -c 5 -n→ shows only traffic from enp2s0 (br-net1); repeat the same command with -i br-net2 for comparison
→ shows only enp3s0 traffic
12Finally, confirm SSH access again via the management path (enp1s0/masquerade)
virtctl ssh fedora@vm/multi-nic-vm -n vmtest -i ~/.ssh/ocp-vm-key→ SSH works independently of enp2s0/enp3s0 status — management path is decoupled from data traffic
13Clean up (optional, if created only for testing)
oc delete vm multi-nic-vm -n vmtest