Bug 1167322

But ksmtuned DOES conflict vdsm's usage of mom. We don't want ksmtuned to be running in parallel.

Which platform are you referring to? RHS/RHEV on el7?

We may want to explicitly disable ksmtuned with `vdsm-tool configure`.

The platform is EL7

On the mean while, please `systemctl disable ksmtuned.service` before installation

Paul, since you experienced the issue first, have you noticed what installed and enabled the ksmtuned.service?

As stated in comment 1 vdsm uses mom and we don't want two ksm managers running at the same time.

Disabling/removing ksmtuned is breaking any RHS requirement?

ksmtuned.service came in with the qemu-kvm-common-rhev package from the rhev3.5 beta channel

[root@rh7-kvm1 ~]# rpm -qf /lib/systemd/system/ksmtuned.service
qemu-kvm-common-rhev-1.5.3-60.el7_0.10.x86_64


Here's the yum history 

Transaction ID : 9
Begin time     : Tue Nov 18 10:31:43 2014
Begin rpmdb    : 755:535eb036ba2014357049377aa78bd8e64ca8ef21
End time       :            10:33:23 2014 (100 seconds)
End rpmdb      : 756:543e3ecd8d90b8cd314fc494e90cd4e6094db7cc
User           : root <root>
Return-Code    : Success
Command Line   : update -y
Transaction performed with:
    Installed     rpm-4.11.1-16.el7.x86_64                    @anaconda/7.0
    Installed     subscription-manager-1.10.14-9.el7_0.x86_64 @rhel-7-server-rpms
    Installed     yum-3.4.3-118.el7.noarch                    @anaconda/7.0
Packages Altered:
    Updated    gnutls-3.1.18-9.el7_0.x86_64                     @rhel-7-server-rpms
    Update            3.1.18-10.el7_0.x86_64                    @rhel-7-server-rpms
    Updated    gnutls-dane-3.1.18-9.el7_0.x86_64                @rhel-7-server-rpms
    Update                 3.1.18-10.el7_0.x86_64               @rhel-7-server-rpms
    Updated    gnutls-utils-3.1.18-9.el7_0.x86_64               @rhel-7-server-rpms
    Update                  3.1.18-10.el7_0.x86_64              @rhel-7-server-rpms
    Install    kernel-3.10.0-123.9.3.el7.x86_64                 @rhel-7-server-rpms
    Updated    kernel-tools-3.10.0-123.9.2.el7.x86_64           @rhel-7-server-rpms
    Update                  3.10.0-123.9.3.el7.x86_64           @rhel-7-server-rpms
    Updated    kernel-tools-libs-3.10.0-123.9.2.el7.x86_64      @rhel-7-server-rpms
    Update                       3.10.0-123.9.3.el7.x86_64      @rhel-7-server-rpms
    Updated    mariadb-libs-1:5.5.37-1.el7_0.x86_64             @rhel-7-server-rpms
    Update                  1:5.5.40-1.el7_0.x86_64             @rhel-7-server-rpms
    Obsoleted  qemu-img-10:1.5.3-60.el7_0.10.x86_64             @rhel-7-server-rpms
    Obsoleting qemu-img-rhev-10:1.5.3-60.el7_0.10.x86_64        @rhel-7-server-rhev-mgmt-agent-beta-rpms
    Obsoleted  qemu-kvm-10:1.5.3-60.el7_0.10.x86_64             @rhel-7-server-rpms
    Obsoleted  qemu-kvm-common-10:1.5.3-60.el7_0.10.x86_64      @rhel-7-server-rpms
    Obsoleting qemu-kvm-common-rhev-10:1.5.3-60.el7_0.10.x86_64 @rhel-7-server-rhev-mgmt-agent-beta-rpms
    Obsoleting qemu-kvm-rhev-10:1.5.3-60.el7_0.10.x86_64        @rhel-7-server-rhev-mgmt-agent-beta-rpms
    Updated    sssd-client-1.11.2-68.el7_0.5.x86_64             @rhel-7-server-rpms
    Update                 1.11.2-68.el7_0.6.x86_64             @rhel-7-server-rpms
history info

I don't see mom installed on either of my test RH7 hypervisors. If vdsm has a dependency on mom, shouldn't the install of vdsm pulled it in?

what vdsm version are we talking about? what is qemu-kvm-common-rhev and what requires it?

Bala, regarding -
"""In a converged glusterfs/virt use case (RHS/RHEV converged use case), this fails vdsm to be started at boot time."""

why is it different than any installation ? why the conflicts list don't catch? I'd like to understand this case better.

Dan, regarding - 
"""We may want to explicitly disable ksmtuned with `vdsm-tool configure`."""

please elaborate. in what scope should we do that? it sounds like it fits more to pre-start tasks ..

I like the idea of disabling the conflicting services on `vdsm-tool configure`. This cannot be postponed to a pre-start task, as vdsmd service cannot start if a conflicting service is running.

I don't think there is any difference between RHS and RHEV in this regard, and believe that Bala is talking about ovirt-3.4's vdsm for el7 (but any vdsm for el7 would have the same behavior).

It's all about ksmtuned.service being enabled before installation.

So is there some race at boot time?
What's the failure on VDSM startup on boot?

It looks like mom dependency is not pulled in when vdsm is installed in EL7.  For more info please check comment #5

Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.

Hi
ksmtuned.service is still enabled (but inactive) after adding the host to engine, is it okay ?

#systemctl status ksmtuned.service
● ksmtuned.service - Kernel Samepage Merging (KSM) Tuning Daemon
   Loaded: loaded (/usr/lib/systemd/system/ksmtuned.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

# ls /usr/lib/systemd/system-preset/
85-display-manager.preset  85-vdsmd.preset  90-default.preset  90-systemd.preset  99-default-disable.preset

file ksmtuned.service in /usr/lib/systemd/system/ exists

for some reason it indeed doesn't work - I also tried it over f23 and centos7 and if you enable ksmtuned before installing vdsm, it will stay enabled. running systemctl preset-all doesn't change anything. 
 
I asked in #systemd freenode channel and didn't get any meaningful response. 

however, the enable parts work. and using "systemctl preset-all" also work. for some reason "systemctl preset vdsmd.service" doesn't do only the "disable*" part 

we don't "really" need it.. mom-vdsm states in its unit file "init/systemd/mom-vdsm.service.in:Conflicts=momd.service ksmtuned.service" .. so when you start vdsm, ksmtuned will stop. 

so I wouldn't call it urgent. vdsm configures systemd alright. 

opening systemd bug on it

Opened Bug #1297363

We need to move this logic to vdsm configuration part - apparently our use in preset file for that is not the way to disable services in installation time (see Bug #1297363) 

I reopen this bug and target it to 3.6.3

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Verified in 3.6.3-0.1.el6