)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":37800,"name":"Sebastian Krott","display_name":"Sebastian Krott","email":"sebastian.krott@sap.com","username":"sebkro_sap"},"change_message_id":"8e22645d7263c35e34ec80b9ef783b3c52171fff","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a5aa40e0_c06550cb","updated":"2026-09-25 11:18:19.000000000","message":"Check https://review.opendev.org/c/openstack/nova/+/1007318 for an alternative fix that implements additional rollback for the libvirt driver.","commit_id":"c7641ffbecd3a0b4a923bf03ff616b48076adfff"},{"author":{"_account_id":26286,"name":"huanhongda","email":"hongda.xun@easystack.cn","username":"huanhongda"},"change_message_id":"bc2d6467cb8d8afa29d28b03d9e513c47466f209","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b9e9e0ce_ebf2b0be","updated":"2025-02-09 03:48:12.000000000","message":"recheck","commit_id":"c7641ffbecd3a0b4a923bf03ff616b48076adfff"}],"nova/compute/manager.py":[{"author":{"_account_id":37800,"name":"Sebastian Krott","display_name":"Sebastian Krott","email":"sebastian.krott@sap.com","username":"sebkro_sap"},"change_message_id":"8e22645d7263c35e34ec80b9ef783b3c52171fff","unresolved":true,"context_lines":[{"line_number":9541,"context_line":"                # instance.host is not current compute node mean the exception"},{"line_number":9542,"context_line":"                # is raised from _post_live_migration_update_host."},{"line_number":9543,"context_line":"                # We can never rollback from post live migration."},{"line_number":9544,"context_line":"                if instance.host \u003d\u003d CONF.host:"},{"line_number":9545,"context_line":"                    self._rollback_live_migration(context, instance, dest,"},{"line_number":9546,"context_line":"                                                  migrate_data,"},{"line_number":9547,"context_line":"                                                  source_bdms\u003dsource_bdms)"}],"source_content_type":"text/x-python","patch_set":3,"id":"73b97467_20e31db6","line":9544,"updated":"2026-09-25 11:18:19.000000000","message":"Aren\u0027t there two issues with this approach?\n\n1) `rollback_live_migration` assumes that the instance is still running on the source host and not on the destination host. But this guard does not work if the driver\u0027s `live_migration` raises after the instance migrated to the destination and before calling `_post_live_migration_update_host `.\n\nMore concretely, for libvirt, what if `_live_migration_monitor` raises an unexpected exception or on\n```\n                if libvirt_migrate.should_trigger_timeout_action(\n                        instance, elapsed, completion_timeout,\n                        migration.status):\n                    timeout_act \u003d CONF.libvirt.live_migration_timeout_action\n                    if timeout_act \u003d\u003d \u0027force_complete\u0027:\n                        self.live_migration_force_complete(instance)\n                    else:\n                        # timeout action is \u0027abort\u0027\n                        try:\n                            guest.abort_job()\n                        except libvirt.libvirtError as e:\n                            LOG.warning(\"Failed to abort migration %s\",\n                                    e,\n                                    instance\u003dinstance)\n                            self._clear_empty_migration(instance)\n                            raise\n```\nThe state of the migration is then unknown. So the instance may already be on the destination host with `instance.host` still set to source. I suppose there are similar scenarios for other drivers as well.\n\n2) Note that `_rollback_live_migration` is passed via the `recover_method` parameter to the driver\u0027s `live_migration`. It seems to me that this is very intended due to the issues mentioned. I.e., in case of an exception during `live_migration`, there is no way for `_do_live_migration` to know whether rollback should be called or not. Therefore the responsibility for triggering rollback is handed off to the driver.\n\nThis also means that the driver may already have called `_rollback_live_migration` before `_do_live_migration` catches the exception. This appears to be the case e.g. when `nova.virt.vmwareapi.vmops.VMwareVMOps.live_migration` raises during\n```\n        try:\n            vm_util.relocate_vm(self._session, vm_ref, res_pool_ref,\n                                ds.ref, esx_host, devices\u003ddevices)\n            LOG.info(\"Migrated instance to host %s\", dest, instance\u003dinstance)\n        except Exception:\n            with excutils.save_and_reraise_exception():\n                recover_method(context, instance, dest, migrate_data)\n```\nAgain, similar scenarios might exist for other drivers.","commit_id":"c7641ffbecd3a0b4a923bf03ff616b48076adfff"}]}