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.