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: always 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 3. 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.
see also bug 854018 and bug 854027 for background info.
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.
Related documentation bug: bug 855103.
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.
(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.
David, 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.
Doron, Any time-frame for M.O.M to be available in RHEV?