Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1098439

Summary: Host Deploy Fails - Network error during communication with the host.
Product: [oVirt] ovirt-host-deploy Reporter: Sokratis <sokratis123k>
Component: Plugins.VDSMAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED NOTABUG QA Contact: Pavel Stehlik <pstehlik>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 1.2.0CC: alonbl, bazulay, bugs, dougsland, gklein, iheim, oourfali, sokratis123k, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-19 07:27:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ovirt engine log none

Description Sokratis 2014-05-16 08:08:37 UTC
Created attachment 896243 [details]
ovirt engine log

Description of problem: Host Deploy Fails


Version-Release number of selected component oVirt 3.4.1

Steps to Reproduce:

1) Create Cluster with Intel Conroe CPU Family compatibility and ovirt 3.4 compatibility

2) Add Host from oVirt GUI


Actual results:

Installation failed. Network error during communication with the host.

Additional info:

ovirt engine hosted on CentOS 6.5 running on VMware VM.

ovirt node running on CentOS 6.5 on HP Proliant DL380 G5 with Intel Xeon E5320 (Clovertown CPU family)

Comment 1 Alon Bar-Lev 2014-05-16 08:31:23 UTC
vdsm is not starting for some reason, please attach its logs from host at /var/log/vdsm.

Thanks!

Comment 2 Sokratis 2014-05-16 08:36:29 UTC
(In reply to Alon Bar-Lev from comment #1)
> vdsm is not starting for some reason, please attach its logs from host at
> /var/log/vdsm.
> 
> Thanks!

As you can see only supervdsm.log is written:

[root@ovirt-node-01 vdsm]# ls -l /var/log/vdsm/
total 8
drwxr-xr-x 2 vdsm kvm  4096 May  7 17:33 backup
-rw-r--r-- 1 vdsm kvm     0 May 16 10:54 metadata.log
-rw-r--r-- 1 vdsm kvm     0 May 16 10:54 mom.log
-rw-r--r-- 1 root root 1223 May 16 10:54 supervdsm.log
-rw-r--r-- 1 vdsm kvm     0 May 16 10:54 vdsm.log


[root@ovirt-node-01 vdsm]# cat supervdsm.log 
MainThread::DEBUG::2014-05-16 10:54:22,092::supervdsmServer::424::SuperVdsm.Server::(main) Terminated normally
MainThread::DEBUG::2014-05-16 10:54:33,737::netconfpersistence::134::root::(_getConfigs) Non-existing config set.
MainThread::DEBUG::2014-05-16 10:54:33,737::netconfpersistence::134::root::(_getConfigs) Non-existing config set.
MainThread::DEBUG::2014-05-16 10:54:33,763::supervdsmServer::384::SuperVdsm.Server::(main) Making sure I'm root - SuperVdsm
MainThread::DEBUG::2014-05-16 10:54:33,763::supervdsmServer::393::SuperVdsm.Server::(main) Parsing cmd args
MainThread::DEBUG::2014-05-16 10:54:33,763::supervdsmServer::396::SuperVdsm.Server::(main) Cleaning old socket /var/run/vdsm/svdsm.sock
MainThread::DEBUG::2014-05-16 10:54:33,764::supervdsmServer::400::SuperVdsm.Server::(main) Setting up keep alive thread
MainThread::DEBUG::2014-05-16 10:54:33,764::supervdsmServer::406::SuperVdsm.Server::(main) Creating remote object manager
MainThread::DEBUG::2014-05-16 10:54:33,765::supervdsmServer::417::SuperVdsm.Server::(main) Started serving super vdsm object
sourceRoute::DEBUG::2014-05-16 10:54:33,766::sourceRouteThread::56::root::(_subscribeToInotifyLoop) sourceRouteThread.subscribeToInotifyLoop started

Comment 3 Sokratis 2014-05-16 13:47:28 UTC
This was fixed by adding vdsm user to the wheel group and setting the following in /etc/sudoers:

Defaults !requiretty


After these changes vdsmd service starts normally.

Comment 4 Alon Bar-Lev 2014-05-16 15:03:20 UTC
But we install /etc/sudoers.d/50_vdsm with this setting, do you have any special setting to ignore the sudoers.d files?

Comment 5 Sokratis 2014-05-19 06:51:51 UTC
Yes we use a custom /etc/sudoers file that doesn't include /etc/sudoers.d directory.

After modifying /etc/sudoers and including the directory I was able to restart vdsmd service successfully so this is fixed.

Thanks a lot!

Comment 6 Oved Ourfali 2014-05-19 06:57:27 UTC
Alon - I assume we can close this one?