Re: [PATCH 24/29] migration, vl: start migration via qmp_migrate_incoming

[Daniel P . Berrangé]

On Wed, Dec 02, 2020 at 01:10:37PM +0000, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonzini@redhat.com) wrote:
> > On 20/11/20 16:34, Igor Mammedov wrote:
> > > >       qapi_event_send_migration(MIGRATION_STATUS_SETUP);
> > > > -    if (!strcmp(uri, "defer")) {
> > > > -        deferred_incoming_migration(errp);
> > > > -    } else if (strstart(uri, "tcp:", &p) ||
> > > > -               strstart(uri, "unix:", NULL) ||
> > > > -               strstart(uri, "vsock:", NULL)) {
> > > considering the last hunk does won't call qmp_migrate_incoming
> > > if 'defer' was used, wouldn't we will lose QAPI event here?
> > > not sure how important it to users,
> > 
> > Hmm yeah that's true.  That might even be considered a bugfix (no setup is
> > done until the "real" migrate-incoming command), but I can also add the
> > event manually in qemu_init.
> > 
> > (Libvirt doesn't use the SETUP case of the event but that's of course only
> > part of the story).
> 
> I'm more worried about how this stops a repeated 'migrate incoming'
> or a 'migrate_incoming' that's issued following a qemu that's been
> started with -incoming tcp:... but which a socket hasn't yet connected
> to.

Can someone remind me why we need to have an -incoming arg at all ?

With snapshots, we can just start QEMU normally, using -S if desired,
and then invoke "loadvm" to restore from a snapshot at any time.

What is different thet means we can't just run "migrate_incoming" on
any QEMU at any time, ignoring -incoming entirely ?


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|