From: Luiz Capitulino <lcapitulino@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events
Date: Wed, 9 Jun 2010 17:52:15 -0300 [thread overview]
Message-ID: <20100609175215.2e2071a0@redhat.com> (raw)
In-Reply-To: <cover.1276085283.git.quintela@redhat.com>
On Wed, 9 Jun 2010 14:10:53 +0200
Juan Quintela <quintela@redhat.com> 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?
>
> 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(-)
>
>
next prev parent reply other threads:[~2010-06-09 20:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 12:10 [Qemu-devel] [PATCH v3 0/5] Add QMP migration events Juan Quintela
2010-06-09 12:10 ` [Qemu-devel] [PATCH v3 1/5] Exit if incoming migration fails Juan Quintela
2010-06-23 1:47 ` Anthony Liguori
2010-06-24 20:41 ` [Qemu-devel] [PATCH] win32: Add define for missing EPROTONOSUPPORT Stefan Weil
2010-06-27 20:25 ` Blue Swirl
2010-06-09 12:10 ` [Qemu-devel] [PATCH v3 2/5] Factorize common migration incoming code Juan Quintela
2010-06-09 12:10 ` [Qemu-devel] [PATCH v3 3/5] QMP: Introduce MIGRATION events Juan Quintela
2010-06-09 20:54 ` Luiz Capitulino
2010-06-10 10:33 ` [Qemu-devel] " Juan Quintela
2010-06-11 13:12 ` Luiz Capitulino
2010-06-09 12:10 ` [Qemu-devel] [PATCH v3 4/5] QMP: Emit migration events on incoming migration Juan Quintela
2010-06-09 12:10 ` [Qemu-devel] [PATCH v3 5/5] QMP: Emit migration events on outgoing migration Juan Quintela
2010-06-09 14:47 ` [Qemu-devel] [PATCH v3 0/5] Add QMP migration events Yoshiaki Tamura
2010-06-09 15:59 ` [Qemu-devel] " Juan Quintela
2010-06-09 22:07 ` Yoshiaki Tamura
2010-06-09 20:52 ` Luiz Capitulino [this message]
2010-06-09 21:19 ` [Qemu-devel] " Yoshiaki Tamura
2010-06-10 10:44 ` [Qemu-devel] " Juan Quintela
2010-06-11 14:30 ` Luiz Capitulino
2010-06-11 14:38 ` Anthony Liguori
2010-06-11 16:42 ` Luiz Capitulino
2010-06-12 11:20 ` Juan Quintela
2010-06-14 14:36 ` Luiz Capitulino
2010-06-14 15:45 ` Juan Quintela
2010-06-12 11:14 ` Juan Quintela
2010-06-14 13:58 ` Anthony Liguori
2010-06-14 14:24 ` Luiz Capitulino
2010-06-14 14:35 ` Anthony Liguori
2010-06-14 14:42 ` Luiz Capitulino
2010-06-12 11:05 ` Juan Quintela
2010-06-14 14:03 ` Anthony Liguori
2010-06-14 16:02 ` Juan Quintela
2010-06-14 16:10 ` Anthony Liguori
2010-06-14 18:35 ` Juan Quintela
2010-06-14 19:07 ` Anthony Liguori
2010-06-14 19:54 ` Juan Quintela
2010-06-14 20:01 ` Anthony Liguori
2010-06-15 10:30 ` Juan Quintela
2010-06-15 13:40 ` Luiz Capitulino
2010-06-15 15:24 ` Juan Quintela
2010-06-16 18:01 ` Luiz Capitulino
2010-06-16 19:10 ` Juan Quintela
2010-06-17 14:23 ` Luiz Capitulino
2010-06-17 16:34 ` Juan Quintela
2010-06-17 16:45 ` Luiz Capitulino
2010-06-17 17:53 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100609175215.2e2071a0@redhat.com \
--to=lcapitulino@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.