Add QMP migration events

Signed-off-by Juan Quintela<[email protected]>

---
  migration.c |   16 ++++++++++------
  migration.h |    2 +-
  vl.c        |    7 ++++++-
  3 files changed, 17 insertions(+), 8 deletions(-)

migration.c +10 -6

index fbf2339..ecc67f1 100644
@@ -36,22 +36,26 @@ static uint32_t max_throttle = (32<<  20);
 
  static MigrationState *current_migration;
 
-void qemu_start_incoming_migration(const char *uri)
+int qemu_start_incoming_migration(const char *uri)
  {
      const char *p;
+    int ret;
 
      if (strstart(uri, "tcp:",&p))
-        tcp_start_incoming_migration(p);
+        ret = tcp_start_incoming_migration(p);
  #if !defined(WIN32)
      else if (strstart(uri, "exec:",&p))
-        exec_start_incoming_migration(p);
+        ret =  exec_start_incoming_migration(p);
      else if (strstart(uri, "unix:",&p))
-        unix_start_incoming_migration(p);
+        ret = unix_start_incoming_migration(p);
      else if (strstart(uri, "fd:",&p))
-        fd_start_incoming_migration(p);
+        ret = fd_start_incoming_migration(p);
  #endif
-    else
+    else {
          fprintf(stderr, "unknown migration protocol: %s\n", uri);
+        ret = -EPROTONOSUPPORT;
+    }
+    return ret;
  }
 
  int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)

migration.h +1 -1

index 97eef4a..e048bb2 100644
@@ -50,7 +50,7 @@ struct FdMigrationState
      void *opaque;
  };
 
-void qemu_start_incoming_migration(const char *uri);
+int qemu_start_incoming_migration(const char *uri);
 
  int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
 

vl.c +6 -1

index 7121cd0..c35b46e 100644
@@ -3826,7 +3826,12 @@ int main(int argc, char **argv, char **envp)
      }
 
      if (incoming) {
-        qemu_start_incoming_migration(incoming);
+        int ret = qemu_start_incoming_migration(incoming);
+        if (ret<  0) {
+            fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
+                    incoming, ret);
+            exit(ret);
+        }
      } else if (autostart) {
          vm_start();
      }

mingw32 does not define EPROTONOSUPPORT (which is used by migration.c and maybe future patches), so add a definition which uses a supported errno value.

Signed-off-by Stefan Weil <[email protected]>

---
 qemu-os-win32.h |    4 ++++

 1 files changed, 4 insertions(+), 0 deletions(-)

qemu-os-win32.h +4 -1

index 6323f7f..2ff9f45 100644
@@ -49,4 +49,8 @@ static inline void os_setup_post(void) {}
  static inline void os_set_line_buffering(void) {}
  static inline void os_set_proc_name(const char *dummy) {}
 
+#if !defined(EPROTONOSUPPORT)
+# define EPROTONOSUPPORT EINVAL
+#endif
+
  #endif
--

1.7.1

They are emitted when migration starts, ends, has a failure or is canceled.

Signed-off-by Juan Quintela <[email protected]>

---
 QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 monitor.c          |   12 ++++++++++++
 monitor.h          |    4 ++++
 3 files changed, 68 insertions(+), 0 deletions(-)

QMP/qmp-events.txt +22 -0

index 01ec85f..cafc4e6 100644
@@ -26,6 +26,58 @@ 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:

QMP/qmp-events.txt +20 -0

+
+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
 -----
 

monitor.c +12 -0

index 15b53b9..a5c5388 100644
@@ -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;

monitor.h +4 -0

index ea15469..34bcd38 100644
@@ -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;
 

QMP/qmp-events.txt Example: · line 60

Quoted 6 lines · On Wed, 9 Jun 2010 14:10:56 +0200 Juan Quintela <[email protected]> wrote:

QMP/qmp-events.txt +6 -0

+MIGRATION_FAILED
+----------------
+
+Emitted when migration fails (both is source and target).  Notice
+that this event will be changed for 0.14 when we have infrastructure
+to emit a QError when things fail.

This is not the kind of information this file should have, compatible
changes should be noted when time comes and incompatible ones are just forbidden after 0.13.

Quoted 13 lines · Luiz Capitulino

QMP/qmp-events.txt Example: · line 60

Quoted 6 lines · On Wed, 9 Jun 2010 14:10:56 +0200 Juan Quintela <[email protected]> wrote:

QMP/qmp-events.txt +6 -0

+MIGRATION_FAILED
+----------------
+
+Emitted when migration fails (both is source and target).  Notice
+that this event will be changed for 0.14 when we have infrastructure
+to emit a QError when things fail.

