Would you be so kind to help me/tell me or point me how to find which Hooks, and in which order, are triggered when VM is being migrated?

What I am aiming for is following: We have a nauseate hook which deletes dns records from DNS server, for of a VM “destroyed”. That is just as we wanted it, except in a case of Migration, which is also a “destructive” action, looking from perspective of a Hypervisor. I was testing an order of Hooks triggered when I issue VM Migrate, in order to discover which Hook I can use to trigger update of the records for a VM that is Migrated. Seems that “after_vm_destroy” is the last in order hook to be executed when VM is migrated, and I wanted to verify that.

How come that there is no hook which enables VM start or continue on a destination hypervisor, after VM is migrated? Or am I missing something?

On 27 Aug 2019, at 11:39, Milan Zamazal <mzamazal(a)redhat.com&gt; wrote: Milan Zamazal <mzamazal(a)redhat.com&gt; writes: > "Vrgotic, Marko" <M.Vrgotic(a)activevideo.com&gt; writes: > >> What I am aiming for is following: >> We have a nauseate hook which deletes dns records from DNS server, for of a VM “destroyed”. >> That is just as we wanted it, except in a case of Migration, which is >> also a “destructive” action, looking from perspective of a Hypervisor. >> I was testing an order of Hooks triggered when I issue VM Migrate, in >> order to discover which Hook I can use to trigger update of the >> records for a VM that is Migrated. >> >> Seems that “after_vm_destroy” is the last in order hook to be executed >> when VM is migrated, and I wanted to verify that. > > Hi Marko, I see, I understand now what's your problem. after_vm_destroy > is called on the source while after_vm_migrate_destination on the > destination and I don't think there is any guarantee in which order they > are mutually called. > >> How come that there is no hook which enables VM start or continue on a >> destination hypervisor, after VM is migrated? Or am I missing >> something? > > after_vm_migrate_destination is called on the destination, but see > above. A possible solution could be to look in the domain XML passed to > after_vm_destroy, there should be an exit reason in the metadata > section. If the reason is migration, then you can skip your delete > action. Hm, it seems there is no exit info after migration. Another idea is to put something into after_vm_migrate_source hook that would prevent the record deletion.