From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4A1M-0007IH-7n for qemu-devel@nongnu.org; Mon, 07 Jul 2014 10:36:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X4A1E-0002yu-PR for qemu-devel@nongnu.org; Mon, 07 Jul 2014 10:35:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4A1E-0002y3-EQ for qemu-devel@nongnu.org; Mon, 07 Jul 2014 10:35:48 -0400 Message-ID: <53BAB03B.5000308@redhat.com> Date: Mon, 07 Jul 2014 16:35:39 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1404495717-4239-1-git-send-email-dgilbert@redhat.com> <53B7D36B.4050800@redhat.com> <20140707140229.GA3443@work-vm> In-Reply-To: <20140707140229.GA3443@work-vm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/46] Postcopy implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, lilei@linux.vnet.ibm.com 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. Paolo