This is not the kind of information this file should have, compatible
changes should be noted when time comes and incompatible ones are just forbidden after 0.13.

Then how you express that this value is going to have a QError in it on the future?

Adding a Default QError that puts 'This QError is going to be refined' or what?

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.

Later, Juan.

v3:
- Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that)
 rebase against today tree

v2:
- Address pbonzini and mst changes
 (error messages and doc fixes)

v1:

This series does:

- exit incoming migration on failure.  For exec/fd migrations, once there was a failure, there was nothing useful to do.  And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration.

- Factorize common migration code, no more duplication, makes easier to do "global" migration things, like QMP events.

- Introduce QMP events, both for incoming and outgoing migration.

Now, the million dollar question: Why I didn't refactorize outgoing migration?  I tried, and have it partially done on my local tree.  But it depends (too much) of current_migration global variable -> Libvirt folks will also want "info migrate" to work on the incoming side, i.e. current_migraition has to also be updated on incoming side.  Done until here, but then I hit the wall "incoming migration is synchronous".

To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution.  I am open to suggestions about what to do here.

This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later.

Please review and consider to apply it.

Later, Juan.

Juan Quintela (5):
 Exit if incoming migration fails
 Factorize common migration incoming code
 QMP: Introduce MIGRATION events
 QMP: Emit migration events on incoming migration
 QMP: Emit migration events on outgoing migration

 QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ migration-exec.c   |   17 +++--------------
 migration-fd.c     |   15 ++-------------
 migration-tcp.c    |   17 ++++-------------
 migration-unix.c   |   17 ++++-------------
 migration.c        |   37 +++++++++++++++++++++++++++++++------ migration.h        |    4 +++-
 monitor.c          |   12 ++++++++++++
 monitor.h          |    4 ++++
 vl.c               |    7 ++++++-

 10 files changed, 121 insertions(+), 61 deletions(-)

Hi Juan,

I don't know I have addressed the problem correctly, but here is my try to get "info migrate" on incoming side.

http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html

Apart from that I have a concern on relation between newly introduced QMP Migration events and existing MIG_STATE_*. Are they supposed to be 1 to 1 mapping?

If so, instead of calling
monitor_protocol_event() everywhere, how about introducing a common function in migration that sets s->mig_state and emits QMP Migration events at once?

Quoted 7 lines · Yoshiaki Tamura

Hi Juan,

I don't know I have addressed the problem correctly, but here is my try to get "info migrate" on incoming side.

http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00417.html

I saw it, haven't had the time to look at it yet.

Quoted 3 lines

Apart from that I have a concern on relation between newly introduced QMP Migration events and existing MIG_STATE_*.  Are they supposed to be 1 to 1 mapping?

Good question.  In my tree I had info migrate being the same on source and destination, but I didn't have async migration.  I have to check with yours.

Quoted 4 lines

If so, instead of calling
monitor_protocol_event() everywhere, how about introducing a common function in migration that sets s->mig_state and emits QMP Migration events at once?

I did that locally, just that this is in the middle of a big cleanup.

I am not sure that is still enough.  We have:

- qemu status: running/stopped
- we have another state "incoming" migration that needs to be same level than running/stopped
- I think MIG_STATE_* should also be promotted to this level, but haven't fully thought how to do it.

Later, Juan.

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.

Later, Juan.

v3:
- Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that)
rebase against today tree

v2:
- Address pbonzini and mst changes
(error messages and doc fixes)

v1:

This series does:

- exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration.

- Factorize common migration code, no more duplication, makes easier to do "global" migration things, like QMP events.

- Introduce QMP events, both for incoming and outgoing migration.

Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable -> Libvirt folks will also want "info migrate" to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall "incoming migration is synchronous".

To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here.

This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later.

Please review and consider to apply it.

Later, Juan.

Juan Quintela (5):
Exit if incoming migration fails Factorize common migration incoming code
QMP: Introduce MIGRATION events
QMP: Emit migration events on incoming migration
QMP: Emit migration events on outgoing migration

 QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 migration-exec.c   |   17 +++--------------
 migration-fd.c     |   15 ++-------------
 migration-tcp.c    |   17 ++++-------------
 migration-unix.c   |   17 ++++-------------
 migration.c        |   37 +++++++++++++++++++++++++++++++------
 migration.h        |    4 +++-
 monitor.c          |   12 ++++++++++++
 monitor.h          |    4 ++++
 vl.c               |    7 ++++++-
 10 files changed, 121 insertions(+), 61 deletions(-)

Quoted 3 lines · On Wed,  9 Jun 2010 14:10:53 +0200 Juan Quintela <[email protected]> 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?

Quoted 66 lines

Later, Juan.

