On Wed, 12 Dec 2012 13:45:54 +
Dietmar Maurer wrote:
> > > Btw, do you know a qmp call which returns the memory assigned to the
> > > VM (the value qemu is started with (-m megs))?
> >
> > No, we only have info/query- balloon. I was also thinking about this the
> > other day.
>
> Can we add
> > Btw, do you know a qmp call which returns the memory assigned to the
> > VM (the value qemu is started with (-m megs))?
>
> No, we only have info/query- balloon. I was also thinking about this the
> other day.
Can we add an additional property: "stat-max-memory"?
Or add 'max_mem' property to
On Wed, 12 Dec 2012 13:36:20 +
Dietmar Maurer wrote:
> > > The following patch seems to work for me:
> >
> > Yeah, that's what I'll do and the doc has to be updated too.
>
> Btw, do you know a qmp call which returns the memory assigned to the VM
> (the value qemu is started with (-m megs))?
> > The following patch seems to work for me:
>
> Yeah, that's what I'll do and the doc has to be updated too.
Btw, do you know a qmp call which returns the memory assigned to the VM
(the value qemu is started with (-m megs))?
On Wed, 12 Dec 2012 13:17:15 +
Dietmar Maurer wrote:
> > > > > Why don't we raise the error when we query the values?
>
> You already raise an error here, so that works out of the box:
>
> if (s->stats[i] == -1) {
> error_setg(errp,
> "timer hasn't been enabled or gu
> > > > Why don't we raise the error when we query the values?
You already raise an error here, so that works out of the box:
if (s->stats[i] == -1) {
error_setg(errp,
"timer hasn't been enabled or guest doesn't support '%s'", name);
> > >
> > > Hmm, that's a good idea.
>
> And personally, I think just having a stale value for stats-last-update is
> sufficient for error checking, but we can squirrel away an error in a
> stats-last-
> error field if we want something more descriptive for clients, and just wipe
> it
> out on the next successful update. Not sure whet
On Tue, Dec 11, 2012 at 04:28:40PM -0200, Luiz Capitulino wrote:
> On Tue, 11 Dec 2012 11:38:08 -0600
> mdroth wrote:
>
> > On Tue, Dec 11, 2012 at 03:14:02PM +, Dietmar Maurer wrote:
> > > > > > I'm not sure I like this for two reasons. First, there will be cases
> > > > > > where the user d
On Tue, 11 Dec 2012 19:39:40 +
Dietmar Maurer wrote:
> > > > but it would silently fail if the feature is never negotiated (as
> > > > you said above).
> > >
> > > Why don't we raise the error when we query the values?
> >
> > Hmm, that's a good idea.
> >
> > Only small nit is that, today o
> > > but it would silently fail if the feature is never negotiated (as
> > > you said above).
> >
> > Why don't we raise the error when we query the values?
>
> Hmm, that's a good idea.
>
> Only small nit is that, today old stats will remain available to be queried
> even
> if you disable the t
On Tue, 11 Dec 2012 19:07:48 +
Dietmar Maurer wrote:
> > I could move the check for the stats feature bit from the function that
> > enables polling to the timer callback. This would solve Dietmar's use-case,
>
> that would be great.
>
> > but it would silently fail if the feature is never
> I could move the check for the stats feature bit from the function that
> enables polling to the timer callback. This would solve Dietmar's use-case,
that would be great.
> but it would silently fail if the feature is never negotiated (as you said
> above).
Why don't we raise the error when we
On Tue, 11 Dec 2012 11:38:08 -0600
mdroth wrote:
> On Tue, Dec 11, 2012 at 03:14:02PM +, Dietmar Maurer wrote:
> > > > > I'm not sure I like this for two reasons. First, there will be cases
> > > > > where the user doesn't want this to be enabled. Second, we'll be
> > > > > forcing an interva
On Tue, 11 Dec 2012 16:28:40 -0200
Luiz Capitulino wrote:
> On Tue, 11 Dec 2012 11:38:08 -0600
> mdroth wrote:
>
> > On Tue, Dec 11, 2012 at 03:14:02PM +, Dietmar Maurer wrote:
> > > > > > I'm not sure I like this for two reasons. First, there will be cases
> > > > > > where the user doesn'
On Tue, Dec 11, 2012 at 03:14:02PM +, Dietmar Maurer wrote:
> > > > I'm not sure I like this for two reasons. First, there will be cases
> > > > where the user doesn't want this to be enabled. Second, we'll be
> > > > forcing an interval on users.
> > >
> > > So when should we set the stats-pol
> > > I'm not sure I like this for two reasons. First, there will be cases
> > > where the user doesn't want this to be enabled. Second, we'll be
> > > forcing an interval on users.
> >
> > So when should we set the stats-polling-interval? I first thought I
> > simply set that at VM start, but that
On Tue, 11 Dec 2012 12:29:01 +
Dietmar Maurer wrote:
> > > Can't we enable stat queries by default (10s interval),
> >
> > I'm not sure I like this for two reasons. First, there will be cases where
> > the
> > user doesn't want this to be enabled. Second, we'll be forcing an interval
> > o
> > Can't we enable stat queries by default (10s interval),
>
> I'm not sure I like this for two reasons. First, there will be cases where the
> user doesn't want this to be enabled. Second, we'll be forcing an interval on
> users.
So when should we set the stats-polling-interval? I first thought
On Tue, 11 Dec 2012 12:05:32 +
Dietmar Maurer wrote:
> > > and simply return all stats with one API call (query-ballon)?
> >
> > We can't use query-balloon because this changes query-balloon from
> > synchronous to asynchronous, and this is an incompatible change.
>
> Why don't we simply ca
> > Can't we enable stat queries by default (10s interval),
>
> I'm not sure I like this for two reasons. First, there will be cases where the
> user doesn't want this to be enabled. Second, we'll be forcing an interval on
> users.
OK.
> > and simply return all stats with one API call (query-ba
aligu...@us.ibm.com; mdr...@linux.vnet.ibm.com; a...@us.ibm.com
> > Subject: [Qemu-devel] [PATCH 0/3] re-enable balloon stats
> >
> > This new try to re-enable the virtio-balloon driver stats uses QOM
> > properties
> > via a polling mechanism as suggested by Anthony h
; [mailto:qemu-devel-bounces+dietmar=proxmox@nongnu.org] On
> Behalf Of Luiz Capitulino
> Sent: Montag, 10. Dezember 2012 20:36
> To: qemu-devel@nongnu.org
> Cc: aligu...@us.ibm.com; mdr...@linux.vnet.ibm.com; a...@us.ibm.com
> Subject: [Qemu-devel] [PATCH 0/3] re-enable balloon
This new try to re-enable the virtio-balloon driver stats uses QOM properties
via a polling mechanism as suggested by Anthony here:
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02390.html
o Changes from the rfc
- avoid balloon_stats_poll_cb() and virtio_balloon_handle_output()
ru
23 matches
Mail list logo
