[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: |
Tue, 15 Jun 2010 10:40:47 -0300 |
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.
> 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.
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, (continued)
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/12
- [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 <=
- [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/16
- [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