Hi,
We are upgrading from Jammy to Noble, and need to include the patch https://review.opendev.org/c/openstack/nova/+/967570?tab=comments so VMs could be created on Noble nodes.
However, all of our existing VMs that were created without the patch could not be live migrated to Noble, and has latency in live migrating to Jammy WITH the patch. right so what your encountering is the fact that the behavior in libvirt change between jammy and noble in the jammy version the defautl behavior fo the ethernet interface type was to not recreate the tap if it exists on noble the defualt behvior is to recreated it nova didnt specify the manage flag in older release so vm migration was broken for calico on upgrade due to the cahnge in libvirt behvior
To be clear: Old VMs created on Jammy -> patch applied on Jammy and Noble -> VMs can be live migrated to Jammy now, but with latency (VMs are pingable almost 10 seconds after live migration completed); VMs can not be live migrated directly to Noble nodes. After live migrated to Jammy with latency, we could live migrate the VMs between Jammy nodes, and one-way to Noble nodes, without any latency. so nova/libvirt/qemu does not supprot movign a vm form an newer qemu/libvirt to an older one.
On 03/02/2026 18:12, Chang Xue wrote: that why you can only move one way form jamy to noble in nova. even though the live migration can sometimes succeeded at the qemu level they do not officially support going form the newer qemu to the older qemu so we block that by default in nova.
Would like to understand it more, is there any way to get rid of the latency issue? I tried to patch nova/virt/libvirt/migration.py to add managed='no' flag when migration is on fly, but it only allows me to live migrate the old VMs directly to Noble nodes, latency still exists.
the lattency is a result of calico. calico does not support wiring up the the destination for networking until after the port binding is activated which alwasy happens after the vm is running when it is activated there is a down time while the bgp route updates propagate i belive this is currently being worked on in the calico plugin. the api contract that is expected of a newutron backend is that when we do port plug in pre-live migrate the netowrk backend should only send the network-vif-plugged event when teh destination port is ready to send and resive packets. ml2/ovs and ml2/ovn to a lesser degree implement this effectively for ml2/ovn it has special handling to intercept the RARP packet that qemu sened before the guest is unpaused on the destination and activate the openflow rules early before the port bidning is activated on the destination. note it was ment to have installed those flows before the migration started so this is late but eilar then calico. both calico and ovn currently send there network-vif-plugged event before the network is plug due to limitation in how the sdn controller works today. for calico i don't know if its possible in bgp to advertise a secondary route or similr for the ip on the destination host and make it the primary route faster or if bgp propagation dely will alwasy be a bottelneck but calico could implement the same handeling of the RARP packet to trigger the switch over that ovn does. this is more of a neutron/calico question then a nova one.
Thanks, Chang