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. Alternatively, we can hook into the feature negotiation path and defer the actual timer start until the required feature is negotiated, and disable it (temporarilly or permanently based on guest behavior) somewhere in the reset path). I'm not sure this will keep it from running during hibernate/sleep...maybe hook into runstate changes?