Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Prepare environment for migration¶

Before starting actual migration, assess the cloud’s eligibility and readiness. There are known differences between Open vSwitch (OVS) and Open Virtual Network (OVN) mechanism drivers that may cause functional gaps and user workload impact if not properly addressed beforehand.

MOSK provides the tooling to help assess the environment and determine whether it is safe to proceed. The assessment checks highlight potential risks and guide operators in remediating issues.

Key items to review before migration¶

This subsection outlines the key differences between the two networking backends, the potential risks they may introduce, and how they can be mitigated. This content is conceptual. Detailed, step-by-step instructions for adjusting your environment to miniize risks and ensure smooth migration are provided later in this migration guide, exactly where the operator will need them.

Tenant network MTU differences¶

Unlike OVS, the OVN mechanism driver uses Geneve as the tenant network encapsulation protocol. Geneve headers are larger than VXLAN headers, which may cause connectivity issues if the physical network MTU is too small to accommodate the encapsulated packet size (tenant network MTU plus Geneve overhead).

As part of the preparation activity, the operator needs to adjust the MTU for affected networks before migration.

Differences in handling security group rules¶

The OVS mechamism driver creates security group rules that allow unrestricted egress traffic. For example, this permits instances to access the DHCP server. If these rules are removed, Neutron automatically adds implicit rules to allow DHCP access.

The OVN mechanism driver does not create such implicit rules. If the environment relies on these rules, the operator must add them manually before migration.

DNS resolution differences¶

There are significant differences in how Neutron with OVS and Neutron with OVN propagates default DNS server addresses to instances when the subnet does not have the dns_nameservers option set:

OVS: DHCP agents (dnsmasq) forward DNS requests to the upstream servers specified in the spec:features:neutron:dns_servers key of the OpenStackDeployment custom resource. Instances are configured to use the DHCP agent IP addresses as DNS servers and forward requests to them.
OVN: OVN does not support forwarding DNS requests to upstream servers as per upstream known issue #1902950. In MOSK, OVN takes the DNS server IP addresses from the spec:features:neutron:dns_servers key in the OpenStackDeployment custom resource and provides them directly to instances through DHCP. OVN can then intercept DNS traffic sent to these addresses.

As a result, during migration, the DNS server address provided by the Neutron OVS mechanism driver stops working. It may take a long time for instances to obtain the new DNS server addresses because the lease renewal from Neutron DHCP to OVN DHCP occurs only through the broadcast request. If the lease duration is set to 24 hours, it can take up to 21 hours before the instance obtains the new DNS addresses, resulting in a long DNS unavailability.

To prevent this, the operator must explicitly configure DNS servers for each affected subnet before migration.

Preparation procedure¶

Caution

Mirantis strongly recommends performing the preparation and migration of your networking from OVS to OVN in a staging environment before executing the procedure in production.

Testing the full migration in a staging environment that closely mirrors the target environment configuration is essential to identify potential issues early and minimize operational risk.

Additionally, no automated rollback to OVS is available. The only option is to restore the Neutron database from a backup. Such a rollback may cause significant downtime for user workloads, and the network state may remain inconsistent even after restoration.

Deploy reference canary workloads on all compute nodes. Mirantis recommends booting one instance per compute node. Ensure that instances use the same operating system as typical user workloads in the target environment.

If Workload Availability monitoring is available in your environment, you can add instances with floating IP addresses by setting the following tag:
```
openstack --os-compute-api-version 2.26 server set \
          --tag openstack.lcm.mirantis.com:prober <INSTANCE-ID>
```
Run the pre-migration verification and resolve failed checks as described in Perform pre-migration verification.

Increase the DHCP lease duration by modifying the default value for the dhcp_lease_duration parameter in the OpenStackDeployment custom resource. During migration, the DHCP server might temporarily become unavailable. To prevent early DHCP lease expiration, Mirantis recommends increasing the value to 3 days:

spec:
  services:
    networking:
      neutron:
        values:
          conf:
            dhcp_agent:
              DEFAULT:
                dhcp_lease_duration: 259200

Normally, the default value of dhcp_lease_duration is 24 hours. Therefore, wait at least 24 hours and verify that the new dhcp_lease_duration value is applied. For example, on Ubuntu:

