Bug 855018 - Add "Disabled" state to "Memory Sharing: " in host information
Add "Disabled" state to "Memory Sharing: " in host information
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Einav Cohen
Pavel Stehlik
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-09-06 10:12 EDT by David Jaša
Modified: 2016-02-10 15:14 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-03 06:42:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-09-06 10:12:48 EDT
Description of problem:
Add "Disabled" state to "Memory Sharing: " in host information.

current RHEV-M doesn't distinguish between two effective states: ksm-based memory-sharing:
a) enabled but not active on the host
b) disabled so it won't kick in even in case of memory crunch

Version-Release number of selected component (if applicable):
RHEV-M 3.0.5

How reproducible:

Steps to Reproduce:
0. have a host with low RAM usage (under 80 %)
1. enable/disable "ksm" and "ksmtuned" services on the host: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-KSM.html
2. watch Hosts - Host - General - Memory Page Sharing value
Actual results:
in both cases, "Inactive" is reported

Expected results:
if the ksm* host services are disabled, RHEV-M should report value as "Disabled"

Additional info:
this makes some ksm-related debugging harder than necessary.
Comment 1 David Jaša 2012-09-06 10:13:25 EDT
see also bug 854018 and bug 854027 for background info.
Comment 2 Yaniv Kaul 2012-09-06 10:23:42 EDT
Added 'futurefeature'. Currently, we don't have such state.
It might be a good idea to have such a state - where we don't let KSM kick in at all (probably like 100% over-commit, but more explicit).
The relate bugs are bugs indeed, and should be handled regardless.
Comment 3 David Jaša 2012-09-06 13:23:45 EDT
Related documentation bug: bug 855103.
Comment 5 Dan Kenigsberg 2012-09-06 18:24:10 EDT
David, would you explain why we should expose this subtlety to the end user? In my opinion it should be written in vdsm logs to make bugs like bug 854027 a bit clearer.
Comment 6 David Jaša 2012-09-10 05:09:22 EDT
(In reply to comment #5)
> David, would you explain why we should expose this subtlety to the end user?

Because current set of indications does not give administrator any reliable clue in the webadmin that KSM will kick in should it be needed.

You could actually remove this field altogether without any loss of information because it's duplicate with zero/non-zero number in "Shared Memory". Changing this field meaning to just Disabled/Enabled would mean a tremendous boost in information value.
Comment 8 Doron Fediuck 2013-01-03 06:42:53 EST
currently indeed we have no indication for ksm state.
Going forward ksm will be controlled by mom along with other
tools, such as the memory balloon device.

So this is going to be completely changed, as mom will get
its policy from the engine which will complete these gaps
and more.

Baring in mind that the default ksm behavior is now enabled
(as Bug 854027 is fixed), and in light of the coming changes,
I see no reason to change VDSM API for something which will
become unusable soon.
Comment 9 Anand Nande 2013-01-21 04:28:53 EST

Any time-frame for M.O.M to be available in RHEV?

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