[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change han

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Wed, 06 Jun 2012 19:49:54 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]