Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1179068 - [3.5-6.6] libvirtd service is not active as default when RHEV-H TUI installation
Summary: [3.5-6.6] libvirtd service is not active as default when RHEV-H TUI installation
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Douglas Schilling Landgraf
QA Contact: Virtualization Bugs
Whiteboard: node
: 1179148 (view as bug list)
Depends On:
Blocks: rhev35rcblocker rhev35gablocker
TreeView+ depends on / blocked
Reported: 2015-01-06 06:27 UTC by cshao
Modified: 2016-02-10 20:07 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-11 21:07:46 UTC
oVirt Team: Node
Target Upstream Version:

Attachments (Terms of Use)
libvirt-issue.png (deleted)
2015-01-06 06:27 UTC, cshao
no flags Details
libvirt.tar.gz (deleted)
2015-01-06 06:29 UTC, cshao
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0160 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2015-02-12 01:34:52 UTC
oVirt gerrit 36649 master MERGED recipe: centos6 and rhevh6 Never
oVirt gerrit 36705 ovirt-3.5 MERGED recipe: centos6 and rhevh6 Never

Description cshao 2015-01-06 06:27:24 UTC
Created attachment 976714 [details]

Description of problem:
libvirtd service is not active as default when RHEV-H TUI installation

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Boot from PXE, TUI install RHEV-H
2. Focus on the first installation screen and check the libvirt error.
3. Finish the installation and log in the hypervisor.
4. Check libvirt issue on TUI.
5. Please see attachment for more details.

Actual results:
1. Step 2: "Failed to Establish Libvirt Connection" appears in the first installation screen.
2. Step4: "Failed to Establish Libvirt Connection" still appears on TUI.
3. Can manually start libvirtd service successful.

# /etc/init.d/libvirtd status
libvirtd is stopped

Expected results:
libvirtd service can work fine.

Additional info:
1. No such issue with rhev-hypervisor6-6.6-20141218.0, so it is a regression bug.
2. Automatic installation did not meet this issue, after automation installation, the libvirtd is running as default.
3. No such issue on rhev-hypervisor7-7.0-20150105.0 build.

Comment 1 cshao 2015-01-06 06:29:03 UTC
Created attachment 976715 [details]

Comment 2 Douglas Schilling Landgraf 2015-01-06 21:26:12 UTC

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:
NEEDED_SERVICES="multipathd rpcbind ntpd wdmd sanlock network libvirtd supervdsmd"

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

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
            service "${srv}" status >/dev/null 2>&1 || service "${srv}" start
        if [ "${ret_val}" -ne 0 ]; then
            log_failure_msg "${prog}: Start dependent ${srv}"
            return "${ret_val}"

So, if we add a debugging in the for:

    for srv in ${needed_services}; do
        echo ${srv} >> /tmp/starting
        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

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 $?

# ifconfig
lo        Link encap:Local Loopback  
          inet addr:  Mask:
          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.

Comment 3 Douglas Schilling Landgraf 2015-01-06 21:38:45 UTC
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

Comment 4 Douglas Schilling Landgraf 2015-01-07 13:09:10 UTC
*** Bug 1179148 has been marked as a duplicate of this bug. ***

Comment 10 cshao 2015-01-19 05:47:04 UTC
Test version:

# /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.

Comment 12 errata-xmlrpc 2015-02-11 21:07:46 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.