qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine is stopped
Date: Thu, 26 Aug 2010 09:57:48 -0300

On Thu, 26 Aug 2010 09:28:42 +0100
"Daniel P. Berrange" <address@hidden> wrote:

> On Thu, Aug 26, 2010 at 01:47:50PM +0530, Amit Shah wrote:
> > On (Thu) Aug 26 2010 [10:05:44], Paolo Bonzini wrote:
> > > On 08/26/2010 08:05 AM, Amit Shah wrote:
> > > >This is what I have currently. It would need some timer handling in
> > > >the save/load case as well, right?
> > > 
> > > When loading you won't have any pending "info balloon" command, so I
> > > think the timer need not be preserved across migration.
> > > 
> > > Also, 5 seconds for a stopped guest is actually a lot,
> > 
> > That's the problem; it's policy. Where and how to specify it?
> 
> It is unfortunate that this is policy, but we just have to accept
> that the current query-balloon command is a flawed design. IMHO
> we  should just hardcode the timeout at 5 seconds as you do (plus
> immediate return for paused guests). Then focus on adding new 
> monitor commands/events to deal with balloon query in a way 
> that doesn't require this kind of policy in QEMU, and deprecate 
> the existing query-balloon command.

Agreed, but it's not just that: we've never correctly specified how
commands that talk with the guest should behave.

  *brain dump warning*

We were talking about making all commands work as synchronous and
asynchronous. If we do that, then we'll need a 'global' timeout
for all synchronous commands. We could have a default value and a
command to set it.

 *brain dump warning ends*

I really don't know what to do 0.13. Probably the hard-coded timer is
the best solution we have, but I'm wondering if it's going to cause
problems in the near future, when we get proper asynchronous command
support.



reply via email to

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