Bug 854027
Summary: | 3.1 - vdsm should start ksmtuned upon startup (if ksm/memory sharing is enabled on the cluster) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | David Jaša <djasa> |
Component: | vdsm | Assignee: | Laszlo Hornyak <lhornyak> |
Status: | CLOSED ERRATA | QA Contact: | Haim <hateya> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.3 | CC: | abaron, acathrow, bazulay, danken, dfediuck, iheim, ilvovsky, lhornyak, lnatapov, lpeer, sgrinber, thildred, yeylon, ykaul |
Target Milestone: | beta | Keywords: | Regression, ZStream |
Target Release: | 6.4 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | sla | ||
Fixed In Version: | vdsm-4.9.6-39.0 | Doc Type: | Bug Fix |
Doc Text: |
Previously, VDSM did not start the ksm and ksmtuned services when it started. This adversely impacted the Red Hat Enterprise Virtualization memory over-commitment features.
Now, VDSM automatically starts ksm and ksmtuned.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-04 19:09:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 782183 |
Description
David Jaša
2012-09-03 15:45:42 UTC
What was the memory state when you restarted VDSM ? over committed ? The VDSM has an internal thread that handles the ksm, and does the start and the stop of the service. It is not required to turn on the ksmtuned when the memory is not above the threshold (I think 80% of physical memory) ksm* services were not started even when the host was under memory crunch. The vdsm log contains lines like this from such moments: Thread-2303351::DEBUG::2012-08-31 10:48:17,157::utils::579::Storage.Misc.excCmd::(execCmd) '/usr/bin/sudo -n /sbin/service ksmtuned retune' (cwd None) Thread-2303351::DEBUG::2012-08-31 10:48:17,196::utils::579::Storage.Misc.excCmd::(execCmd) FAILED: <err> = ''; <rc> = 1 so i'd say that vdsm assumes that ksm is running but it actualy is not. (In reply to comment #4) > > so i'd say that vdsm assumes that ksm is running but it actualy is not. I think you are correct: we have ksm.start() function, but I do not see anyone calling it! well, also: is ksm service running? it seems to me the check in vdsm/ksm.py is not sufficient/correct. it checks /sys/kernel/mm/ksm/run and if it's 0 it starts both ksm and ksmtuned. But that file reports ksm's status only. I.e. you get 1(running) when ksm is started and ksmtuned stopped. Two more related bugs: bug 855018 (so that engine distinguishes ksm disabled and enabled-but-inactive states) and bug 855103 requesting pointer to KSM chapter from Cluster configuration chapter (that speaks about Cluster-level memory overocommit). (In reply to comment #5) > (In reply to comment #4) > > > > so i'd say that vdsm assumes that ksm is running but it actualy is not. > > I think you are correct: we have ksm.start() function, but I do not see > anyone calling it! Dan, if this is the case this is a regression and should be handled at a high priority, please mark it for RHEV 3.1 (In reply to comment #5) > (In reply to comment #4) > > > > so i'd say that vdsm assumes that ksm is running but it actualy is not. > > I think you are correct: we have ksm.start() function, but I do not see > anyone calling it! Perhaps I'm misreading it, but I see in ksm.py: if config.getboolean('ksm', 'ksm_monitor_thread'): pids = utils.execCmd([constants.EXT_PGREP, '-xf', 'ksmd'], raw=False, sudo=False)[1] if pids: self._pid = pids[0].strip() self.start() <--------------- else: self._cif.log.error('failed to find ksmd thread') I'm more concerned how the service got disabled in the first place, and why no one complained thus far. I fully understand it CAN be disabled, but so can many other services which will harm our functionality. $SUBJECT is confusing, so to make it clear; VDSM has no knowledge of cluster, RHEV-M and anything beyond the host level scope. So the fix should be simply to run ksmd and ksmtuned if not already running. And I share Kaul's concern on why ksm wasn't running by default. If ksm is not running by default it's a ksm bug. the start() function in ksm.py is not a member of KsmMonitorThread, it is not called by anyone and therefore the ksm monitor thread is not started Sorry, let me correct myself, the thread will be started but the functions that check if ksm is running and the functions that actually start ksm and ksmtuned are not invoked. Also, the ksmtuned and ksmd are handled as one thing, I mean if ksmd is up, it will not check ksmtuned, while it seems they can run independently from each other. merged upstream 10e3fdb756cf4b9d641df4f95cc82133ec8ce14c vdsm-4.9.6-43.0.el6_3.x86_64. ---------------------------- [root@purple-vds2 init.d]# service ksmtuned status ksmtuned (pid 27087) is running... [root@purple-vds2 init.d]# service ksmtuned stop Stopping ksmtuned: [ OK ] [root@purple-vds2 init.d]# service ksmtuned status ksmtuned is stopped [root@purple-vds2 init.d]# chkconfig --del ksmtuned [root@purple-vds2 init.d]# service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm stop [ OK ] vdsm: libvirt already configured for vdsm [ OK ] Starting iscsid: Starting up vdsm daemon: vdsm start [ OK ] [root@purple-vds2 init.d]# service ksmtuned status ksmtuned (pid 28981) is running... [root@purple-vds2 init.d]# Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-1508.html |