Jiri Denemark <jdene...@redhat.com> wrote:
> On Wed, May 20, 2015 at 17:35:23 +0200, Juan Quintela wrote:
>> We have one argument that tells us what event has happened.
>>
>> Signed-off-by: Juan Quintela <quint...@redhat.com>
>> ---
>> docs/qmp/qmp-events.txt | 16 ++++++++++++++++
>> migration/migration.c | 12 ++++++++++++
>> qapi/event.json | 14 ++++++++++++++
>> 3 files changed, 42 insertions(+)
>
> Hi Juan,
>
> I patched libvirt to be able to consume this event and it all seems to
> work fine except for events sent after migrate_cancel command:
>
> {"execute":"migrate_cancel","id":"libvirt-33"}
> {"timestamp": {"seconds": 1432899178, "microseconds": 844907}, "event":
> "MIGRATION", "data": {"status": "cancelling"}}
> {"return": {}, "id": "libvirt-33"}
> {"timestamp": {"seconds": 1432899178, "microseconds": 845625}, "event":
> "MIGRATION", "data": {"status": "failed"}}
> {"timestamp": {"seconds": 1432899178, "microseconds": 846432}, "event":
> "MIGRATION", "data": {"status": "cancelled"}}
>
> In other words, the status first changes to "failed" and then it changes
> correctly "cancelled". Can you fix this weird behavior in QEMU or do we
> have to work around it in libvirt?
>
> Jirka
Found root cause of this, basically we had the code:
migrate_set_state(FOO, MIGRATION_STATUS_FAILED);
qapi_send_event(...., MIGRATION_STATUS_FAILED);
But the first call only change the state if the current state is FOO.
So, changed the event to inside migrate_set_state() and only sent it
when we change the state.
See new patch series, basically we were using incorrectly
atomic_cmpxchg() and that made things ... interesting.
Later, Juan.
