[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: Alon Levy
Subject: Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Date: Wed, 6 Jun 2012 14:27:56 +0300
User-agent: Mutt/1.5.21 (2011-07-01)

On Wed, Jun 06, 2012 at 07:05:44PM +0800, Anthony Liguori wrote:
> 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.

I stand corrected.

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

> 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

reply via email to

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