From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiP1H-0003Ah-Ey for qemu-devel@nongnu.org; Wed, 04 Jan 2012 06:28:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiP1F-00013N-VJ for qemu-devel@nongnu.org; Wed, 04 Jan 2012 06:28:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiP1F-000138-RE for qemu-devel@nongnu.org; Wed, 04 Jan 2012 06:28:33 -0500 Message-ID: <4F0437DA.8080600@redhat.com> Date: Wed, 04 Jan 2012 12:28:26 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <032f49425e7284e9f050064cd30855bb@mail.dlh.net> <4F03AD98.7020700@linux.vnet.ibm.com> <4F042FA1.5090909@dlh.net> <4F04326F.8080808@redhat.com> <4F043689.2000604@dlh.net> In-Reply-To: <4F043689.2000604@dlh.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Shu Ming , qemu-devel@nongnu.org, kvm@vger.kernel.org On 01/04/2012 12:22 PM, Peter Lieven wrote: >> There were patches to move RAM migration to a separate thread. The >> problem is that they broke block migration. >> >> However, asynchronous NBD is in and streaming will follow suit soon. >> As soon as we have those two features, we might as well remove the >> block migration code. > > ok, so its a matter of time, right? Well, there are other solutions of varying complexity in the works, that might remove the need for the migration thread or at least reduce the problem (post-copy migration, XBRLE, vectorized hot loops). But yes, we are aware of the problem and we should solve it in one way or the other. > would it make sense to patch ram_save_block to always process a full ram > block? If I understand the proposal, then migration would hardly be live anymore. The biggest RAM block in a 32G machine is, well, 32G big. Other RAM blocks are for the VRAM and for some BIOS data, but they are very small in proportion. > - in stage 3 the vm is stopped, right? so there can't be any more dirty > blocks after scanning the whole memory once? No, stage 3 is entered when there are very few dirty memory pages remaining. This may happen after scanning the whole memory many times. It may even never happen if migration does not converge because of low bandwidth or too strict downtime requirements. Paolo