Nova currently processes the interaction with neutron and cinder serially during post-live migration

The current sequence is to clean up the source host voumes then remove the attachments in cidner .

after that, the destination port binding are activated later the source ports are cleaned up and sriov ports on the destination are reattached to the VM.

This sequence is sub-optimal.

ideally, the post_live_migration function would be refactored.

the simplest apprcoh while keeping the code linear would be to move
the activation fo the destination port binding to the start fo the function.
next the attachment of the sriov ports could be moved after the port bindings to have all operations on the destioant for networking done before we start cleaning up the host
follow that the cinder and neutron source host cleanup could be done and finally the db state updated.

This is more complex then it seams as the destination host calls involve an RPC form the source host to the destination where as the source cleanup happens locally.

the code is also highly dependent on the current sequence in term of deping on the current values of instance.host so the update of the instance in the db need to remain at the end of the function to avoid significant rpc changes.

a more advanced optimisation could be to separate each phase (destination networking, source storage and source networking) into separate functions that are run in parallel using eventlet.spawn()
we could then wait on the completion of each greentrhead and proceed with the db update when this was completed. this complicates error handling to some degree and the complexity of the code in general but it would prevent one slow operation from blocking the other e.g. a slow cinder backend could not block the progress of the networking setup or cleanup.

This is an non-trivial enhancement that would need careful testing and is unlikely to be backportable. the simple approach and advanced apprch could both be implemented with the trivial reodring potentially being backportable before the paralisation which is unlikely to be safe to backport. as such this should likely be a small spec or specless blueprint upstream. The current linar approach is working as desgisned so this is not a regression or a bug so this should be considered a feature.