[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
From: |
Juan Quintela |
Subject: |
[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events |
Date: |
Tue, 25 May 2010 17:35:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Anthony Liguori <address@hidden> wrote:
> On 05/25/2010 09:21 AM, Juan Quintela wrote:
>> +MIGRATION_CANCELED
>> +------------------
>> +
>> +Emitted when migration is canceled. This is emitted in the source.
>> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
>> +and CANCELED migration for target).
>>
>
> But the management tool is the one that cancels so surely, it knows
> why already.
ok, then that one is ok.
>
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_CANCELED",
>> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_ENDED
>> +---------------
>> +
>> +Emitted when migration ends (both in source and target)
>>
>
> A start event is going to be generated already, no?
problem here is that libvirt start target with -S, and waits to do the
"cont" as soon as possible. As of know, only way to do it is to poll
info migrate on source faster.
>> +Data: None
>> +
>> +Example:
>> +
>> +{ "event": "MIGRATION_ENDED",
>> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_FAILED
>> +----------------
>> +
>> +Emitted when migration fails (both is source and target).
>> +
>> +Data: None
>>
>
> There should be some information about why it failed, no? Preferrably
> in a QError format.
At this point, we have basically -1 :(
I can add a field with an error number, but we are very bad at the
moment about moving errno's upstack.
>> +Example:
>> +
>> +{ "event": "MIGRATION_FAILED",
>> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
>> +
>> +MIGRATION_STARTED
>> +-----------------
>> +
>> +Emitted when migration starts (both in source and target).
>>
>
> I think this makes more sense as a MIGRATION_CONNECTED event. It
> probably should carry peer information too.
What kind of peer information?
We have tcp/fd/exec/unix migrations. calling it CONNECTED vs STARTED, I
don't care. But adding information? Notice that the management
application knows what it did, I can put the:
"exec: gzip -d < /tmp/foo"
string, but not much more that I can put here.
Later, Juan.
- [Qemu-devel] [PATCH v2 0/5] Add QMP migration events, Juan Quintela, 2010/05/25
- [Qemu-devel] [PATCH 2/5] Factorize common migration incoming code, Juan Quintela, 2010/05/25
- [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events, Juan Quintela, 2010/05/25
- Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events, Anthony Liguori, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events,
Juan Quintela <=
- Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Daniel P. Berrange, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Anthony Liguori, 2010/05/25
- Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Daniel P. Berrange, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Juan Quintela, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Anthony Liguori, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Luiz Capitulino, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Juan Quintela, 2010/05/25
- Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Daniel P. Berrange, 2010/05/25
- Re: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Anthony Liguori, 2010/05/25
- [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events, Juan Quintela, 2010/05/25