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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 26 Aug 2010 09:28:42 +0100
"Daniel P. Berrange" <berrange@redhat.com> 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.