Bug 1974427

Summary: Expand on the VXLAN usage in OVN related to the OVS to OVN migration
Product: Red Hat OpenStack Reporter: Jakub Libosvar <jlibosva>
Component: documentationAssignee: James Smith <jamsmith>
Status: CLOSED NOTABUG QA Contact: Roman Safronov <rsafrono>
Severity: unspecified Docs Contact:
Priority: high    
Version: 16.1 (Train)CC: ddf-bot, ekuris, gregraka, jamsmith, mariel, rsafrono, ykarel
Target Milestone: z4Keywords: Triaged
Target Release: ---Flags: jamsmith: needinfo? (jlibosva)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-06 05:34:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2087498    
Bug Blocks:    

Description Jakub Libosvar 2021-06-21 16:28:06 UTC 
This BZ is to document cons and pros around network type (Geneve vs. VXLAN) during the migration to ML2/OVN.

There are challenges in MTU configurations when switching from VXLAN network to Geneve network for several reasons.

1) The guest OS of running VMs has the MTU already configured and the VM will need to wait for the next DHCP offer in order to change it. By default, the address leases are 24 hours and it requires extra step prior to performing the migration.

2) Some operating systems store the MTU configuration into network scripts and such systems will need a manual intervention to change the MTU because new DHCP Offers will not override the static network scripts.

3) The MTU configuration is part of domxml of running instances in libvirt. This can't be easily changed while VM is running and it can lead to other issues, like live migrating the vm (see bug 1943613 for more info).

Since OVN now supports VXLAN as the tunnelling technology (bug 1881704), the operator can chose to not migrate to Geneve and remain on the VXLAN even after migrating to OVN. This brings limitation that must be considered prior to the migration. The limitation is that OVN is capable of running only 4k tenant networks and 4k ports.

It's also worth to note that even if the tunnelling backend is not changed and operator chooses to stay on VXLAN, there will be a data plane disruption between instances on the same network running on different hypervisors because ml2/ovs compute nodes can't create a VXLAN tunnel to other compute node that is already running on OVN.
Comment 1 Jakub Libosvar 2021-06-21 16:34:40 UTC 
(In reply to Jakub Libosvar from comment #0)
> Since OVN now supports VXLAN as the tunnelling technology (bug 1881704), the
> operator can chose to not migrate to Geneve and remain on the VXLAN even
> after migrating to OVN. This brings limitation that must be considered prior
> to the migration. The limitation is that OVN is capable of running only 4k
> tenant networks and 4k ports.

Amending that the limitation is 4k network globally but each network can have up to 4k ports.
Comment 3 Jakub Libosvar 2023-02-13 15:46:51 UTC 
(In reply to Jakub Libosvar from comment #1)
> (In reply to Jakub Libosvar from comment #0)
> > Since OVN now supports VXLAN as the tunnelling technology (bug 1881704), the
> > operator can chose to not migrate to Geneve and remain on the VXLAN even
> > after migrating to OVN. This brings limitation that must be considered prior
> > to the migration. The limitation is that OVN is capable of running only 4k
> > tenant networks and 4k ports.
> 
> Amending that the limitation is 4k network globally but each network can
> have up to 4k ports.

Correction: the limitation is 4k network globally but each network can have up to 2k ports.
Comment 6 James Smith 2023-04-10 14:41:01 UTC 
*** Bug 2073247 has been marked as a duplicate of this bug. ***