On Thu, Dec 03, 2020 at 12:16:24PM +0000, Daniel P. Berrangé wrote: > On Thu, Dec 03, 2020 at 07:11:17AM -0500, Michael S. Tsirkin wrote: > > On Thu, Dec 03, 2020 at 11:43:41AM +0000, Dr. David Alan Gilbert wrote: > > > Another way to solve this would be to remove the unplugging from the > > > migration layer and leave it as a problem for the management layer to do > > > the unplug. > > > > Daniel described the problem with modular management tools which expect > > pausing or slowing down guest to cause migration to converge. > > > > Point is, it actually *will* make it converge but only if you > > pause it after unplug. > > > > As it is, these tools fundamentally can not handle failover > > requiring guest cooperation. Moving code between layers won't help. > > Introducing failure modes as this patch does won't help either > > especially since Daniel wrote there are countless tools like this. > > We just break them all but have no resources to fix them, > > this does not help at all. > > > > We can just leave the situation as is. > > > > Or if we do want to be nice to these tools, how about we > > unpause the guest until unplug, then pause it again? > > This actually addresses the problem instead of > > shifting the blame, does it not? > > This is a very bad idea because it changes the execution status of the > guest behind the apps/admins back, and that cannot be assumed to be a > safe thing todo. > > Regards, > Daniel
My question is this: management gets an error since guest was paused presumably by someone (admin?) outside its control. How does it know when it is unpaused? > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|