* Eric Blake (ebl...@redhat.com) wrote: > On 07/10/2014 05:29 AM, Dr. David Alan Gilbert wrote: > > * 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. > >> > >> 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. > > > > Actually the 'migrate_start_postcopy' idea is growing on me; Eric is that > > also your preferred way of doing it? > > > > If we did this I'd: > > 1) Remove the migration_set_parameter code I added > > 2) and the x-postcopy_ram_start_time parameter > > 3) Add a new command migrate_start_postcopy that just sets a flag > > which is tested in the same place as I currently check the timeout. > > If it's issued after a migration has finished it doesn't fail because > > that would be racy. If issued before a migration starts that's OK > > as long as postcopy is enabled and means to start postcopy mode > > immediately. > > So to make sure I understand, the idea is that the management starts > migration as normal, then after enough time has elapsed, issues a > migrate_start_postcopy to tell qemu that it is okay to switch to > postcopy at the next convenient opportunity? Is there any need for an > event telling libvirt that enough pre-copy has occurred to make a > postcopy worthwhile? And of course, I _still_ want an event for when > normal precopy migration is ready (instead of the current solution of > libvirt having to poll to track progress). > > But in answer to your question, yes, it sounds like adding a new command > (actually, per QMP conventions it should probably be > migrate-start-postcopy with dashes instead of underscore) for management > to determine if/when to allow postcopy to kick in seems okay.
That's implemented in the v2 I just posted. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
