From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFWLg-00076s-HL for qemu-devel@nongnu.org; Tue, 01 Dec 2009 12:17:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFWLc-000743-Rj for qemu-devel@nongnu.org; Tue, 01 Dec 2009 12:17:12 -0500 Received: from [199.232.76.173] (port=47940 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFWLc-00073t-7g for qemu-devel@nongnu.org; Tue, 01 Dec 2009 12:17:08 -0500 Received: from goliath.siemens.de ([192.35.17.28]:20575) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFWLb-0000o3-PH for qemu-devel@nongnu.org; Tue, 01 Dec 2009 12:17:08 -0500 Message-ID: <4B154F8E.2060107@siemens.com> Date: Tue, 01 Dec 2009 18:17:02 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20091130172119.22889.28114.stgit@mchn012c.ww002.siemens.net> <20091130172121.22889.68041.stgit@mchn012c.ww002.siemens.net> <4B152621.9020108@siemens.com> <3A1DA18D-59C7-4DFC-8A65-36A350E1EF71@irisa.fr> In-Reply-To: <3A1DA18D-59C7-4DFC-8A65-36A350E1EF71@irisa.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH v2 22/23] block migration: Add support for restore progress reporting List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Riteau Cc: Anthony Liguori , "qemu-devel@nongnu.org" , Liran Schour Pierre Riteau wrote: > On 1 d=E9c. 2009, at 15:20, Jan Kiszka wrote: >=20 >> Inject progress report in percentage into the block live stream. This >> can be read out and displayed easily on restore. >=20 >=20 > I guess that this patch only reports percentage for the initial bulk co= py of the image. > I haven't tested this scenario, but the next phase, sending dirty block= s, can be quite long too if the guest does a lot of I/O. > Won't it give a wrong impression to the user when qemu says "Completed = 100%" but disk migration continues catching up for a while? I does give a wrong impression (as there is also a wrong behavior) ATM. But the plan is to update the number of pending blocks during the sync. Theoretically we could even go backwards with this progress value if (much) more blocks become dirty than we are able to write over a certain period. Effectively, the total disk sizes increases during the migration due to dirty blocks being added. Instead of carrying this updated number over to the receiving side, I want to let the sender do the calculation and only transfer the result inside the stream (as this is only about visualization). Jan PS: Think I just found the e1000 migration issue, which turned out to affect all NICs. --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux