Bug 1179068

Created attachment 976715 [details]
libvirt.tar.gz

Hi,

I have reproduced the report. I don't see the libvirtd daemon after installation.

VDSM init script contain a trigger to start libvirtd and it's not working because the others needed service are not starting as expected and it cannot continue on the loop to start libvirtd.

Some data:
===============
init/sysvinit/vdsmd.init.in
<snip>
NEEDED_SERVICES="multipathd rpcbind ntpd wdmd sanlock network libvirtd supervdsmd"

start() {
   <snip>
   start_needed_srv "${NEEDED_SERVICES}" || return 1
<snip>

start_needed_srv() {
    local srv
    local ret_val
    local needed_services="$1"

    for srv in ${needed_services}; do
        if initctl status "${srv}" >/dev/null 2>&1; then
            # When srv is Upstart service, status srv always returns 0
            initctl start "${srv}" || : # start fails when already running
            initctl status "${srv}" | grep -q start/running
        else
            service "${srv}" status >/dev/null 2>&1 || service "${srv}" start
        fi
        ret_val=$?
        if [ "${ret_val}" -ne 0 ]; then
            log_failure_msg "${prog}: Start dependent ${srv}"
            return "${ret_val}"
        fi
    done
}

So, if we add a debugging in the for:

    for srv in ${needed_services}; do
        echo ${srv} >> /tmp/starting
        ....
        ret_val=$?
        echo ${ret_val} >> /tmp/starting

We will see that vdsm cannot go into the all services if one stop.

# service vdsmd start
# cat /tmp/starting
multipathd
0
rpcbind
6

However, if we change the order of NEEDED_SERVICES to libvirtd be the first service to be started and reboot, everything works as expected.

Other data about the host
==================================
In case, change the network for the first service, I saw:
# service network start
# echo $?
6

# ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:24993494 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24993494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:28158 (27.4 KiB)  TX bytes:28158 (27.4 KiB)

One option is make the libvirtd service be started on the boot without intervention of VDSM.

I don't see it happening in RHEV-H7 because even we having in rhevh7-install.ks --disabled for libvirtd:

=====
services --enabled=auditd,ntpd,ntpdate,iptables,network,rsyslog,multipathd,snmpd,ovirt-early,ovirt-post,ovirt-cim,ovirt-kdump,cgconfig,mcelog,tuned --disabled=netfs,ovirt-awake,libvirt-guests,libvirtd,kdump
====

We do also have in post rhevh7-post.ks:

========
#enabling libvirtd as described in its libvirtd.service comments and virt-who as requested in bug
systemctl enable libvirtd.service
systemctl enable virt-who.service
========

*** Bug 1179148 has been marked as a duplicate of this bug. ***

Test version:
rhev-hypervisor6-6.6-20150114.0
ovirt-node-3.2.1-4.el6.noarch

# /etc/init.d/libvirtd status
libvirtd (pid  16657) is running...

Test result:
Libvirtd service is active as default when RHEV-H TUI installation.
So the bug has been fixed, change bug status to VERIFIED.

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.

https://rhn.redhat.com/errata/RHEA-2015-0160.html