From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAgCl-0008D0-Bl for qemu-devel@nongnu.org; Mon, 12 Jan 2015 09:42:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAgCi-00070d-6H for qemu-devel@nongnu.org; Mon, 12 Jan 2015 09:42:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAgCh-00070V-Uk for qemu-devel@nongnu.org; Mon, 12 Jan 2015 09:42:52 -0500 Message-ID: <54B3DD65.7030200@redhat.com> Date: Mon, 12 Jan 2015 15:42:45 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1418307457-25996-1-git-send-email-vsementsov@parallels.com> <1418307457-25996-10-git-send-email-vsementsov@parallels.com> <54AF0662.7050303@redhat.com> <54B3D84A.8000207@parallels.com> In-Reply-To: <54B3D84A.8000207@parallels.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, stefanha@redhat.com On 12/01/2015 15:20, Vladimir Sementsov-Ogievskiy wrote: > > On 09.01.2015 01:36, Paolo Bonzini wrote: >> The bitmaps are transmitted many times in their entirety, but only the >> last copy actually means something. The others are lost. This means >> you should use the non-live interface (register_savevm). This will >> simplify the code a lot. > > But what if the dirty bitmap is really big? > > For example, for 5 Pb drive the bitmap with granularity 65536 will be of > 2 Gb size. So, shouldn't it be migrated iteratively for live migration? But your code is not attempting to do that. It is not attempting to track the dirtiness of the dirty bitmap, so to speak. For such a huge storage, in any case, I suspect the solution is to not use QEMU's live operations and, instead, operate at the storage level. Paolo