netplan ip leases <INTERFACE>

Example of system response:

ADDRESS=10.5.0.232
NETMASK=255.255.255.0
ROUTER=10.5.0.1
SERVER_ADDRESS=10.5.0.3
NEXT_SERVER=10.5.0.3
BROADCAST=10.5.0.255
MTU=1430
T1=56
T2=226796
LIFETIME=259200
DNS=10.172.1.100
DOMAINNAME=openstack.internal
HOSTNAME=test-vm130
ROUTES=169.254.169.254/32,10.5.0.3 0.0.0.0/0,10.5.0.1
CLIENTID=ffb55e67ff00020000ab1186dc66d3eb27cdcc

Create a database backup as close as possible to maintenance window to ensure the backup reflects the latest state of the environment:

kubectl -n osh-system exec -it deployment/rockoon -c osdpl -- bash

Initiate the database backup:

osctl-ovs-ovn-migrate backup_db

An example of backup utility log output:

osctl@rockoon-997c99cf6-6t7kf:/$ osctl-ovs-ovn-migrate backup_db
2025-08-06 10:44:53,615 [INFO] rockoon.cli.ovs_ovn_migration: Backing up database
2025-08-06 10:44:53,824 [WARNING] rockoon.cli.ovs_ovn_migration: Backup database in disabled state
2025-08-06 10:44:53,845 [INFO] rockoon.cli.ovs_ovn_migration: Backing up Neutron database
2025-08-06 10:44:56,837 [INFO] rockoon.kube: Waiting for 600 StatefulSet/mariadb-server is ready
2025-08-06 10:44:56,846 [INFO] rockoon.kube: The StatefulSet/mariadb-server is ready
2025-08-06 10:44:56,846 [INFO] rockoon.cli.ovs_ovn_migration: Desyncing mariadb on mariadb-server-2 from Galera cluster
2025-08-06 10:44:57,110 [INFO] rockoon.cli.ovs_ovn_migration: Waiting galera to become Desynced
2025-08-06 10:45:07,129 [INFO] rockoon.cli.ovs_ovn_migration: Waiting galera to become Desynced
2025-08-06 10:45:17,153 [INFO] rockoon.cli.ovs_ovn_migration: Waiting galera to become Desynced
2025-08-06 10:45:17,478 [INFO] rockoon.cli.ovs_ovn_migration: Galera cluster member is Desynced.
2025-08-06 10:45:17,479 [INFO] rockoon.cli.ovs_ovn_migration: Desynced mariadb on mariadb-server-2 from Galera cluster
2025-08-06 10:45:17,479 [INFO] rockoon.cli.ovs_ovn_migration: Starting Neutron database backup on mariadb-server-2
2025-08-06 10:45:18,577 [INFO] rockoon.cli.ovs_ovn_migration: Neutron database dump on mariadb-server-2 is completed
2025-08-06 10:45:18,578 [INFO] rockoon.cli.ovs_ovn_migration: Syncing mariadb on mariadb-server-2 back to Galera cluster
2025-08-06 10:45:18,917 [INFO] rockoon.kube: Waiting for 600 StatefulSet/mariadb-server is ready
2025-08-06 10:45:28,961 [INFO] rockoon.kube: The StatefulSet/mariadb-server is ready
2025-08-06 10:45:28,962 [INFO] rockoon.cli.ovs_ovn_migration: Synced mariadb on mariadb-server-2 back to Galera cluster

This command performs the following actions:

Triggers a full physical database backup using the mariadb-phy-backup cronjob (only if periodic database backups are enabled in OpenStackDeployment).
Executes a MySQL dump of the Neutron database on the highest-index mariadb-server replica. The resulting dump is stored in the pod’s MariaDB data directory, which is /var/lib/mysql/.

Verify that the MySQL dump is present in the MariaDB pod:

kubectl -n openstack exec -t mariadb-server-2 -- bash -c \
  'find /var/lib/mysql/ -name neutron-ovs* -exec basename {} \; | sort -rn'

An example of positive system response:

neutron-ovs-ovn-migration-20250806104517.sql

After completing these steps, proceed with the migration as described in Perform migration.