VMs with vif_type bridge/tap started before Rocky upgrade cannot be live migrated
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
Mohammed Naser | ||
Rocky |
Fix Committed
|
High
|
Mohammed Naser |
Bug Description
In Rocky, the following patch introduced adding MTU to the network for VMs:
https:/
However, this didn't affect live migrations much because Nova didn't touch the network bits of the XML during live migration, until this patch:
https:/
With that change, the MTU is added to the configuration, which means that the destination is launched with host_mtu=N, which apparently changes the guest ABI (see: https:/
2018-10-29 14:59:15.126+0000: 5289: error : qemuProcessRepo
2018-10-
2018-10-
2018-10-
2018-10-
I was able to further verify this by seeing that `host_mtu` exists in the command line when looking at the destination host instance logs in /var/log/
Changed in nova: | |
assignee: | nobody → Mohammed Naser (mnaser) |
tags: | added: libvirt live-migration upgrade |
Changed in nova: | |
importance: | Undecided → High |
status: | New → Triaged |
summary: |
- VMs started before Rocky upgrade cannot be live migrated + VMs with vif_type bridge/tap started before Rocky upgrade cannot be live + migrated |
FWIW I don't think https:/ /github. com/openstack/ nova/commit/ 2b52cde565d542c 03f004b48ee9c1a 6a25f5b7cd really changed how https:/ /github. com/openstack/ nova/commit/ f02b3800051234e cc14f3117d5987b 1a8ef75877 could have broken anything. _update_vif_xml is called from the source host using migrate data from the dest host, but as far as I know that migrate data doesn't have any information about mtu from the dest to determine what to set in the source vif config. Before _update_vif_xml, we would have just sent the source guest xml vif config to the dest and if the dest didn't support mtu it would have failed also.