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

[Anton Kuchin]

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.

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