Re: [Qemu-devel] [PATCH 3/3] migration: Add migration events on target side

[Juan Quintela]

Eric Blake <address@hidden> wrote:
> On 05/20/2015 09:35 AM, Juan Quintela wrote:
>> We reuse the migration events from the source side, sending them on the
>> appropiate place.
>
> s/appropiate/appropriate/
>
>> 
>> Signed-off-by: Juan Quintela <address@hidden>
>> ---
>>  migration/migration.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>
>> @@ -116,14 +117,17 @@ static void process_incoming_migration_co(void *opaque)
>>      Error *local_err = NULL;
>>      int ret;
>> 
>> +    qapi_event_send_migration(MIGRATION_STATUS_ACTIVE, &error_abort);
>>      ret = qemu_loadvm_state(f);
>>      qemu_fclose(f);
>>      free_xbzrle_decoded_buf();
>>      if (ret < 0) {
>> +        qapi_event_send_migration(MIGRATION_STATUS_FAILED, &error_abort);
>>          error_report("load of migration failed: %s", strerror(-ret));
>>          migrate_decompress_threads_join();
>>          exit(EXIT_FAILURE);
>
> Does qapi_event_send_* send an event right away, or merely just queue
> things up to be sent at a safe point later in the overall event loop?
> Or put another way, could the early exit() here prevent the actual error
> from being delivered, because we don't return control to the event loop
> to actually flush the pending event queue?

Too depth for me.


>
> But whether or not we have a design issue on the failure path, at least
> something got printed via error_report, and the real benefit of this
> patch is the event on success; so I'm fine with giving this patch:
>
> Reviewed-by: Eric Blake <address@hidden>

Thanks

Once that we are here

@@ -89,6 +89,7 @@ void qemu_start_incoming_migration(const char *uri, Error 
**errp)
 {
     const char *p;

+    qapi_event_send_migration(MIGRATION_STATUS_SETUP, &error_abort);
     if (!strcmp(uri, "defer")) {
         deferred_incoming_migration(errp);
     } else if (strstart(uri, "tcp:", &p)) {


I am not able to see this event at all.  Not that it should matter for
destination.  My guess is that it happens too early for qapi, qmp or
whatever handles events is ready to consume them.  Any good idea?

Notice that in the big scheme of things, on destination, this event
should be very important/useful anyways.

Thanks again, Juan.