From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEkY-0008Pa-Ax for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:50:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ScEkV-00060o-M2 for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:50:05 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:38046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ScEkV-0005yR-GJ for qemu-devel@nongnu.org; Wed, 06 Jun 2012 07:50:03 -0400 Received: by dadv2 with SMTP id v2so9420130dad.4 for ; Wed, 06 Jun 2012 04:50:01 -0700 (PDT) Message-ID: <4FCF43E2.5030508@codemonkey.ws> Date: Wed, 06 Jun 2012 19:49:54 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <1338875386-21051-1-git-send-email-yhalperi@redhat.com> <4FCDF49E.6090006@codemonkey.ws> <4FCE067E.5030903@redhat.com> <4FCF1E70.3030703@redhat.com> <4FCF214D.8060001@codemonkey.ws> <20120606105447.GF16572@garlic.tlv.redhat.com> <4FCF3988.5020107@codemonkey.ws> <20120606112756.GG16572@garlic.tlv.redhat.com> In-Reply-To: <20120606112756.GG16572@garlic.tlv.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yonit Halperin , Gerd Hoffmann , aliguori@us.ibm.com, qemu-devel@nongnu.org On 06/06/2012 07:27 PM, Alon Levy wrote: >>> If there is an active VNC client >>> then it is there as a result of a user choosing to use it, so it should >>> be treated as part of the user experience and not as something external. >>> The experience from ignoring this and choosing to treat the remote >>> console as an unrelated part is bound to be suboptimal. >> >> Guest migration affects correctness! >> >> If the Spice client is slow (even due to network lag) in responding to your >> flush message, you will disrupt the guest and potentially drop network >> connections and/or cause lockup detectors to trigger. >> > > OK, you think any timeout here would be too large. What would it's value be? Migration is convergent and our downtime estimate is just that--an estimate. It's literally always a crap-shoot as to whether the actual migration will complete fast enough. What do you propose the timeout to be? 1us? Can you even do a round trip to a client in 1us? 50us? I still question whether a round trip is feasible in that time period and you've blown away the default 30us time anyway. Even 1us would be too much though. Regards, Anthony Liguori