* Paolo Bonzini (pbonz...@redhat.com) wrote: > Il 07/07/2014 16:02, Dr. David Alan Gilbert ha scritto: > >>> Could you have instead a "migrate_start_postcopy" command, and leave the > >>> policy to management instead? > >Hmm; yes that is probably possible - although with the > >migration_set_parameter > >configuration you get the best of both worlds: > > 1) You can set the parameter to say a few seconds and let QEMU handle it > > 2) You can set the parameter really large, but (I need to check) you could > > drop the parameter later and then cause it to kick in. > > > >I also did it this way because it was similar to the way the auto-throttling > >mechanism. > > Auto-throttling doesn't let you configure when it kicks in (it doesn't even > need support from the destination side). For postcopy you would still have > a capability, like auto-throttling, just not the argument.
But auto-throttling is handled automatically by qemu rather than management; and it seems right that it should be a configurable threshold. > The reason why I prefer a manual step from management, is because postcopy > is a one-way street. Suppose a newer version of management software has > started migration with postcopy configured, and then an older version is > started. It is probably an invalid thing to do, but the confusion in the > older version could be fatal and it's nice if there's an easy way to prevent > it. Hmm, the way the setup at the moment is setup the new-version would have had to start the VMs down the one way street, I'm not sure what the old software would do bad to it. Having said that, I can see some advantages - in particular knowing when it's safe to cancel. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