v3:
- Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that)
  rebase against today tree

v2:
- Address pbonzini and mst changes
  (error messages and doc fixes)

v1:

This series does:

- exit incoming migration on failure.  For exec/fd migrations, once there was a failure, there was nothing useful to do.  And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration.

- Factorize common migration code, no more duplication, makes easier to do "global" migration things, like QMP events.

- Introduce QMP events, both for incoming and outgoing migration.

Now, the million dollar question: Why I didn't refactorize outgoing migration?  I tried, and have it partially done on my local tree.  But it depends (too much) of current_migration global variable -> Libvirt folks will also want "info migrate" to work on the incoming side, i.e. current_migraition has to also be updated on incoming side.  Done until here, but then I hit the wall "incoming migration is synchronous".

To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution.  I am open to suggestions about what to do here.

This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later.

Please review and consider to apply it.

Later, Juan.

Juan Quintela (5):
  Exit if incoming migration fails Factorize common migration incoming code
  QMP: Introduce MIGRATION events
  QMP: Emit migration events on incoming migration
  QMP: Emit migration events on outgoing migration

 QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ migration-exec.c   |   17 +++--------------
 migration-fd.c     |   15 ++-------------
 migration-tcp.c    |   17 ++++-------------
 migration-unix.c   |   17 ++++-------------
 migration.c        |   37 +++++++++++++++++++++++++++++++------ migration.h        |    4 +++-
 monitor.c          |   12 ++++++++++++
 monitor.h          |    4 ++++
 vl.c               |    7 ++++++-

 10 files changed, 121 insertions(+), 61 deletions(-)

Quoted 3 lines · On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela <[email protected]> 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?

Quoted 7 lines · Luiz Capitulino

Quoted 3 lines · On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela <[email protected]> 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.

Quoted 6 lines

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:

- MIGRATION_STARTED: somebody started a migration, it is emited on source and target, all monitors receive this event.

- 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.

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.

Quoted 10 lines · On Thu, 10 Jun 2010 12:44:55 +0200 Juan Quintela<[email protected]> wrote:

Quoted 8 lines · Luiz Capitulino

Quoted 4 lines · On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela<[email protected]> 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.

Quoted 9 lines

Quoted 7 lines

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" }

Quoted 3 lines

- 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?

Quoted 7 lines

- 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.

Quoted 4 lines

- 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?

Quoted 10 lines

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.

Quoted 6 lines

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" }

This is how just about every RPC mechanism works...

Quoted 5 lines

Quoted 3 lines

- 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?

I think we've more or less agreed that MIGRATION_CONNECTED is really the event we want.

Quoted 7 lines

Quoted 7 lines

- 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.

Quoted 6 lines

Quoted 4 lines

- 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.

MIGRATION_DONE gets deprecated for 0.14.

Quoted 8 lines · On Fri, 11 Jun 2010 09:38:42 -0500 Anthony Liguori <[email protected]>…

Quoted 6 lines

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" }

This is how just about every RPC mechanism works...

Let's go for it then.

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

- MIGRATION_STARTED: somebody started a migration, it is emited on source and target, all monitors receive this event.

Quoted 5 lines

Quoted 2 lines

The client has started the migration, it knows it. Why is the event needed?

I think we've more or less agreed that MIGRATION_CONNECTED is really the event we want.

Is it useful in the source or in the target?

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

- 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.

Quoted 5 lines

Quoted 2 lines

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.

[...]

Quoted 1 line

MIGRATION_DONE gets deprecated for 0.14.

Yeah, this removes the need for polling in 0.13, but I was wondering if
it's worth it. If I'm not mistaken, libvirt does the polling when working with the text Monitor and I believe it's not a big deal to keep it until 0.14.

Quoted 20 lines · Luiz Capitulino

Quoted 8 lines · On Fri, 11 Jun 2010 09:38:42 -0500 Anthony Liguori <[email protected]>…

Quoted 6 lines

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" }

This is how just about every RPC mechanism works...

Let's go for it then.

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

- 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?

Quoted 4 lines

Quoted 2 lines

I think we've more or less agreed that MIGRATION_CONNECTED is really the event we want.

Is it useful in the source or in the target?

Both.

Quoted 17 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

- 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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 7 lines

[...]

Quoted 1 line

MIGRATION_DONE gets deprecated for 0.14.

Yeah, this removes the need for polling in 0.13, but I was wondering if
it's worth it. If I'm not mistaken, libvirt does the polling when working with the text Monitor and I believe it's not a big deal to keep it until 0.14.

It makes things slower for no good reason.

This reasoning is sneaky at least:
- qemu didn't give interfaces to libvirt for do what libvirt wanted
- libvirt uses workarounds
- qemu tells libvirt that they are using workarounds that they shouldn't
- libvirt tells qemu why they need the new interface
- qemu tells libvirt that they could continue to use its workarounds.

I am losing something? The whole point of live migration is that they need to be as fast as possible. For some scenaries (shared storage with funny locking) libvirt needs to move from shared locks to normal locks as far as migration ends on target. We are telling them to do workarounds becauese qemu don't want to tell libvirt on destination when migration has ended.

Why can't we just tell them that migration has ended with success as fast as possible?

I can't understand what I am missing here. I can't believe that libvirt(management app in general) could came with a simple request that would make its live better. And to make things worse, it is _trivial_ to implement, semantics are clear, has other uses, .....

Quoted 1 line · On Sat, 12 Jun 2010 13:20:54 +0200 Juan Quintela <[email protected]> wrote:

Both.

What does it report in the source?

Quoted 7 lines

Why can't we just tell them that migration has ended with success as fast as possible?

I can't understand what I am missing here. I can't believe that libvirt(management app in general) could came with a simple request that would make its live better. And to make things worse, it is _trivial_ to implement, semantics are clear, has other uses, .....

I'd be ok in having the done event if the polling is shown to be that
problematic, but from some private talks I had with libvirt guys it seemed to me that it's more like a wish have.

For us, having this event means that we'll have to carry it for (at least)
several releases. I really would like to avoid adding one-time workarounds in a stable interface like QMP.

Quoted 2 lines · Luiz Capitulino

On Thu, 10 Jun 2010 12:44:55 +0200
Juan Quintela<[email protected]> wrote:

I think we've more or less agreed that MIGRATION_CONNECTED is really the event we want.

Quoted 11 lines

Quoted 11 lines

- 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.

Quoted 2 lines

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.

Quoted 10 lines

Quoted 10 lines

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.

Quoted 5 lines

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.

Quoted 2 lines · Anthony Liguori

On 06/11/2010 09:30 AM, Luiz Capitulino wrote:

Quoted 7 lines

Quoted 3 lines

On Thu, 10 Jun 2010 12:44:55 +0200
Juan Quintela<[email protected]> 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.

Quoted 3 lines

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.

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.

For 0.13, we need to focus on introducing the least disruptive change that addresses the fundamental requirement--allow clients to avoid a polling loop for determining when migration ends. Having a single event with no payload is an extremely simple change.

Quoted 5 lines · On Mon, 14 Jun 2010 08:58:19 -0500 Anthony…

For 0.13, we need to focus on introducing the least disruptive change that addresses the fundamental requirement--allow clients to avoid a polling loop for determining when migration ends. Having a single event with no payload is an extremely simple change.

Agreed.

Actually, I'm slightly against introducing the done event too. While the
polling is undesired, I don't think that having an event only for a release is worth it.

Quoted 11 lines · Luiz Capitulino

Quoted 5 lines · On Mon, 14 Jun 2010 08:58:19 -0500 Anthony…

For 0.13, we need to focus on introducing the least disruptive change that addresses the fundamental requirement--allow clients to avoid a polling loop for determining when migration ends. Having a single event with no payload is an extremely simple change.

Agreed.

Quoted 4 lines

Actually, I'm slightly against introducing the done event too. While the
polling is undesired, I don't think that having an event only for a release is worth it.

I don't think we can realistically remove it. In my mind, what deprecate means with respect to QMP is that we never add additional features to the deprecated commands.

Right now, 'migrate', 'info migrate', and MIGRATE_DONE do not provide very rich error reporting. They really just provide a boolean failed/succeeded.

For 0.14, we'll have to introduce a 'migrate2' command and deprecate the old 'migrate' command. 'migrate2' will provide rich error reporting and all new features will be added to 'migrate2'.

BTW, I lack any kind of naming creativity so 'migrate2' is not necessarily what it ought to be called.

Quoted 8 lines · On Thu, 10 Jun 2010 12:44:55 +0200 Juan Quintela <[email protected]> wrote:

Quoted 7 lines · Luiz Capitulino

Quoted 3 lines · On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela <[email protected]> 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.

Quoted 8 lines

Quoted 6 lines

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.

Quoted 2 lines

- 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?

Quoted 7 lines

- 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.

Quoted 3 lines

- 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?

Quoted 9 lines

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.

Quoted 47 lines · Luiz Capitulino

Quoted 10 lines · On Thu, 10 Jun 2010 12:44:55 +0200 Juan Quintela<[email protected]> wrote:

Quoted 8 lines · Luiz Capitulino

Quoted 4 lines · On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela<[email protected]> 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.

Quoted 9 lines

