From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baddf-00027Y-W6 for qemu-devel@nongnu.org; Fri, 19 Aug 2016 02:50:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baddc-0003py-QU for qemu-devel@nongnu.org; Fri, 19 Aug 2016 02:50:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baddc-0003pq-KX for qemu-devel@nongnu.org; Fri, 19 Aug 2016 02:50:44 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B28E38553D for ; Fri, 19 Aug 2016 06:50:42 +0000 (UTC) Date: Fri, 19 Aug 2016 14:50:37 +0800 From: Peter Xu Message-ID: <20160819065037.GA32302@pxdev.xzpeter.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Qemu-devel] Question with migrate_set_speed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Devel Mailing List Cc: "Dr. David Alan Gilbert" , "Daniel P. Berrange" , quintela@redhat.com, Amit Shah , Peter Xu Hi, I am playing with live migration and got one question about live migration set_speed. Now we can use migrate_set_speed to configure the threshold during migration (it should be only used for precopy, so let's assume the migration is a precopy case). However I feel like this single parameter cannot describe the process very clearly. The problem is, we use this "speed" value as both: 1. transfer threshold, to make sure migration stream is relatively constant and under control 2. value to estimate "when we should stop the vm and start counting downtime" For (1), we want a customized value that best suites our network environment. E.g., if we have other critical network payloads, we can set this to a very small number, so the migration stream will be very small. For (2), it should be nothing else but possibly the network bandwidth that the system can provide on the migration link. We can set_speed to a very small value to avoid disturbing other network services, that's good. However using the same value to estimate "when to stop" seems odd, since this value can be far away from the real network speed (when we are transfering the last bits in precopy, we should be using the max network speed all the time, which actually is not affected by the threshold value). IMHO, it'll be clearer if these are two different tunables, e.g., not sure whether it'll be cool to add another tunable "set_speed_max", to configure the speed for the (2) case (when vm is stopped on source). If so, it'll be clearer, and also bring another benefit: users can have full control of the last migration phase as well, in case they don't want to suffer from a network fluctuation for each ends of migration. Still haven't thought further. Just throw this question out. Thanks, -- peterx