* Wei Yang (richardw.y...@linux.intel.com) wrote: > On Wed, May 15, 2019 at 02:38:27PM +0800, Wei Yang wrote: > >On Tue, May 14, 2019 at 04:18:14PM +0100, Dr. David Alan Gilbert wrote: > >>* Wei Yang (richardw.y...@linux.intel.com) wrote: > >>> > >>> 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. > >> > > > >The situation is on a vm with 'migration_blockers' still could reload from a > >snapshot. > > > >This sounds reasonable. Thanks :-) > > > > Well, this is still a little strange. The means source vm and destination vm > could have different configuration. Is this common?
It's not different configuration that I'm worried about here; but it's different runtime state. Items can get added/removed from migration_blockers dynamically depending on the behaviour of the guest; e.g. a device might only migratable in certain states. Dave > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
