On Wed, Dec 02, 2020 at 01:10:37PM +0000, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@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 :|
