|
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:1.9.1.5) 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": "RESUME"} {"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 completion.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 -no-autostart 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.
Regards, Anthony Liguori
Later, Juan.
[Prev in Thread] | Current Thread | [Next in Thread] |