[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: |
Juan Quintela |
Subject: |
[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events |
Date: |
Sat, 12 Jun 2010 13:05:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Luiz Capitulino <address@hidden> wrote:
> On Thu, 10 Jun 2010 12:44:55 +0200
> Juan Quintela <address@hidden> wrote:
>
>> Luiz Capitulino <address@hidden> wrote:
>> > On Wed, 9 Jun 2010 14:10:53 +0200
>> > Juan Quintela <address@hidden> wrote:
>> >
>> >> This is a resent with what we agreed on yesterday call.
>> >> Migration events would be there for 0.13 until we get proper
>> >> async command support.
>> >
>> > Something which is not clear to me is the set of events we'd have if
>> > migrate
>> > was an async command.
>> >
>> > Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to
>> > get
>> > this information from the async response?
>> >
>>
>> I am not able to define simpler semantics for this events:
>
> Ok, I must be missing something here.
>
> First, let's talk about how async commands work today, better yet, how they
> should work in 0.14.
>
> I see two possible interfaces (off the top of my head):
>
> 1. QMP only returns the response when the command is finished, eg:
>
> C: { "execute": "migrate", "id": "foo" ... }
> /* nothing is returned, other commands are issued, after several hours...
> */
> S: { "return": ... "id": "foo" }
>
> 2. QMP returns a response right away just to signal that the command
> has been accepted:
>
> C: { "execute": "migrate", "id": "foo" ... }
> S: { "return": {}, "id": "foo" ... }
>
> However, the actual response is emitted as an event:
>
> S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" }
>
>
> That's what I have in mind, that's why I'm confused about what we're
> trying to accomplish here.
You continue forgeting the case that you have more than one monitor
conected. The other monitor will not receive _ethire_ of that
responses. Will not know what is happening.
>> - MIGRATION_STARTED: somebody started a migration, it is emited on
>> source and target, all monitors receive this event.
>
> The client has started the migration, it knows it. Why is the event needed?
The monitor that did it knows it, nobody else knows it. At destination
time, I guess you agree this is important, i.e. the management app knows
that migration has started.
I have been needinng this for audit, knowing when guest
start/stop/migrates. And just now the only way to get that information
is to "hack" qemu source code. With migration_events it will be
"trivial" to know when that happens.
In libvirt case. First thing that I would do if I receive a
MIGRATION_START command that I didn't started: I release control of that
VM, something fishy happened. At this point, it is imposible to know
what happens.
>> - MIGRATION_ENDED: migration ended with sucess, all needed data is in
>> target machine. Also emitted in all monitors on source and target.
>>
>> - MIGRATION_CANCELED: in one of the source monitors somebody typed:
>> migrate_cancel. It is only emmited on the source monitors, target
>> monitors will receive a MIGRATION_FAILED event.
>>
>> - MIGRATION_FAILED (with this error). At this point we don't have
>> neither the QMP infraestructure for sending (with this error) nor
>> migration infrastructure to put there anything different than -1.
>
> Aren't all the three events above duplicating the async response?
Again, no. Think that you have more than one monitor.
And indeed in the case of a single monitor. We are delaying the
information to the target management app.
MIGRATION_ENDED on target machine: We can do whatever is needed when
migration has ended. Async (or sync) answer to the source management
app, it needs to receive that information + send that information to
destination machine + receive information in destination machine + do
whatever is needed on destination vm.
Just because we refuse to give Information that we have, ready.
I am not asking for something that is difficult to do in qemu, it is
information that qemu knows (when migration has started/ended). And we
are telling management apps that they need to guess when things happens
and use polling to know it.
>> This event is emmited on all source and target monitors.
>> - For 0.13: Event don't have a QError.
>> - For 0.14: It will gain a QError.
>>
>> About migration becoming an async command. Really it is independent
>> of what events we emit. If migration becomes async command, only
>> difference is for the monitor that emitted the command, rest of
>> monitors see nothing. If we want to be able to see that informantion
>> in the other monitors, we need the events anyways.
>
> Somewhere else in this discussion someone has said that we should assume
> that the client talking to the source is the same one which is going to
> talk to the target, in this case all the communication is done through
> the source qemu instance.
That is another problem, that we don't have a monitor in the destination
target during migration.
Later, Juan.
- Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, (continued)
- Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Anthony Liguori, 2010/06/11
- Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/11
- [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, Luiz Capitulino, 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, 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, Luiz Capitulino, 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, Luiz Capitulino, 2010/06/14
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events,
Juan Quintela <=
- [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