Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
On Tue, 25 May 2010 13:51:01 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
On 05/25/2010 01:31 PM, Luiz Capitulino wrote:
On Tue, 25 May 2010 16:21:03 +0200
Juan Quintelaquint...@redhat.com wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintelaquint...@redhat.com
---
QMP/qmp-events.txt | 50
++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..93caa4d 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
Shouldn't this one be emitted in the destination?
Destination can't distinguish a cancelled from a closed pipe. But the
idea is that a third party is talking to both source and destination so
it knows if it's cancelled the migration.
Yeah, got it.
+Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
+and CANCELED migration for target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration ends (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
What about a MIGRATION_FINISHED event, which contains a 'success'
key which is a bool?
The only disadvantage of this is if we decide to add more information
to the event (say, stats) then it'd get ugly. Otherwise, one event is
enough.
Anyway, the counterpart of MIGRATION_FAILED is MIGRATION_SUCCEEDED.
I see MIGRATION_FAILED as being very similar to block I/O error events.
I think we'll need a very similar solution for both. It boils down to,
how do we raise asynchronous events when something fails?
You mean we should have a sort of error specific events?
[Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela quint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..93caa4d 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+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).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration ends (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_STARTED
+-
+
+Emitted when migration starts (both in source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_STARTED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
RESET
-
diff --git a/monitor.c b/monitor.c
index ad50f12..5158780 100644
--- a/monitor.c
+++ b/monitor.c
@@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
case QEVENT_WATCHDOG:
event_name = WATCHDOG;
break;
+case QEVENT_MIGRATION_STARTED:
+event_name = MIGRATION_STARTED;
+break;
+case QEVENT_MIGRATION_ENDED:
+event_name = MIGRATION_ENDED;
+break;
+case QEVENT_MIGRATION_FAILED:
+event_name = MIGRATION_FAILED;
+break;
+case QEVENT_MIGRATION_CANCELED:
+event_name = MIGRATION_CANCELED;
+break;
default:
abort();
break;
diff --git a/monitor.h b/monitor.h
index ea15469..34bcd38 100644
--- a/monitor.h
+++ b/monitor.h
@@ -28,6 +28,10 @@ typedef enum MonitorEvent {
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
+QEVENT_MIGRATION_STARTED,
+QEVENT_MIGRATION_ENDED,
+QEVENT_MIGRATION_FAILED,
+QEVENT_MIGRATION_CANCELED,
QEVENT_MAX,
} MonitorEvent;
--
1.6.6.1
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
On 05/25/2010 09:21 AM, Juan Quintela wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintelaquint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..93caa4d 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+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.
+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?
+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.
+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.
Regards,
Anthony Liguori
+Data: None
+
+Example:
+
+{ event: MIGRATION_STARTED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
RESET
-
diff --git a/monitor.c b/monitor.c
index ad50f12..5158780 100644
--- a/monitor.c
+++ b/monitor.c
@@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
case QEVENT_WATCHDOG:
event_name = WATCHDOG;
break;
+case QEVENT_MIGRATION_STARTED:
+event_name = MIGRATION_STARTED;
+break;
+case QEVENT_MIGRATION_ENDED:
+event_name = MIGRATION_ENDED;
+break;
+case QEVENT_MIGRATION_FAILED:
+event_name = MIGRATION_FAILED;
+break;
+case QEVENT_MIGRATION_CANCELED:
+event_name = MIGRATION_CANCELED;
+break;
default:
abort();
break;
diff --git a/monitor.h b/monitor.h
index ea15469..34bcd38 100644
--- a/monitor.h
+++ b/monitor.h
@@ -28,6 +28,10 @@ typedef enum MonitorEvent {
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
+QEVENT_MIGRATION_STARTED,
+QEVENT_MIGRATION_ENDED,
+QEVENT_MIGRATION_FAILED,
+QEVENT_MIGRATION_CANCELED,
QEVENT_MAX,
} MonitorEvent;
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
On Tue, May 25, 2010 at 10:09:55AM -0500, Anthony Liguori wrote:
On 05/25/2010 09:21 AM, Juan Quintela wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
+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?
+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.
+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.
FYI the original request for these events from a libvirt POV
for in terms of identifying the lifecycle transitions.
Currently we issue a migration commend on source, and then have
to poll very frequently on 'info migrate' to get progress stats,
and to determine completion. We want to poll much less frequently
for stats, and get async notification of completion/errors on the
source.
Simiarly on the destination, we need to know when any migration
operation is taking place, so we can avoid issuing monitor
commands to the QEMU process during that time, and also track
success/failure + eventually get progress information via an
equivalent of 'info migrate' on destination.
So this is really focused on lifecycle transitions, rather than
network client connections. I'm not convinced that we should mix
up the two sorts of data. If we want to track network client
connections IMHO they ought to be separate events. Perhaps
there should be a generic QEMU network CONNECT/DISCONNECT
event that works for all QEMU network sockets (migration, chardevs,
netdev sockets, vnc, spice, and whatever we invent in future using
sockets).
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
On Tue, 25 May 2010 16:21:03 +0200
Juan Quintela quint...@redhat.com wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela quint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..93caa4d 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
Shouldn't this one be emitted in the destination?
+Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
+and CANCELED migration for target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration ends (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
What about a MIGRATION_FINISHED event, which contains a 'success'
key which is a bool?
The only disadvantage of this is if we decide to add more information
to the event (say, stats) then it'd get ugly. Otherwise, one event is enough.
Anyway, the counterpart of MIGRATION_FAILED is MIGRATION_SUCCEEDED.
+
+MIGRATION_STARTED
+-
+
+Emitted when migration starts (both in source and target).
Don't you need this only on the destination?
Re: [Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
On 05/25/2010 01:31 PM, Luiz Capitulino wrote:
On Tue, 25 May 2010 16:21:03 +0200
Juan Quintelaquint...@redhat.com wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintelaquint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..93caa4d 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
Shouldn't this one be emitted in the destination?
Destination can't distinguish a cancelled from a closed pipe. But the
idea is that a third party is talking to both source and destination so
it knows if it's cancelled the migration.
+Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
+and CANCELED migration for target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration ends (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
What about a MIGRATION_FINISHED event, which contains a 'success'
key which is a bool?
The only disadvantage of this is if we decide to add more information
to the event (say, stats) then it'd get ugly. Otherwise, one event is enough.
Anyway, the counterpart of MIGRATION_FAILED is MIGRATION_SUCCEEDED.
I see MIGRATION_FAILED as being very similar to block I/O error events.
I think we'll need a very similar solution for both. It boils down to,
how do we raise asynchronous events when something fails?
Regards,
Anthony Liguori
[Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela quint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..234360f 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
+Target will emit MIGRATION_CANCELED (no way to differentiate a FAILED
+and CANCELED migration).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration starts (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_STARTED
+-
+
+Emitted when migration starts (both in source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_STARTED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
RESET
-
diff --git a/monitor.c b/monitor.c
index a1ebc5d..723ca73 100644
--- a/monitor.c
+++ b/monitor.c
@@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
case QEVENT_WATCHDOG:
event_name = WATCHDOG;
break;
+case QEVENT_MIGRATION_STARTED:
+event_name = MIGRATION_STARTED;
+break;
+case QEVENT_MIGRATION_ENDED:
+event_name = MIGRATION_ENDED;
+break;
+case QEVENT_MIGRATION_FAILED:
+event_name = MIGRATION_FAILED;
+break;
+case QEVENT_MIGRATION_CANCELED:
+event_name = MIGRATION_CANCELED;
+break;
default:
abort();
break;
diff --git a/monitor.h b/monitor.h
index ea15469..34bcd38 100644
--- a/monitor.h
+++ b/monitor.h
@@ -28,6 +28,10 @@ typedef enum MonitorEvent {
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
+QEVENT_MIGRATION_STARTED,
+QEVENT_MIGRATION_ENDED,
+QEVENT_MIGRATION_FAILED,
+QEVENT_MIGRATION_CANCELED,
QEVENT_MAX,
} MonitorEvent;
--
1.6.6.1
