* Markus Armbruster (arm...@redhat.com) wrote: > We appear to use migration blockers in two ways: > > (1) Prevent migration for an indefinite time, typically due to use of > some feature that isn't compatible with migration. > > (2) Delay migration for a short time. > > Option -only-migrate is designed for (1). It interferes with (2). > > Example for (1): device "x-pci-proxy-dev" doesn't support migration. It > adds a migration blocker on realize, and deletes it on unrealize. With > -only-migrate, device realize fails. Works as designed. > > Example for (2): spapr_mce_req_event() makes an effort to prevent > migration degrate the reporting of FWNMIs. It adds a migration blocker > when it receives one, and deletes it when it's done handling it. This > is a best effort; if migration is already in progress by the time FWNMI > is received, we simply carry on, and that's okay. However, option > -only-migrate sabotages the best effort entirely.
That's interesting; it's the first time I've heard of anyone using it as 'best effort'. I've always regarded blockers as blocking. > While this isn't exactly terrible, it may be a weakness in our thinking > and our infrastructure. I'm bringing it up so the people in charge are > aware :) Thanks. It almost feels like they need a way to temporarily hold off 'completion' of migratio - i.e. the phase where we stop the CPU and write the device data; mind you you'd also probably want it to stop cold-migrates/snapshots? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
