[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message
Date: Fri, 27 Aug 2010 10:45:12 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

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

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.


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.


reply via email to

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