[et-mgmt-tools] [PATCH/RFC]: virt-manager: display disk and network I/O statistics

[Guido Günther]

On Fri, Oct 03, 2008 at 04:19:39PM -0400, Cole Robinson wrote:
> I would say let that come later. We could either add some way
> to make the graphs scalable on demand (if traffic exceeds X KB/sec,
> the scale suddenly grows).
I currently autoscale the graph to the maximum read or write transfer
rate measured. This can be improved but has little point as long as the
sparcline widgets don't put any units on the vertical axis.

> Other way would be to add an option to 'Preferences', which really
> needs to be broken out into sections. There's a whole bunch of prefs
> we could add for stats, like disabling polling outright for the
> different data types (since a connection with a ton of VMs will most
> likely have scaling issues).
Having "autoscaling" on by default and being able to set e.g.
100MBytes/s would probably be best. Disabling polling would certainly be
nice too.

> >  * the GtkSparkline graphs display input only. I'd be nice to have in
> >    and out in one graph in different colors
> 
> Fixing up these graphs to be prettier and more useful is high on
> my list. I'm unfortunately not too savvy on custom widgets so there
> will be a bit of overhead. gnome-system-monitor has some beautiful
> graph widgets, though they are written in C++.
The patch series adds some minor improvements like multiple lines in a
widget and color. Maybe you can work on from that.

> 
> >  * the overview looks a bit boring, should we add sparklines there too,
> >    like for cpu usage?
> 
> Yes, I would say duplicating the spark lines like you have in the
> details section would be sufficient. Maybe just change the heading
> in the manager to be 'Disk Activity' and 'Network Activity', and
> if the user wants specific data rate numbers they can look at the
> individual vm details.
I've added a combined read+write sparcline to each column. However I
don't bother to add this all up for the domain since there's really
little to read out of it. This can certainly be added.

[..snip..] 
> I haven't tested this, but I don't think we should rename the
> gconf field names. There isn't really any benefit, and instead
> it will just leave dead fields kicking around.
O.k., I backed that out.

> Changing the description as needed shouldn't be a problem
> though.
> 
> The rest of the code looks fine. With the above change and
> the sparklines in the manager window I'd be glad to take it
> in.
I've split things up a little, for easier review.
 -- Guido