[Virtio-fs] [PATCH v3 1/1] vhost-user-fs: add migration type property

[Anton Kuchin]

On 22/02/2023 18:51, Michael S. Tsirkin wrote:
> 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.

Yes, I don't know where I'm going to migrate to. This is why property
affects only how source saves state on outgoing migration.

>
>>>> 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.