On Thu, May 12, 2022 at 17:16:32 +0200, Peter Krempa wrote:
> On Tue, May 10, 2022 at 17:21:29 +0200, Jiri Denemark wrote:
> > The QEMU process is already running, all we need to do is to call
> > migrate-recover QMP command. Except for some checks and cookie handling,
> > of course.
> >
> > Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>
> > ---
> > src/qemu/qemu_migration.c | 99 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 99 insertions(+)
> >
> > diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> > index 2e9235e1d5..a8481f7515 100644
> > --- a/src/qemu/qemu_migration.c
> > +++ b/src/qemu/qemu_migration.c
> > @@ -3509,6 +3509,98 @@ qemuMigrationDstPrepareFresh(virQEMUDriver *driver,
> > }
>
> [...]
>
> > +
> > + if (qemuMigrationAnyRefreshStatus(driver, vm, VIR_ASYNC_JOB_MIGRATION_IN,
> > + &status) < 0)
> > + goto cleanup;
> > +
> > + if (status != VIR_DOMAIN_JOB_STATUS_POSTCOPY_PAUSED) {
> > + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> > + _("QEMU reports migration is still running"));
> > + goto cleanup;
> > + }
>
> Is there any reason not to allow adopting a running unattended migration
> with a recovery API?
It's easier this way :-) The migration will happily finish anyway so it
does not really matter. You can't just have a synchronous API call and
finished migration is only announced via events. Anyway, it can
definitely be done in a follow up series if desired, although it will
make the code even more complicated as we would have to do all the steps
and just avoid running any QMP commands and jump right into waiting for
migration to finish on both sides.
Jirka
