Red HatJoe TalericoBenchmark
Scaling localnet user-defined networks (CUDNs) in Red Hat OpenShift to 3,500 networks
Summary
Migrating from legacy virtualization with flat VLAN-based tenant networks to Red Hat OpenShift Virtualization often requires re-architecting network topology, creating friction. Red Hat OpenShift supports localnet user-defined networks (CUDNs) to preserve existing VLAN infrastructure while modernizing. Red Hat tested localnet CUDNs at scale, successfully managing up to 3,500 localnet CUDNs hosting over 3,500 active virtual machines. OVN-Kubernetes achieved 100% SSH connectivity, near-line-speed data-path performance over 100GbE interfaces without Geneve tunnel overhead, and stable control plane resource usage. Resource peaks reached approximately 5.5 CPU cores per worker node and 10 CPU cores on control plane nodes during bulk creation, then returned to low baselines.
Context
Migrating from legacy virtualization platforms with flat VLAN-based tenant networks to Red Hat OpenShift Virtualization often requires re-architecting the network topology, creating friction. Localnet CUDNs allow direct migration from VLAN tenant networks to preserve existing infrastructure layout. This post reports scale and performance testing results.
Approach / What changed
The team deployed Red Hat OpenShift 4.20.16 on 3 control plane nodes (Dell PowerEdge R760, 128 CPU cores each) and 20 worker nodes (same hardware). They configured NMState to map physical interfaces to an OVS bridge, then used kube-burner-ocp with the virt-cudn-density localnet test to create up to 3,500 CUDNs and 3,500 VMs. Control plane testing measured creation-phase metrics; data-path testing used a k8s-netperf branch to run East-West tests across 100GbE interfaces.
Takeaways
Localnet CUDNs eliminate Geneve tunnel encapsulation and complex routing between nodes, offloading overlay management to the physical network and drastically reducing OVN-Kubernetes overhead.
In testing, 3,500 localnet CUDNs with 3,500 VMs achieved 100% SSH success and near-line-speed data-path throughput over 100GbE interfaces, without tunnel-related CPU overhead.
During mass creation of CUDNs and VMs, OVN-Kubernetes CPU usage peaked at about 5.5 cores per worker node and 10 cores on the control plane, then returned to low idle baselines after creation completed.
FAQ
What hardware was used in the scale test?
The tests used Dell PowerEdge R760 nodes with 128 Intel Xeon Gold 6548Y+ CPU cores and 512 GiB RAM. The cluster had 3 control plane nodes and 20 worker nodes, plus one bastion node, all connected via 100GbE Mellanox ConnectX-6 adapters.
Were there any boot issues with VMs at scale?
Yes: during rapid scale-up of 1,500+ CUDNs, fewer than 0.1% of VMs experienced a hung guest OS boot state stuck at systemd-vconsole-setup or dracut-pre-mount. This was verified as an OS/boot timing anomaly unrelated to network plumbing; a VM reboot resolved it.
What is the recommended CPU allocation for peak creation phases?
For peak churn during mass deployment phases, Red Hat recommends allocating about 5.5 CPU cores per worker node and about 10 CPU cores on control plane nodes to handle the creation of thousands of CUDNs and VMs.
Source and freshness
- Source
- developers.redhat.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.