[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events
From: |
Luiz Capitulino |
Subject: |
[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events |
Date: |
Wed, 16 Jun 2010 15:01:55 -0300 |
On Tue, 15 Jun 2010 17:24:59 +0200
Juan Quintela <address@hidden> wrote:
> Luiz Capitulino <address@hidden> wrote:
> > On Tue, 15 Jun 2010 12:30:57 +0200
> > Juan Quintela <address@hidden> wrote:
> >
> >> Anthony Liguori <address@hidden> wrote:
> >> > On 06/14/2010 02:54 PM, Juan Quintela wrote:
> >> >> Anthony Liguori<address@hidden> 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.
>
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, (continued)
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/14
- Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/15
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/15
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/15
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events,
Luiz Capitulino <=
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/16
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/17
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/17
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/17
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/17