Choosing Between OVN and OVS Before Your Private Cloud Deploys

You can resize, reconfigure, and expand a private cloud long after it’s deployed. The networking backend is different. In Private Cloud Core v4, OVN is the default Neutron backend, replacing OVS. OVS is still available, but the choice is made before the cloud’s first deployment run, and there’s no supported way to convert a cloud from OVN to OVS afterward. The only path is a rebuild. So it’s worth spending an hour on this decision before you deploy, not after.

Here’s how this usually comes up. A team plans its private cloud around the services it runs today. Somewhere in that stack is a load balancer doing more than spreading traffic: terminating TLS, routing by hostname, pinning sessions with cookies. On a v4 cloud running OVN, the built-in OpenStack load balancer can’t do those things. If nobody checks before deployment, the team finds out when the first load balancer goes live.

None of this makes OVN the wrong default. For many workloads it’s the better option. The point is that the decision is permanent for the life of the cloud, so make it deliberately.

What OVN and OVS Mean in OpenStack

Neutron is OpenStack’s networking service. It needs a backend to actually build the virtual networks, routers, and security rules you define.

• ML2/OVS uses Open vSwitch with a set of Neutron agents for Layer 3 routing, DHCP, and other functions. It’s the long-standing approach and the default in earlier Private Cloud Core versions.
• ML2/OVN uses Open Virtual Network, a control plane built on top of Open vSwitch. OVN translates your networks, routers, and security groups into logical flows that are programmed across the hypervisors.

On a v4 cloud, the backend is set by a single deployment setting that accepts either ovn or openvswitch. The two are mutually exclusive, and the value has to be in place before the first main Kolla-Ansible configuration run that builds the cloud.

Why the Choice Matters Most for Load Balancing

The biggest practical difference shows up in Octavia, OpenStack’s load balancing service. Octavia uses a provider driver to build load balancers, and in v4 the provider follows the networking backend:

• An OVN cloud gets the OVN provider.
• An OVS cloud gets the Amphora provider.

Because the provider follows the backend, it’s fixed for the life of the cloud too.

How the OVN Provider Works

The OVN provider doesn’t boot anything. It programs each load balancer as logical flows inside OVN, distributed across the hypervisors. That gives it some real advantages:

• It consumes no tenant quota, since there’s no load balancer VM.
• It comes up in seconds.
• It’s highly available by default, with nothing to fail over or maintain.

The tradeoff is that it’s a plain Layer 4 packet balancer. On a v4 OVN cloud, that means:

• TCP and UDP pass-through only
• SOURCE_IP_PORT as the only balancing algorithm
• No TLS termination
• No Layer 7 routing by hostname or path
• No HTTP health checks
• No session persistence

How the Amphora Provider Works

Amphora boots a dedicated HAProxy instance for each load balancer, or two when you use an active-standby topology. Octavia drives those instances through its health manager. This is the full-featured option, and it comes with costs:

• Each load balancer consumes tenant quota for its instances.
• Provisioning takes minutes rather than seconds.
• If an amphora fails, there’s a brief outage while the health manager rebuilds it.
• There’s an amphora image and certificate lifecycle that has to be maintained.

Check the Feature Matrix for Your Exact Needs

Summaries drift. The authoritative reference is the upstream Octavia provider feature matrix, which compares Amphora and OVN field by field across load balancers, listeners, pools, members, health monitors, and Layer 7 policies and rules. The OVN Octavia provider documentation explains how the driver works and its known caveats. If your team depends on a specific load balancer feature, look it up there before deployment.

Other Differences Worth Knowing About

Load balancing isn’t the only area where OVN and ML2/OVS behave differently. The Neutron project maintains a list of known gaps between ML2/OVS and OVN for the 2026.1 release. A few items on it are worth checking against your workloads:

• DHCP and security groups. ML2/OVS automatically allows DHCP traffic from instances to its DHCP agent. With OVN, that traffic has to be explicitly allowed by the security group rules attached to the instance.
• Internal DNS. OVN answers DNS queries for project networks only over UDP, and only for queries without extra options set (EDNS). Other queries are forwarded to the configured resolvers.
• IPv6 NDP proxy. Not supported by OVN.
• East-west fragmentation. OVN doesn’t support fragmentation of east-west traffic through an OVN router between two private networks.
• Metering. The Neutron metering agent works only with the Neutron L3 agent, not with OVN.
• Port forwarding. Port forwardings are always centralized in ML2/OVN rather than distributed.

Most workloads never touch these. But if your network design depends on one of them, it belongs in the decision.

How to Decide

Start with your load balancing requirements, since that’s where the difference is sharpest.

Choose OVN (the Default) If You:

• Need load balancers that spread TCP or UDP traffic across a pool of backends
• Terminate TLS somewhere other than the OpenStack load balancer, such as in a Kubernetes ingress controller or your own proxy tier
• Want load balancers that come up in seconds and don’t use tenant quota
• Don’t depend on any of the known ML2/OVS gaps listed above

Choose OVS If You:

• Terminate TLS at the OpenStack load balancer
• Route traffic by hostname or URL path at the load balancer
• Rely on cookie-based session persistence
• Need HTTP health checks run by the load balancer
• Depend on a Neutron feature that’s on the OVN gaps list

There’s a Middle Path

