Bug 475856 - VM performance numbers should be relative to the guest, not the host
Summary: VM performance numbers should be relative to the guest, not the host
Keywords:
Status: CLOSED DUPLICATE of bug 629754
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-10 20:09 UTC by Daniel Bass
Modified: 2011-07-12 13:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-12 13:58:47 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Bass 2008-12-10 20:09:34 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4

Imagine a host with 4 CPUs and 4 GB of RAM. Imagine a guest with one CPU and 512 MB of RAM. If it maxes out its resources, it'll show as using 25% CPU and 12.5% of RAM. This is relative to the host, but that's not really meaningful when you're looking at the guest. Instead, those numbers should be relative to the guest, so it'd be 100% and 100%. As a special case, when the startup and maximum RAM are the same, it should just show the amount (512 MB) because a constant 100% isn't really useful.

The numbers on the main virt-manager screen (as opposed to on the detail of a specific host) are harder to define. I can make a case for both sets of numbers. I would argue that both should be available (in separate columns), but the relative-to-guest columns should be hidden by default.

Reproducible: Always

Comment 1 Cole Robinson 2011-07-12 13:58:47 UTC
The memory issues are gone in recent virt-manager, since we don't really show a graph for it anymore (since historically we haven't had _actual_ memory usage statistics from inside the guest, so it wasn't all that useful to show a graph here).

The CPU issue is tracked in other bugs, so closing as a dup

*** This bug has been marked as a duplicate of bug 629754 ***


Note You need to log in before you can comment on or make changes to this bug.