Anthony Liguori <anth...@codemonkey.ws> wrote: > On 06/14/2010 02:54 PM, Juan Quintela wrote: >> Anthony Liguori<aligu...@linux.vnet.ibm.com> wrote:
>>> What makes migration important and not savevm? >>> >> That is the reason why I insist to have the events "both" in source and >> destination. About how to integrate savevm on the whole picture .... >> >> VM_SAVE_START/VM_SAVE_END/VM_RESTORE_START/VM_RESTORE_END events? >> > > If savevm is an asychronous command, then it's already there. > > You really want to support turning all command submissions/completions > into events. You could do it with two events. The first would be > COMMAND_REQUEST and would contain the request data and which monitor > it occurred on. The second would be COMMAND_RESPONSE and would > contain the response data and which monitor it occurred on. > > But honestly, I think it's a stretch to say this functionality is > really needed. As already told, what I need is the migration ones. The imporant case is MIGRATION_ENDED on target when migration were sucessful. This is the fast path, and it makes a difference here. MIGRATION_STARTED on target is also quite "nice" to have. At this point libvirt has an sleep(250ms): echo "cont" Due to a race here in incoming migration. As we only wanted one ending event, can agree on: MIGRATION_STARTED(both source and target) MIGRATION_DONE(result) (both source and target) where result can be ok or -1 (at this point we don't have anything else to put there). That moves us from 4 events to 2? Later, Juan.