Quoted 7 lines

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" }

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

- 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.

Quoted 7 lines

Quoted 7 lines

- 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.

Quoted 6 lines

Quoted 4 lines

- 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.

Quoted 6 lines · Juan Quintela

Luiz Capitulino<[email protected]> wrote:

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.

Dual monitors is a slippery slope argument because even if you had these events, it doesn't give you nearly enough information to implement anything safely.

If you truly want to support dual uncooperative monitors, you basically need to mirror every monitor session so that each monitor can see what the other monitors are doing. You also need a transaction mechanism to allow a client to do operations in a non-racy way.

Since we're not likely to ever implement these things, dual monitor support is really not a viable argument for such a change.

QMP is the wrong mechanism for this. Merging the tracing code and then adding trace points to migration is the right solution for this problem.

The problem is, all of the arguments you're using to justify this for the migrate command is applicable for every other command we have. Why do this for migrate and not for commit or savevm?

Do we really want to introduce 4 events for every command that we support?

Quoted 10 lines · Anthony Liguori

Quoted 8 lines · Juan Quintela

Luiz Capitulino<[email protected]> wrote:

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.

Quoted 4 lines

Dual monitors is a slippery slope argument because even if you had these events, it doesn't give you nearly enough information to implement anything safely.

Security folks here needed to do logging of qemu events, here. Guest what ones: vm_start, vm_stop, vm_continue, and vm_migrate.

Insteod of a nice: write this "small qmp client, and listen for this four events, I just had to point them where to hack their logging.

About libvirt, I would rreally, really like to be able to use libvirt to launch a guest, and then let im me launch another monitor and stoup libvirt for continuing with it. There is no way for a monitor that there has been doing "write" operations in other monitors. I see this as a useful feature for all "write" (i.e. not query) commands.

Quoted 9 lines

QMP is the wrong mechanism for this. Merging the tracing code and then adding trace points to migration is the right solution for this problem.

The problem is, all of the arguments you're using to justify this for the migrate command is applicable for every other command we have. Why do this for migrate and not for commit or savevm?

Quoted 2 lines

Do we really want to introduce 4 events for every command that we support?

Migration commands have a "feature" that dont' have other commands: they invosve two machines.

And I would also liked to have that events for all the "write" commands. Migration is more "interesting" becaues it needs synchronization.

Later, Juan.

Quoted 16 lines · Juan Quintela

Quoted 14 lines · Anthony Liguori

Quoted 8 lines · Juan Quintela

Luiz Capitulino<[email protected]> wrote:

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.

Dual monitors is a slippery slope argument because even if you had these events, it doesn't give you nearly enough information to implement anything safely.

Quoted 3 lines

Security folks here needed to do logging of qemu events, here. Guest what ones: vm_start, vm_stop, vm_continue, and vm_migrate.

