On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:
> On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:
> > On 22.02.23 17:25, Anton Kuchin wrote:
> > > > > > +static int vhost_user_fs_pre_save(void *opaque)
> > > > > > +{
> > > > > > + VHostUserFS *fs = opaque;
> > > > > > + g_autofree char *path = object_get_canonical_path(OBJECT(fs));
> > > > > > +
> > > > > > + switch (fs->migration_type) {
> > > > > > + case VHOST_USER_MIGRATION_TYPE_NONE:
> > > > > > + error_report("Migration is blocked by device %s", path);
> > > > > > + break;
> > > > > > + case VHOST_USER_MIGRATION_TYPE_EXTERNAL:
> > > > > > + return 0;
> > > > > > + default:
> > > > > > + error_report("Migration type '%s' is not
> > > > > > supported by device %s",
> > > > > > + VhostUserMigrationType_str(fs->migration_type), path);
> > > > > > + break;
> > > > > > + }
> > > > > > +
> > > > > > + return -1;
> > > > > > +}
> > > > > Should we also add this as .pre_load, to force user select
> > > > > correct migration_type on target too?
> > > > In fact, I would claim we only want pre_load.
> > > > When qemu is started on destination we know where it's migrated
> > > > from so this flag can be set.
> > > > When qemu is started on source we generally do not yet know so
> > > > we don't know whether it's safe to set this flag.
> >
> > But destination is a "source" for next migration, so there shouldn't be
> > real difference.
> > The new property has ".realized_set_allowed = true", so, as I understand
> > it may be changed at any time, so that's not a problem.
>
> Yes, exactly. So destination's property sets not how it will handle this
> incoming
> migration but the future outgoing one.
How do you know where you are going to migrate though?
I think you don't.
Setting it on source is better since we know where we
are migrating from.
> >
> > >
> > > This property selects if VM can migrate and if it can what should
> > > qemu put
> > > to the migration stream. So we select on source what type of
> > > migration is
> > > allowed for this VM, destination can't check anything at load time.
> >
> > OK, so the new field "migration" regulates only outgoing migration and
> > do nothing for incoming. On incoming migration the migration stream
> > itself defines the type of device migration.
> > Worth mentioning in doc?
>
> Good point. I don't think this deserves a respin but if I have to send v4
> I'll include
> clarification in it.
