[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:14:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Anthony Liguori <address@hidden> wrote:
> On 06/11/2010 09:30 AM, Luiz Capitulino wrote:
>> On Thu, 10 Jun 2010 12:44:55 +0200
>> Juan Quintela<address@hidden> wrote:
>
> I think we've more or less agreed that MIGRATION_CONNECTED is really
> the event we want.
This had the problem of migrating to a file/whatever.
MIGRATION_CONECTED only makes sense when you have TCP or similar.
MIGRATION_STARTED it just means that migration has started,
independently of whatever method you have. For TCP it is possible that
we want another event each time that somebody connected to a port (not
only for migration), but that is something different.
>>> - 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?
>>
>
> Yes. Today, we should just generate a MIGRATION_DONE event and let a
> client poll for failure status.
I disagree completely. It just defeat the reason for this.
MIGRATION_ENDED on destination machine: go ahead, everything is ok.
MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path.
With MIGRATION_DONE + polling, we are delaying the "success" case just
to avoid having a new event. I don't buy 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.
>>
>
> MIGRATION_DONE gets deprecated for 0.14.
I still think that we want the 4 events that I described. My
understanding is that libvirt people also would love to have that 4
events.
Answer here is that: you can do this workaround and this other
workaround and you can get that information.
About semantics of messages, I don't see anytime soon that migration are
going to change from:
Start migration and then end with success or failure.
The only one that we could change/remove is MIGRATION_CANCEL to
MIGRATION_FAILURE(User canceled) it. But that is it.
Why have to do a polling when none is needed?
If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error)
to MIGRATION_ENDED(result code), and you have to check the error code, I
can also live with that. But that is it.
Later, Juan.
- Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, (continued)
- Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/09
- Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events, Yoshiaki Tamura, 2010/06/09
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Juan Quintela, 2010/06/10
- [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events, Luiz Capitulino, 2010/06/11
- 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 <=
- [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, 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