From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBJuf-0000ip-J8 for qemu-devel@nongnu.org; Wed, 14 Jan 2015 04:06:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBJua-0005Hr-LT for qemu-devel@nongnu.org; Wed, 14 Jan 2015 04:06:53 -0500 Received: from mail-wi0-x232.google.com ([2a00:1450:400c:c05::232]:33046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBJua-0005HY-EF for qemu-devel@nongnu.org; Wed, 14 Jan 2015 04:06:48 -0500 Received: by mail-wi0-f178.google.com with SMTP id z2so3818812wiv.5 for ; Wed, 14 Jan 2015 01:06:47 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54B631A4.7090403@redhat.com> Date: Wed, 14 Jan 2015 10:06:44 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <201501130948157439113@sangfor.com.cn>, <201501131002532239699@sangfor.com.cn>, <201501141041046517018@sangfor.com.cn> <201501141558472151450@sangfor.com.cn> In-Reply-To: <201501141558472151450@sangfor.com.cn> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] question about live migration with storage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Haoyu , qemu-devel Cc: Gleb Natapov , Stefan Hajnoczi On 14/01/2015 08:58, Zhang Haoyu wrote: >> 2) Finer-grain control the parameters of block migration (dirty bitmap >> granularity). >> >> 3) Block and RAM migration do not share the same socket and thus can >> more easily be parallelized. >> > But, because of the parallelization, how to calculate the progress? You can use "query-block-jobs". > BTW, the traditional iterative mechanism is buggy-implemented? > e.g., some bugs which are very difficult to fixed, or something? There are no bugs that corrupt data. It's simply less flexible. Regarding parallelization, the problems happen especially if you disable migration bandwidth limits. Then you'll see large chunks of RAM and large chunks of block device data being sent. This is a problem for convergence in some workloads. Instead, with NBD-based storage migration everything happens in parallel, and TCP makes sure that bandwidth is split between the sockets. If you have a migration bandwidth limit, NBD-based storage migration will use a separate bandwidth limit for each disk and for RAM. Thus network usage is less predictable than with block-migration.c. On the other hand, storage migration uses a lot of network so it's usually more likely that you do not have migration bandwidth limits. Paolo > Thanks, > Zhang Haoyu >> Note that 1-2 are not yet supported by libvirt as far as I remember. >> >> Paolo > > >