Re: [Qemu-devel] [PATCH 0/6] qapi: Convert migrate

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 15 Feb 2012 09:59:07 +0100
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2012-02-10 20:31, Luiz Capitulino wrote:
> > This is a rebase of Anthony's conversion, from his glib branch; and this is
> > also the beginning of the conversion of complex commands to the qapi.
> > 
> > There are two important changes that should be observed:
> > 
> >  1. patch 5/6 purges the 'mon' object from migration code. One of the
> >     consequences is that we lose the ability to print progress status to
> >     the HMP user (esp. in block migration)
> 
> This smells extremely fishy. You have some common "monitor" context in
> both cases, means something that decides where suspend/resume takes
> effect or where to pick up file descriptors from. If the exiting Monitor
> object is not generic enough, introduce some super-class and use that in
> common services. Or make sure that a variant of Monitor is also valid
> over QMP. But don't remove the dependency from the API, while
> reintroducing it via the backdoor of cur_mon.

What we really want to do here is to untangle HMP and QMP. Unfortunately,
the migrate command is one of those commands where the two are deeply
tangled and the split won't be perfect.

However, the two cases you mention above are solvable:

 1. suspend/resume: this is *really* a HMP feature and shouldn't be in any
    QMP code path. This is correctly addressed in this series by moving it
    to hmp_migrate()

 2. file descriptor passing: the new QMP server will support sessions and
    we'll move statefull commands (like getfd) to it. When we do it, we'll
    introduce a new API to get fds that won't depend on the monitor. However,
    this requires all commands to be converted to the qapi first. Meanwhile
    we use the qemu_get_fd() API.

    Note: qemu_get_fd() is temporary, it shouldn't be a problem to use it
    (if it's not incorrect, of course, I honestly haven't fully tested it yet).