No worries!
I checked the scripts of the RPM and that line is in there.
I tried to reinstall it but no luck.
Then I began to run each line in the RPM script by hand.
What I found out is that there was already a KVM group but not in the
/etc/group file.
The system was connected to a IPA server and somebody had created the KVM
group for some reason. (Maybe me in the past :-))
I removed the KVM group from IPA and ran the installation again and it
works flawless!
So the KVM group in IPA was the reason why the installation was not
working correctly.
Thanks for your time and I feel a bit stupid that I did not check this
before sending a e-mail to this mailinglist.
Also no worries.. I don't think that was easy issue to figure, but with
good collaboration every bug can be discovered. Keep using the users
list for any future issues with ovirt.
Regards,
Yaniv.
On 31/03/15 15:23, "ybronhei" <ybronhei(a)redhat.com> wrote:
> On 03/31/2015 03:34 PM, Bloemen, Jurriën wrote:
>> Hi,
>>
>> Please see the inline answers.
>>
>> Thanks in advance,
>>
>> Jurriën
>>
>
> Sorry that he took me awhile to check that (I didn't have el7
> installation in hand) but now when checking that -
> please run: rpm -q --scripts qemu-kvm-common-rhev
>
> you'll see that this package creates the kvm group - useradd -r -u 107
> -g qemu -G kvm -d / -s /sbin/nologin \
> -c "qemu user" qemu
>
> something went wrong with your installation and its hard to tell what.
> please try - yum reinstall qemu-kvm-common-rhev
>
> then check again "egrep "kvm" /etc/group" , if exists run
vdsm-tool
> configure --force and start vdsm
>
> Let me know how it goes..
>
>> On 31/03/15 14:18, "ybronhei" <ybronhei(a)redhat.com> wrote:
>>
>>> On 03/31/2015 02:07 PM, Bloemen, Jurriën wrote:
>>>> Hi all,
>>>>
>>>> First of all thanks Yaniv for your reply!
>>>
>>> Sure. Anytime
>>>
>>> Basically kvm group should be created by qemu rpm installation,
>>> so first check "egrep "kvm" /etc/group" - it should
return
>>> kvm:x:36:qemu,sanlock if your system is installed properly
>>
>> "egrep "kvm" /etc/group"
>>
>> No result
>>
>>
>>>
>>> If not, please tell me the output of "rpm -qa | grep qemu-kvm"
>>
>> # rpm -qa | grep qemu-kvm
>> qemu-kvm-rhev-1.5.3-60.el7_0.2.x86_64
>> qemu-kvm-tools-rhev-1.5.3-60.el7_0.2.x86_64
>> qemu-kvm-common-rhev-1.5.3-60.el7_0.2.x86_64
>>
>>
>>>
>>> And just to be on the same side write me also what vdsm version you use
>>> There
>>
>> # rpm -qa | grep vdsm
>> vdsm-xmlrpc-4.16.10-8.gitc937927.el7.noarch
>> vdsm-jsonrpc-4.16.10-8.gitc937927.el7.noarch
>> vdsm-python-zombiereaper-4.16.10-8.gitc937927.el7.noarch
>> vdsm-python-4.16.10-8.gitc937927.el7.noarch
>> vdsm-yajsonrpc-4.16.10-8.gitc937927.el7.noarch
>> vdsm-4.16.10-8.gitc937927.el7.x86_64
>> vdsm-cli-4.16.10-8.gitc937927.el7.noarch
>>
>>
>>>
>>> Yaniv.
>>>>
>>>> This is a fresh new installed system. It was not registered to another
>>>> oVirt engine before.
>>>>
>>>> So...
>>>>
>>>> The output of "groups sanlock² is
>>>> sanlock : sanlock disk qemu
>>>>
>>>> KVM is missing. There is no kvm group at all or user for that matter!?
>>>>
>>>> I ran the command "vdsm-tool configure --module sanlock ‹force² and
>>>> after
>>>> that ³groups sanlock² but it shows the same output as above.
>>>>
>>>> Do you have other ideas what to check?
>>>>
>>>> Thanks in advance,
>>>>
>>>> Jurriën
>>>>
>>>> On 31/03/15 10:23, "ybronhei" <ybronhei(a)redhat.com>
wrote:
>>>>
>>>>> Hey guys,
>>>>>
>>>>> Probably the problem is that sanlock service cannot stop properly -
>>>>> was
>>>>> the host registered to another ovirt engine before and you missed to
>>>>> put
>>>>> it on maintenance before adding it to another system?
>>>>>
>>>>> Such issue raised before when sanlock service fails to stop - can
you
>>>>> explicitly check if does - service sanlock stop - fail or pass?
>>>>>
>>>>> If it fails it means that some leases are still locked and reboot
>>>>> will
>>>>> solve the issue.
>>>>>
>>>>> If that is not the case please share the output of "groups
sanlock" -
>>>>> it
>>>>> should be - sanlock : sanlock disk kvm qemu after the call to -
>>>>> vdsm-tool configure --module sanlock --force (fyi all this configure
>>>>> call does is to add sanlock user to those groups in this case)
>>>>>
>>>>> Hope the information helps. Please share your progress with the
>>>>> issue.
>>>>>
>>>>> Yaniv Bronhaim.
>>>>>
>>>>> On 03/31/2015 10:15 AM, Bloemen, Jurriën wrote:
>>>>>> I did that also. I forgot to mention it because you only have to
run
>>>>>> --force if you didn¹t stop the sanlock process of running.
>>>>>> The result of with and without is the same. Still the vdsmd
process
>>>>>> cannot start.
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Roy Golan
<rgolan@redhat.com<mailto:rgolan@redhat.com>>
>>>>>> Date: Monday 30 March 2015 23:25
>>>>>> To: Jurriën Bloemen
>>>>>>
>>>>>>
>>>>>>
<jurrien.bloemen@dmc.amcnetworks.com<mailto:jurrien.bloemen@dmc.amcne
>>>>>> tw
>>>>>> or
>>>>>> ks.com>>
>>>>>> Cc: "users@ovirt.org<mailto:users@ovirt.org>"
>>>>>> <users@ovirt.org<mailto:users@ovirt.org>>
>>>>>> Subject: Re: [ovirt-users] Modules sanlock are not configured
>>>>>>
>>>>>>
>>>>>> On Mar 30, 2015 10:45 PM, Jurriën
>>>>>>
>>>>>>
>>>>>>
<Jurrien.Bloemen@dmc.amcnetworks.com<mailto:Jurrien.Bloemen@dmc.amcne
>>>>>> tw
>>>>>> or
>>>>>> ks.com>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I have CentOS 7 running and I added the oVirt 3.5 repo to it.
I
>>>>>>> open
>>>>>>> the oVirt Manager and added a new system to it.
>>>>>>> The manager says installing and after that is fails to
connect.
>>>>>>> Looking on the system I see:
>>>>>>>
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
mkdirs
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> configure_coredump
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> configure_vdsm_logs
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> wait_for_network
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> run_init_hooks
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> upgraded_version_check
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
>>>>>>> check_is_configured
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Error:
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: One of the
modules is
>>>>>>> not
>>>>>>> configured to work with VDSM.
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: To configure the
module
>>>>>>> use the following:
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool
configure
>>>>>>> [--module module-name]'.
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: If all modules
are not
>>>>>>> configured try to use:
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool
configure
>>>>>>> --force'
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: (The force flag
will
>>>>>>> stop
>>>>>>> the module's service and start it
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: afterwards
>>>>>>> automatically
>>>>>>> to load the new configuration.)
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: libvirt is
already
>>>>>>> configured for vdsm
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Modules sanlock
are not
>>>>>>> configured
>>>>>>> Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: stopped
during
>>>>>>> execute check_is_configured task (task returned with error
code 1).
>>>>>>>
>>>>>>> So I run vdsm-tool configure after I stop sanlock.
>>>>>>>
>>>>>>> # vdsm-tool configure
>>>>>>
>>>>>> Try adding --force (this is what the log suggests)
>>>>>>
>>>>>>>
>>>>>>> Checking configuration status...
>>>>>>>
>>>>>>> libvirt is already configured for vdsm
>>>>>>> SUCCESS: ssl configured to true. No conflicts
>>>>>>>
>>>>>>> Running configure...
>>>>>>> Reconfiguration of sanlock is done.
>>>>>>>
>>>>>>> Done configuring modules to VDSM.
>>>>>>>
>>>>>>> But when I want to start vdsmd it still gives the error that
>>>>>>> sanlock
>>>>>>> is not configured.
>>>>>>>
>>>>>>> Does somebody has a solution for this?
>>>>>>>
>>>>>>> I am a bit lost on thisŠ Google only tells me that there was
a bug
>>>>>>> in
>>>>>>> 3.4.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>> Jurriën
>>>>>>> This message (including any attachments) may contain
information
>>>>>>> that
>>>>>>> is privileged or confidential. If you are not the intended
>>>>>>> recipient,
>>>>>>> please notify the sender and delete this email immediately
from
>>>>>>> your
>>>>>>> systems and destroy all copies of it. You may not, directly
or
>>>>>>> indirectly, use, disclose, distribute, print or copy this
email or
>>>>>>> any
>>>>>>> part of it if you are not the intended recipient
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>>
http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Yaniv Bronhaim.
>>>>
>>>
>>>
>>> --
>>> Yaniv Bronhaim.
>>
>
>
> --
> Yaniv Bronhaim.