* Wei Yang (richardw.y...@linux.intel.com) wrote: > On Thu, Apr 25, 2019 at 05:55:15PM -0300, Daniel Henrique Barboza wrote: > > > > > >On 4/23/19 9:46 PM, Wei Yang wrote: > >> migration_is_blocked() is used in migrate_prepare() and > >> save_snapshot(), this is more proper to use this instead of > >> qemu_savevm_state_blocked() in qemu_loadvm_state(). > > > > > >migration_is_blocked() does an additional verification: > > > >"if (migration_blockers)" > > > >comparing to what was previously done in qemu_loadvm_state. > > > >I've checked what migration_blockers does and it is a GList used > >for callers to block the migration process. This is used via > >'migration_add_blocker', from migration.c. > > > >'migration_add_blocker' is called all over the place, most notably > >in _realize() functions and _open() functions from block. > > > >Thus, I am not sure if this change will impact the use of > >qemu_loadvm_state() from load_snapshot() (i.e. can load_snapshot > >be called with migration_blockers?). It's better to someone > >with a better understanding of this code to comment on that. > > > > Well, when you look into the source side of migration: > > qmp_migrate > migrate_prepare > migration_is_blocked > > This means if migration_is_blocked fails, the source will not start migration. > And it is the same as save_snapshot. > > From my understanding, when we load a vm, it should check the same > requirement.
I've been thinking about this, and I think I agree with Daniel on this. The 'migration_blockers' list tells you that something about the *current* state of a device means that it can't be migrated - e.g. a 9pfs with a mounted filesystem can't be migrated. If we're about to reload the state from a snapshot, then the saved snapshot's state must have been migratable, so that's OK. (Whether all the device code is actually OK about being reset in that state is a different question; but I think it should be). Dave > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
