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

[Anthony Liguori]

On 06/06/2012 06:54 PM, Alon Levy wrote:
> On Wed, Jun 06, 2012 at 05:22:21PM +0800, Anthony Liguori wrote:
> > On 06/06/2012 05:10 PM, Yonit Halperin wrote:
> > Spice client migration has nothing to do with guest migration.  Trying to
>
> I don't understand this POV. If it were a VNC connection instead of a
> Spice one would it make a difference?

Of course, I would say yes if it was VNC.  Because the only possibly way I could 
disagree with something Spice related is because I'm biased against it.

Give me the benefit of the doubt at least.  More importantly, try to stop and 
think about what I'm saying before you assume the anti-Spice brigade is coming 
in to rain on your parade.

> 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.

Migrating the Spice client is a UI feature.  It has absolutely no affect no the 
workloads that are running in the guest.

Impacting migration *correctness* in order to support a UI feature is 
unacceptable especially when there are ways to achieve the same results without 
having any impact on correctness.

We have had a simple rule with migration in QEMU.  Nothing gets to impact 
downtime with migration.  No device gets magic hooks or anything like that.  Go 
read the TPM threads if you want to see another example of this.

Regards,

Anthony Liguori