From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Towxv-0004n9-P1 for qemu-devel@nongnu.org; Sat, 29 Dec 2012 09:00:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Towxu-00012T-Tp for qemu-devel@nongnu.org; Sat, 29 Dec 2012 09:00:43 -0500 Received: from mail-wi0-f173.google.com ([209.85.212.173]:35721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Towxu-00012P-9g for qemu-devel@nongnu.org; Sat, 29 Dec 2012 09:00:42 -0500 Received: by mail-wi0-f173.google.com with SMTP id hn17so8656336wib.12 for ; Sat, 29 Dec 2012 06:00:41 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50DEF785.7030706@redhat.com> Date: Sat, 29 Dec 2012 15:00:37 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <50DCC3AF.7020802@profihost.ag> <50DDDCB2.1060403@redhat.com> <50DDED1C.2020208@profihost.ag> In-Reply-To: <50DDED1C.2020208@profihost.ag> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] setting migrate_downtime results in halted vm (qemu 1.3) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Priebe Cc: qemu-devel , Alexandre DERUMIER , Juan Quintela Il 28/12/2012 20:03, Stefan Priebe ha scritto: > Hi Paolo, > > Am 28.12.2012 18:53, schrieb Paolo Bonzini: >> Il 28/12/2012 08:05, Alexandre DERUMIER ha scritto: >>> Hi list, >>> After discuss with Stefan Yesterday here some more info: >>> >>> (this is for stable qemu 1.3, it was working fine with qemu 1.2) >>> >>> The problem seem that whesettings a migrate_set_downtime to 1sec, >>> >>> the transfert of the vm seem to send all the memory of the vm in 1 >>> step, and not by increment. >>> So the downtime is really huge , 90000ms for 1GB memory. >> >> Can you try commit bde54c08b4854aceee3dee25121a2b835cb81166? > > i cherry picked that one on top of 1.3 sadly it does not help. VM halts, > monitor socket is no longer available kvm process is running with 100% > CPU on source side. Can you please test master and, if it works, bisect it in reverse? (That is, mark "bad" if it works, "good" if it fails). Paolo