Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/27/2010 10:33 AM, Daniel P. Berrange wrote:
> On Fri, Aug 27, 2010 at 09:59:55AM -0500, Anthony Liguori wrote:
>    
>> On 08/27/2010 09:15 AM, Luiz Capitulino wrote:
>>      
>>> I wondered if we could drop it for now to make it right in 0.14, but I
>>> believe it's already part of the user monitor for some time and libvirt
>>> uses the stats, right?
>>>
>>> I think we need testing/unstable namespace in QMP, where commands can be
>>> tested for while so that we reduce the risk of nasty surprises like this
>>> one.
>>>
>>>        
>> It's trying to plug a sieve with a band-aid.  It's certainly an
>> "improvement" but it's of question utility looking at the bigger picture.
>>
>> Balloon is a perfect example of where what we really need to do is build
>> interface interfaces that make sense, and then expose them in QMP.
>>
>> What's a reasonable C-level API to query statistics that potentially may
>> never return?  Building in a timeout is something of a crappy API
>> because it puts policy deep in the API that is trivial to implement
>> elsewhere.  What you'd probably do is something like:
>>
>> BalloonStatsRequest *query_guest_balloon_stats(CompletionCallback *cb,
>> void *opaque);
>> int cancel_guest_balloon_stats(BalloonStatsRequest *req);
>> void release_guest_balloon_stats(BalloonStatsRequest *req);
>>      
> IMHO this is flawed because it does not allow you to fetch the
> balloon stats independantly of asking the guest OS to refresh
> them. So if the guest dies, it is not possible to ask QEMU
> what the last known stats were.
>    

The "last known" stats could be totally meaningless as they could be 
from 3 hours ago and there may have been a full reboot into a different 
OS since then.

Whether a "last known" stat is useful is a policy decision and belongs 
in the management tooling.

> Although the current guest driver implementation requires the
> host to request an update before the guest will refresh stats,
> in theory someone could provide a guest driver impl thta does
> a periodic push to the host without requiring a request.
>
> Thus for a fully generalized access mechanism you need two
> APIs and one event
>
>   - API to request guest balloon stats update
>   - API to get current known balloon stats
>    

Current known balloon stats is not meaningful within qemu.

>   - Event to notify client of a balloon stats update
>
> And for the non-stats related balloon level we need
>
>   - Event to notify client of balloon level change
>    

An alternative API would avoid a 1-1 relationship between requests and 
responses.   That would mean:

void balloon_set_target(BalloonInterface *b, uint64_t value);
uint64_t balloon_get_STAT_NAME(BalloonInterface *b);

void balloon_request_update(BalloonInterface *b);

void balloon_add_stat_change_notifier(BalloonInterface *b, StatNotifer 
*notifer, uint64_t mask);
void balloon_del_stat_change_notifier(BalloonInterface *b, StatNotifier 
*notifier);

This API allows you to set and get individual stats.  Because there are 
individual getters/setters, it provides a better backwards/future 
compatibility and is pretty discoverable.  It offers no real indication 
of the age of the stat.  It's unclear to me if that's a good or bad thing.

balloon_request_update() requests that a guest update it's status but 
there's no specific guarantees in the interface.  A mask might prove 
valuable here.

Then there's an interface to register notifications of when the 
statistics are updated.  I think this probably would cover most use cases.

A main difference between this API is that the API guarantees absolutely 
no "freshness" to the statistics.  It provides an interface to freshen 
them but provides no guarantees about when that will happen and even if 
it will happen.

Regards,

Anthony Liguori

> Even if the API to request a guest balloon stats update is fully async
> and cancellable, you still need the event to notify client of the
> balloon stats update, because in a multiple monitor scenario the
> client wanting notification may be different to the client requesting
> the refresh.
>
> Regards,
> Daniel
>