[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: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
Date: Thu, 27 May 2010 11:07:28 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 05/27/2010 10:58 AM, Juan Quintela wrote:
Luiz Capitulino<address@hidden>  wrote:
On Wed, 26 May 2010 11:55:31 -0500
Anthony Liguori<address@hidden>  wrote:
That's exactly how the protocol is designed.  That was one of the major
improvements of QMP over the human monior.
  Yes and it already has 'id' support:

{ "execute": "cont", "id": "luiz" }
{"timestamp": {"seconds": 1274966635, "microseconds": 776813}, "event": 
{"return": {}, "id": "luiz"}

  But it doesn't detect duplicates, this is something I think it's up
to the client to do, do you agree?

This is how the info balloon command works, BTW.
  I won't remember the details now, but that interface has some issues and it
has to be reviewed.

Since there's a clear correlation between the request and the result of
the request, an asynchronous command is what makes the most sense.  It
eliminates the problem of how to pass QErrors via an event which is one
of the problems with the current event proposal.
  Not exactly, this is a problem with QError not the event proposal. We'll
have the same issue if we decide to include errno in the migrate errors and
the problem still exists with the BLOCK_IO_ERROR event.

  That said, I do agree that migrate should be asynchronous. This yet another
thing we may want to fix before 0.13.
How difficult is that?

Easy. I've got a patch locally and will submit an RFC this afternoon. I'm currently converting the migration error's to QError to make sure than when an error occurs, we can report it in a meaningful way.

We'll still need the MIGRATION_CONNECTED event though and I'm not currently planning on working on that.


For tcp: and unix:, a CONNECTED event absolutely makes sense (every
socket server should emit a CONNECTED event).  Unfortunately, after
CONNECTED you lose the monitor until migration is complete.  If
something bad happens, you have to exit qemu so once the monitor
returns, migration has completed successfully.

If we introduce live incoming migration, we'll need to rethink things.
I would actually suggest that we deprecate the incoming command if we do
that and make incoming migration a monitor command.  I would think it
should have the same semantics as migrate (as an asynchronous command).
A CONNECTED event still makes sense for tcp and unix protocols but I
don't think events make sense for start stop vs. an asynchronous command

Do you actually mean 'deprecate -incoming arg' here ?

Yes.  And by deprecate, I really mean that -incoming just becomes
syntactic sugar for executing a monitor command immediately.
  But we can't change -incoming itself, since our command-line is supposed
to be stable, right?

  Also, Juan has said that replacing that arg with a monitor command
doesn't work, as qemu would have to be started in paused monitor for this
to work.

  So, what about introducing a -incoming-monitor command, which puts qemu
in the right state for migration, but requires a migrate_incoming command
to actually start migration?
this -incoming-monitor is called -S, that should have a long name of

that is what it does, and what we need for incoming migration as monitor
command.  Nothing new to see here.

Agreed. We could introduce a migrate_incoming command but it wouldn't be possible to poll it's results while the command executed. I'd rather not do that though because that's potentially ugly for clients to deal with.


Anthony Liguori

Later, Juan.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]