Bug 475856 - VM performance numbers should be relative to the guest, not the host
VM performance numbers should be relative to the guest, not the host
Status: CLOSED DUPLICATE of bug 629754
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Cole Robinson
Depends On:
  Show dependency treegraph
Reported: 2008-12-10 15:09 EST by Daniel Bass
Modified: 2011-07-12 09:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-07-12 09:58:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Bass 2008-12-10 15:09:34 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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 09:58:47 EDT
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.