On Tue, 15 Jun 2010 17:24:59 +0200 Juan Quintela <quint...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> wrote: > > On Tue, 15 Jun 2010 12:30:57 +0200 > > Juan Quintela <quint...@redhat.com> wrote: > > > >> 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. > > > > I think we could avoid this one too, but as it has a clear feature for > > 0.13, I'm not too opposed either. > > > >> 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. > > > > Hm. Did you investigate that race in detail? I hope we're not using events > > to hide bugs. > > Yes. we can call "cont" while staying in "waiting for incomming > migration" because we dont' have "waiting incoming migraiton" than > vm_start/stop understand. > > Reviewing all callers to see that I can add a new state. Will skip this one because it seems to be being discussed in a different thread. > >> 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? > > > > I still don't see the need for MIGRATION_STARTED, it could be useful in > > the target but I'd like to understand the use case in more detail. > > At this point, if you are doing migration with tcp, and you are putting > the wrong port on source (no path or any other error), you get no info > at all of what is happening. Shouldn't the migrate command just the return the expected error? > It is important to be sure than migration has started, i.e. something > happenend. It happens to me all the time, and users with more complex > setup will like it to know what is happening. It already happened to me too, but I feel that the event is being used as a workaround: we should return good error information instead, like this: (qemu) migrate tcp:foobar:444 migrate: Can't locate host 'foobar' (qemu) migrate tcp:doriath:1 migrate: Host 'doriath' is not listening for migration in port 1 (qemu) migrate 'exec:asd' migrate: Can't execute 'asd' In QMP the client does get an event, it's the completion response of the async command, with the error information. > As a workaround, we can try something like "info status" or ony read > only version to know that migration is not happening (because) monitor > is working (as I tell an workaround). > > Later, Juan. >
