Solution to this problem is a little bit different since live migration monitor has been merged. Instead of periodic task I think of monitor improvement.
When user trigger delete of a VM that is being live migrated, live migration monitor will think that LM was eventually completed and it will call "post_method" on destination host (because VM disappeared from source host). Depending on scenario during post_method VM will be in DELETING state or it will not exist. This will cause exceptions on destination host and will leave things in a messy state - rollback will not be called.
So I think that this check in live_migration_monitor:
if ex.get_error_code() == libvirt.VIR_ERR_NO_DOMAIN: LOG.debug("VM is missing, migration finished", instance=instance) info.type = libvirt.VIR_DOMAIN_JOB_COMPLETED
should also check whether VM still exists in Nova. If not - it should set info.type to one of two: libvirt.VIR_DOMAIN_JOB_FAILED or libvirt.VIR_DOMAIN_JOB_CANCELLED so that rollback will be called on destination host.
Solution to this problem is a little bit different since live migration monitor has been merged. Instead of periodic task I think of monitor improvement.
When user trigger delete of a VM that is being live migrated, live migration monitor will think that LM was eventually completed and it will call "post_method" on destination host (because VM disappeared from source host). Depending on scenario during post_method VM will be in DELETING state or it will not exist. This will cause exceptions on destination host and will leave things in a messy state - rollback will not be called.
So I think that this check in live_migration_ monitor:
if ex.get_error_code() == libvirt. VIR_ERR_ NO_DOMAIN:
LOG.debug( "VM is missing, migration finished",
instance= instance)
info.type = libvirt. VIR_DOMAIN_ JOB_COMPLETED
should also check whether VM still exists in Nova. If not - it should set info.type to one of two: libvirt. VIR_DOMAIN_ JOB_FAILED or libvirt. VIR_DOMAIN_ JOB_CANCELLED so that rollback will be called on destination host.
After this fix I believe that such situation will be a corner case and will happen only if nova-compute will be restarted during LM, but this should be fixed by blueprint manager- restart- during- migration /blueprints. launchpad. net/nova/ +spec/manager- restart- during- migration
https:/