[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 27 May 2010 17:58:03 +0200
Juan Quintela <quintela@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > On Wed, 26 May 2010 11:55:31 -0500
> > Anthony Liguori <anthony@codemonkey.ws> 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?

 Anthony is working on this and should have patches soon.

[...]

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

 Ok, I thought -S alone wasn't enough but if it's, let's go for it then.