On Tue, 11 Dec 2012 16:28:40 -0200 Luiz Capitulino <lcapitul...@redhat.com> wrote:
> On Tue, 11 Dec 2012 11:38:08 -0600 > mdroth <mdr...@linux.vnet.ibm.com> wrote: > > > On Tue, Dec 11, 2012 at 03:14:02PM +0000, 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-polling-interval? I first thought I > > > > > simply set that at VM start, but that triggers an error: > > > > > > > > > > "guest doesn't support balloon stats" > > > > > > > > > > because the balloon driver is not loaded. > > > > > > > > Yes, it's required to have the balloon driver loaded. The stats are > > > > reported by > > > > it. > > > > > > That does not really answers my question. So you think the management > > > framework should start the VM, and then wait until the balloon driver is > > > loaded? That sound very clumsy to me. > > > > > > I mean, I just want to set the polling interval. Why does that need the > > > balloon drive loaded > > > inside the guest (polling is done by the host)? > > > > I agree. Should lack of a balloon module disable the timer > > completely, or just silently fail? Management can always reference > > stats-last-update to check that stats are being reported properly. -1 would > > mean driver was never loaded, longer update intervals might mean guest > > was rebooted/suspended/etc, but in both cases it makes sense that the > > timer still try to fetch stats, and the determination of what stats are > > valid/invalid be left to management. > > 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, > but it would silently fail if the feature is never negotiated (as you said > above). Btw, we could also add functionality to qemu-ga to list loaded modules.
