On Wed, May 18, 2022 at 15:59:46 +0200, Peter Krempa wrote:
> On Wed, May 18, 2022 at 15:40:18 +0200, Jiri Denemark wrote:
> > On Thu, May 12, 2022 at 14:14:15 +0200, Peter Krempa wrote:
> > > > +static char *
> > > > +qemuMigrationSrcBeginResume(virQEMUDriver *driver,
> > > > + virDomainObj *vm,
> > > > + const char *xmlin,
> > > > + char **cookieout,
> > > > + int *cookieoutlen,
> > > > + unsigned long flags)
> > > > +{
> > > > + virDomainJobStatus status;
> > > > +
> > > > + if (qemuMigrationAnyRefreshStatus(driver, vm, VIR_ASYNC_JOB_MIGRATION_OUT,
> > > > + &status) < 0)
> > > > + return NULL;
> > > > +
> > > > + if (status != VIR_DOMAIN_JOB_STATUS_POSTCOPY_PAUSED) {
> > > > + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> > > > + _("QEMU reports migration is still running"));
> > > > + return NULL;
> > > > + }
> > > > +
> > > > + return qemuMigrationSrcBeginXML(driver, vm, xmlin,
> > > > + cookieout, cookieoutlen, 0, NULL, 0, flags);
> > >
> > > Certain steps here around the non-shared-storage migration are redundant
> > > at this point and IMO should be skipped.
> >
> > Which is what happens in qemuMigrationSrcBegin:
> >
> > if (flags & VIR_MIGRATE_POSTCOPY_RESUME) {
> > xml = qemuMigrationSrcBeginResumePhase(...);
> > goto cleanup;
> > }
> >
> > ...
> >
> > Or did I miss anything?
>
> In 'qemuMigrationSrcBeginXML'
> qemuMigrationSrcBeginPhaseBlockDirtyBitmaps is called which does a bunch
> of setup for bitmap migration which is pointless when recovering as
> storage is copied already if the CPUs are running on the destination.
Oh I see. This part is actually skipped, although it is not easily
visible. The function is only called when QEMU_MIGRATION_COOKIE_NBD is
set in cookieFlags and qemuMigrationSrcBeginResume calls
qemuMigrationSrcBeginXML with cookieFlags == 0.
Jirka