Why do security folks need this? Why are they not interested in other things like savevm? Why are they talkign to qemu and not libvirt (they shouldn't trust qemu).

Quoted 9 lines

Insteod of a nice: write this "small qmp client, and listen for this four events, I just had to point them where to hack their logging.

About libvirt, I would rreally, really like to be able to use libvirt to launch a guest, and then let im me launch another monitor and stoup libvirt for continuing with it. There is no way for a monitor that there has been doing "write" operations in other monitors. I see this as a useful feature for all "write" (i.e. not query) commands.

Yeah, but if we want to do this, then we need to discuss this with the libvirt folks and come up with a proposal that works for all commands. Sneaking in a few migration events is not going to help.

Quoted 6 lines

Migration commands have a "feature" that dont' have other commands: they invosve two machines.

And I would also liked to have that events for all the "write" commands. Migration is more "interesting" becaues it needs synchronization.

I'm still fundamentally confused about what you think you can do with these events. But do you really intend on introducing events for every non-query QMP command? Does that seem a bit unrealistic?

Wouldn't it be better to have a mechanism to snoop on monitor traffic in a more proper way?

Quoted 24 lines · Anthony Liguori

Quoted 22 lines · Juan Quintela

Quoted 19 lines · Anthony Liguori

Quoted 11 lines · Juan Quintela

Luiz Capitulino<[email protected]> wrote:

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.

Dual monitors is a slippery slope argument because even if you had these events, it doesn't give you nearly enough information to implement anything safely.

Quoted 8 lines

Quoted 4 lines

Security folks here needed to do logging of qemu events, here. Guest what ones: vm_start, vm_stop, vm_continue, and vm_migrate.

Why do security folks need this? Why are they not interested in other things like savevm? Why are they talkign to qemu and not libvirt (they shouldn't trust qemu).

No clue about last one. I just was asked to provide that list of events. will ask back.

Quoted 10 lines

Quoted 10 lines

Insteod of a nice: write this "small qmp client, and listen for this four events, I just had to point them where to hack their logging.

About libvirt, I would rreally, really like to be able to use libvirt to launch a guest, and then let im me launch another monitor and stoup libvirt for continuing with it. There is no way for a monitor that there has been doing "write" operations in other monitors. I see this as a useful feature for all "write" (i.e. not query) commands.

Quoted 4 lines

Yeah, but if we want to do this, then we need to discuss this with the libvirt folks and come up with a proposal that works for all commands. Sneaking in a few migration events is not going to help.

Fully agree.

Quoted 11 lines

Quoted 7 lines

Migration commands have a "feature" that dont' have other commands: they invosve two machines.

And I would also liked to have that events for all the "write" commands. Migration is more "interesting" becaues it needs synchronization.

I'm still fundamentally confused about what you think you can do with these events. But do you really intend on introducing events for every non-query QMP command? Does that seem a bit unrealistic?

Ok. lets stop here. My definitions:

Event: this important thing happened (important has several meanings).

Migration events fully enter in this definition. Furthermore, migration events happens from actions that are issued in machine A and event happens in machine A and machine B. (I.e. they are so special as they can get).

Now convenience. I "think" it would be convenient to also know in the other monitors when any "write" command happens. About how to implement this, if there are more uses or no, .... that is clearly open to discussion. I think that this enter fully in the politics vs mechanism discussions, events allow you to notify when things happen, and management app can do anything that it sees fit.

As principle, I think that "important happenings" (to not repeat the "event" word) should be published in a very clear way. Migration start/end are a basic example of that. It is not as if Migration is going to stop having a "start" or an "end" any time soon. Making the app polling to know that is too cumbersome for the "normal" good case. This kind of things should be plublished "somehow". The same that happens when a machine start/stops. That are improntant events.

Quoted 9 lines · Juan Quintela

Ok. lets stop here. My definitions:

Event: this important thing happened (important has several meanings).

Migration events fully enter in this definition. Furthermore, migration events happens from actions that are issued in machine A and event happens in machine A and machine B. (I.e. they are so special as they can get).

I think you've got too narrow a view. Migration doesn't always involve two machines. Migration can involve just the source writing via "exec:dd of=foo.img" and this is in fact an important use case for libvirt.

Quoted 7 lines

Now convenience. I "think" it would be convenient to also know in the other monitors when any "write" command happens. About how to implement this, if there are more uses or no, .... that is clearly open to discussion. I think that this enter fully in the politics vs mechanism discussions, events allow you to notify when things happen, and management app can do anything that it sees fit.

Quoted 8 lines

As principle, I think that "important happenings" (to not repeat the "event" word) should be published in a very clear way. Migration start/end are a basic example of that. It is not as if Migration is going to stop having a "start" or an "end" any time soon. Making the app polling to know that is too cumbersome for the "normal" good case. This kind of things should be plublished "somehow". The same that happens when a machine start/stops. That are improntant events.

What makes migration important and not savevm?

It's not that I don't agree that migration is important and that it's important for tools to be able to know about it. I disagree that migration is *more* important than most of the other things that happen in the monitor and I want to make sure that we come up with a solution that solves the broader problem.

Quoted 13 lines · Anthony Liguori

Quoted 10 lines · Juan Quintela

Ok. lets stop here. My definitions:

Event: this important thing happened (important has several meanings).

Migration events fully enter in this definition. Furthermore, migration events happens from actions that are issued in machine A and event happens in machine A and machine B. (I.e. they are so special as they can get).

Quoted 5 lines

I think you've got too narrow a view. Migration doesn't always involve two machines. Migration can involve just the source writing via "exec:dd of=foo.img" and this is in fact an important use case for libvirt.

In this case, I also want to know when migration ended.

Quoted 16 lines

Quoted 16 lines

Now convenience. I "think" it would be convenient to also know in the other monitors when any "write" command happens. About how to implement this, if there are more uses or no, .... that is clearly open to discussion. I think that this enter fully in the politics vs mechanism discussions, events allow you to notify when things happen, and management app can do anything that it sees fit.

As principle, I think that "important happenings" (to not repeat the "event" word) should be published in a very clear way. Migration start/end are a basic example of that. It is not as if Migration is going to stop having a "start" or an "end" any time soon. Making the app polling to know that is too cumbersome for the "normal" good case. This kind of things should be plublished "somehow". The same that happens when a machine start/stops. That are improntant events.

Quoted 2 lines

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?

Quoted 6 lines

It's not that I don't agree that migration is important and that it's important for tools to be able to know about it. I disagree that migration is *more* important than most of the other things that happen in the monitor and I want to make sure that we come up with a solution that solves the broader problem.

Agreed. That was also the reason why I told that the "write" commands are "more interesting" in this regard.

But now (at least in my point of view), we are moving in the right direction. From "we can get this with polling + other workarounds" to "this mechininsm could be useful for other things".

Later, Juan.

Quoted 9 lines · Juan Quintela

Quoted 2 lines · Anthony Liguori

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.

Quoted 19 lines · Anthony Liguori

Quoted 9 lines · Juan Quintela

Quoted 2 lines · Anthony Liguori

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.

Quoted 2 lines

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.

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.

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?

Quoted 20 lines · On Tue, 15 Jun 2010 12:30:57 +0200 Juan Quintela <[email protected]> wrote:

Quoted 19 lines · Anthony Liguori

Quoted 9 lines · Juan Quintela

Quoted 2 lines · Anthony Liguori

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 3 lines

MIGRATION_STARTED on target is also quite "nice" to have. At this point libvirt has an

Quoted 3 lines

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.

Quoted 5 lines

As we only wanted one ending event, can agree on:

MIGRATION_STARTED(both source and target)
MIGRATION_DONE(result) (both source and target)

Quoted 4 lines

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.

Quoted 41 lines · Luiz Capitulino

Quoted 20 lines · On Tue, 15 Jun 2010 12:30:57 +0200 Juan Quintela <[email protected]> wrote:

Quoted 19 lines · Anthony Liguori

Quoted 9 lines · Juan Quintela

Quoted 2 lines · Anthony Liguori

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

Hm. Did you investigate that race in detail? I hope we're not using events
to hide bugs.

Yes. we can call "cont" while staying in "waiting for incomming migration" because we dont' have "waiting incoming migraiton" than vm_start/stop understand.

Reviewing all callers to see that I can add a new state.

Quoted 8 lines

Quoted 8 lines

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).

Quoted 4 lines

Quoted 1 line

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

It is important to be sure than migration has started, i.e. something happenend. It happens to me all the time, and users with more complex setup will like it to know what is happening.

As a workaround, we can try something like "info status" or ony read only version to know that migration is not happening (because) monitor is working (as I tell an workaround).

Later, Juan.

Quoted 1 line · On Tue, 15 Jun 2010 17:24:59 +0200 Juan Quintela <[email protected]> wrote:

Quoted 1 line

Quoted 6 lines

Quoted 2 lines

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

Shouldn't the migrate command just the return the expected error?

Quoted 3 lines

It is important to be sure than migration has started, i.e. something happenend. It happens to me all the time, and users with more complex setup will like it to know what is happening.

It already happened to me too, but I feel that the event is being used
as a workaround: we should return good error information instead, like this:

(qemu) migrate tcp:foobar:444
migrate: Can't locate host 'foobar'

(qemu) migrate tcp:doriath:1
migrate: Host 'doriath' is not listening for migration in port 1

(qemu) migrate 'exec:asd'
migrate: Can't execute 'asd'

In QMP the client does get an event, it's the completion response of the
async command, with the error information.

Quoted 4 lines · Luiz Capitulino

Quoted 1 line · On Tue, 15 Jun 2010 17:24:59 +0200 Juan Quintela <[email protected]> wrote:

Quoted 1 line

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

Shouldn't the migrate command just the return the expected error?

No. Think you are "having troubles". You try to find what happens. launch things by hand. And there is no way to know if anybody has conected to the destination machine. Some notification that migration has started is _very_ useful. expecially when there are networks/firewalls/... in the middle.

That is it. But you continue telling that going to the old house and doing a info migrate is a good interface.

To add insult to injury, the problem is that libvirt people are not collaborative, and expect things that can't be done, are uncooperative,

....

Libvirt folks "also" do lots of things wrong, they are not perfect. But it in this case, who is being completely unreasonable is qemu land.

Later, Juan.

Quoted 12 lines · On Wed, 16 Jun 2010 21:10:04 +0200 Juan Quintela <[email protected]> wrote:

Quoted 11 lines · Luiz Capitulino

Quoted 7 lines · On Tue, 15 Jun 2010 17:24:59 +0200 Juan Quintela <[email protected]> wrote:

Quoted 3 lines

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

Quoted 7 lines

Quoted 1 line

Shouldn't the migrate command just the return the expected error?

No. Think you are "having troubles". You try to find what happens. launch things by hand. And there is no way to know if anybody has conected to the destination machine. Some notification that migration has started is _very_ useful. expecially when there are networks/firewalls/... in the middle.

[...]

Quoted 2 lines

That is it. But you continue telling that going to the old house and doing a info migrate is a good interface.

I'm sorry? When did I ever claimed such a thing?

First point: all you describe is MIGRATION_CONNECTED, at the end of the day
it would do exactly what you want for MIGRATION_STARTED.

The second, and most important point, is that we're trying not to make
things worse. Adding a number of events to circumvent a bad designed command and having the wrong expectations (ie. help developer debugging) is a clear recipe for disaster.

Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
stable for 0.13. In this case we'll have enough time to design the proper interface.

Quoted 2 lines

To add insult to injury, the problem is that libvirt people are not collaborative, and expect things that can't be done, are uncooperative,

Again, I've never claimed that and I think you're taking this thread to
the wrong direction.

Quoted 23 lines · Luiz Capitulino

Quoted 19 lines · On Wed, 16 Jun 2010 21:10:04 +0200 Juan Quintela <[email protected]> wrote:

Quoted 4 lines · Luiz Capitulino

Quoted 1 line · On Tue, 15 Jun 2010 17:24:59 +0200 Juan Quintela <[email protected]> wrote:

Quoted 1 line

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

Shouldn't the migrate command just the return the expected error?

No. Think you are "having troubles". You try to find what happens. launch things by hand. And there is no way to know if anybody has conected to the destination machine. Some notification that migration has started is _very_ useful. expecially when there are networks/firewalls/... in the middle.

Quoted 6 lines

[...]

Quoted 2 lines

That is it. But you continue telling that going to the old house and doing a info migrate is a good interface.

I'm sorry? When did I ever claimed such a thing?

polling is enough. polling has to be done in source machine.

Quoted 12 lines

First point: all you describe is MIGRATION_CONNECTED, at the end of the day
it would do exactly what you want for MIGRATION_STARTED.

The second, and most important point, is that we're trying not to make
things worse. Adding a number of events to circumvent a bad designed command and having the wrong expectations (ie. help developer debugging) is a clear recipe for disaster.

Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
stable for 0.13. In this case we'll have enough time to design the proper interface.

Quoted 5 lines

Quoted 2 lines

To add insult to injury, the problem is that libvirt people are not collaborative, and expect things that can't be done, are uncooperative,

Again, I've never claimed that and I think you're taking this thread to
the wrong direction.

Ok, I stop then.

Quoted 30 lines · On Thu, 17 Jun 2010 18:34:00 +0200 Juan Quintela<[email protected]> wrote:

Quoted 28 lines · Luiz Capitulino

Quoted 21 lines · On Wed, 16 Jun 2010 21:10:04 +0200 Juan Quintela<[email protected]> wrote:

Quoted 4 lines · Luiz Capitulino

On Tue, 15 Jun 2010 17:24:59 +0200
Juan Quintela<[email protected]> wrote:

Quoted 9 lines

Quoted 7 lines

Quoted 3 lines

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.

At this point, if you are doing migration with tcp, and you are putting the wrong port on source (no path or any other error), you get no info at all of what is happening.

Shouldn't the migrate command just the return the expected error?

No. Think you are "having troubles". You try to find what happens. launch things by hand. And there is no way to know if anybody has conected to the destination machine. Some notification that migration has started is _very_ useful. expecially when there are networks/firewalls/... in the middle.

[...]

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

That is it. But you continue telling that going to the old house and doing a info migrate is a good interface.

I'm sorry? When did I ever claimed such a thing?

polling is enough. polling has to be done in source machine.

Enough for the meantime, until we have something better to offer. The problem
here is that adding not so good stuff to a protocol is that we will have to maintain it for a quite long time, possibly forever.

That's why I'm being so opposed to a large set of events, a reduced set is a lot
more attractive.

Quoted 13 lines

Quoted 13 lines

First point: all you describe is MIGRATION_CONNECTED, at the end of the day
it would do exactly what you want for MIGRATION_STARTED.

The second, and most important point, is that we're trying not to make
things worse. Adding a number of events to circumvent a bad designed command and having the wrong expectations (ie. help developer debugging) is a clear recipe for disaster.

Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
stable for 0.13. In this case we'll have enough time to design the proper interface.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

To add insult to injury, the problem is that libvirt people are not collaborative, and expect things that can't be done, are uncooperative,

Again, I've never claimed that and I think you're taking this thread to
the wrong direction.

Ok, I stop then.

I'm not asking you to stop arguing, just to avoid taking the non-technical
route in a bad way.

Now, we have the following situation: MIGRATION_CONNECTED and MIGRATION_DONE
would have possibly been a good fit for 0.13 if QMP was going to be stable.

However, that's not going to happen so the question is: is it interesting
to have those events for an unstable QMP? Do we expect any client to need it? Or can we wait until 0.14?