If your Layer 7 needs are limited to a few services, you don’t have to choose OVS for the whole cloud. On an OVN cloud, you can run your own HAProxy or NGINX instances as ordinary VMs behind an OVN load balancer, or handle TLS and routing in a Kubernetes ingress controller. You manage that layer yourself, but you keep the OVN defaults everywhere else. Weigh the extra operational work against the reasons for choosing OVN.

Questions to Answer Before Deployment

Before you confirm the backend with us, work through these with whoever owns your applications and network design. The answers usually make the choice obvious.

1. List every load balancer you run today. Include hardware appliances, cloud load balancers, and software proxies. For each one, note what it actually does.
2. Mark which ones terminate TLS. If TLS ends at the load balancer, decide whether it could move to an ingress controller, a proxy tier, or the application itself.
3. Mark which ones route by hostname or path. Layer 7 routing needs Amphora, or your own proxy layer on an OVN cloud.
4. Check for session persistence. If an application breaks when a user’s requests land on different backends, note how it pins sessions today.
5. Check health checks. If you rely on HTTP-level health checks at the load balancer, that’s an Amphora feature.
6. Review the OVN gaps list. Confirm none of your network designs depend on NDP proxy, Neutron metering, or the other items above.
7. Count your load balancers. If you’ll run many of them, Amphora’s per-load-balancer instances and quota use add up. OVN’s don’t.

If every load balancer passes Layer 4 traffic and nothing on the gaps list applies, OVN is the straightforward choice. If several need Layer 7 features and you don’t want to run your own proxy tier, choose OVS.

Scenarios That Make the Choice Clearer

A SaaS Platform on Kubernetes

A SaaS team runs its product on Kubernetes clusters inside the private cloud. TLS terminates at the ingress controller, and the OpenStack load balancer only needs to forward TCP traffic to the ingress nodes. OVN handles that well, and its load balancers come up quickly as services change. Our Kubernetes workloads page covers running Kubernetes on OpenMetal infrastructure.

A VMware Migration With Application Load Balancers

A team leaving VMware has dozens of applications that depend on load balancer features: TLS offload, host-based routing, and sticky sessions. They want to keep that behavior without rebuilding it in each application. That points to OVS and the Amphora provider. If you’re planning a migration like this, our VMware migration page covers the broader path.

An Internal Platform With Mixed Needs

A platform team runs mostly internal services that need simple TCP balancing, plus two customer-facing apps that terminate TLS. They choose OVN for the cloud and run a small HAProxy pair as VMs for the two apps. They keep fast, quota-free load balancers for most services, and own the proxy layer for the two that need more.

How to Request OVS on OpenMetal

OVN is the default for new Private Cloud Core v4 deployments. If you need OVS and the Amphora provider, tell our team before your cloud is deployed, so the setting is in place before the first deployment run. Bring your load balancer requirements to that conversation. If you’re unsure, we’ll walk through them with you.

Once a cloud is deployed on OVN, changing to OVS means building a new cloud and moving workloads to it. That’s why we’d rather have this conversation early.

Who This Is For

OVN is likely the right fit if you:

• Run Kubernetes and terminate TLS inside the cluster
• Mainly need Layer 4 load balancing
• Want load balancers that don’t consume tenant quota
• Prefer distributed, built-in high availability with nothing extra to maintain

OVS is likely the right fit if you:

• Need TLS termination, Layer 7 routing, or session persistence at the OpenStack load balancer
• Are migrating applications that depend on those features today
• Rely on a Neutron capability listed among the known OVN gaps

The Short Version

OVN gives you fast, distributed, quota-free load balancing for Layer 4 traffic. OVS gives you full-featured load balancers at the cost of speed, quota, and maintenance. Pick based on what your load balancers actually do, and pick before you deploy, because you only get to choose once.

If you’re planning a Private Cloud Core v4 and want to talk through the networking choice, contact our team before deployment. You can also size your cloud with the private cloud pricing calculator or apply for a proof of concept to test your load balancing setup on real hardware.

Frequently Asked Questions

What is the default networking backend in Private Cloud Core v4?

OVN is the default Neutron backend for new Private Cloud Core v4 deployments, replacing OVS as the default. OVS remains available as a deployment option.

Can I switch a private cloud from OVN to OVS after deployment?

No. The networking backend is set before the cloud’s first deployment run, and there’s no supported conversion from OVN to OVS. Moving to OVS requires deploying a new cloud.

What load balancer features are missing with the OVN provider?

On a v4 OVN cloud, the OVN provider supports Layer 4 TCP and UDP pass-through with SOURCE_IP_PORT as the only algorithm. It doesn’t support TLS termination, Layer 7 routing, HTTP health checks, or session persistence. The upstream Octavia provider feature matrix has the full comparison.

What is the Amphora provider?

Amphora is Octavia’s full-featured load balancer provider. It boots an HAProxy instance for each load balancer, or two in an active-standby topology. It supports TLS termination and Layer 7 features, but uses tenant quota and takes minutes to provision. On a v4 cloud, it’s available only when the cloud is deployed with OVS.

Can I terminate TLS on an OVN cloud?

Yes, just not at the OpenStack load balancer. You can terminate TLS in a Kubernetes ingress controller, in your own proxy VMs running HAProxy or NGINX, or in your applications, and use an OVN load balancer to forward TCP traffic to them.

How do I get an OVS cloud from OpenMetal?

Tell our team before your Private Cloud Core v4 is deployed. The backend has to be set before the first deployment run.