From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5CXh-0001UX-Uh for qemu-devel@nongnu.org; Thu, 10 Jul 2014 07:29:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5CXa-00056k-Cp for qemu-devel@nongnu.org; Thu, 10 Jul 2014 07:29:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5CXa-00056Y-2Q for qemu-devel@nongnu.org; Thu, 10 Jul 2014 07:29:30 -0400 Date: Thu, 10 Jul 2014 12:29:22 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20140710112921.GG2627@work-vm> References: <1404495717-4239-1-git-send-email-dgilbert@redhat.com> <53B7D36B.4050800@redhat.com> <20140707140229.GA3443@work-vm> <53BAB03B.5000308@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53BAB03B.5000308@redhat.com> Subject: Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , eblake@redhat.com Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, lilei@linux.vnet.ibm.com * Paolo Bonzini (pbonzini@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. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK