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

Bug 1084863

Summary: hosted-engine-setup fails at "Waiting for cluster to become operational"
Product: [Retired] oVirt Reporter: Garry Tiedemann <garrytiedemann>
Component: ovirt-hosted-engine-setupAssignee: Sandro Bonazzola <sbonazzo>
Status: CLOSED CURRENTRELEASE QA Contact: meital avital <mavital>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.4CC: acathrow, garrytiedemann, gklein, iheim, yeylon
Target Milestone: ---   
Target Release: 3.4.1   
Hardware: x86_64   
OS: Linux   
Whiteboard: integration
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-08 13:37:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ovirt-hosted-engine-setup logfile none

Description Garry Tiedemann 2014-04-07 05:12:36 UTC
Created attachment 883449 [details]
ovirt-hosted-engine-setup logfile

Description of problem:
After informing the host that engine-setup has completed in the VM, and the VDSM host has become operational, the host crashes after several attempts at "Waiting for cluster 'Default' to become operational".

Version-Release number of selected component (if applicable):
ovirt-hosted-engine-setup.noarch              1.1.2-1.fc19     @ovirt-3.4-stable

How reproducible:
Always

Steps to Reproduce:
1. run hosted-engine --deploy
2. In the VM, install operating system & perform engine-setup
3. following this the --deploy crashes the host as described above.

Actual results:
Host crashes

Expected results:
Successful deployment of hosted-engine

Additional info:
Host & VM are installed with 3.13.7-100.fc19.x86_64, selinux permissive.
Install log shows these:
2014-04-07 12:02:40 DEBUG otopi.plugins.ovirt_hosted_engine_setup.engine.add_host add_host._wait_cluster_cpu_ready:254 cluster <ovirtsdk.infrastructure.brokers.Cluster object at 0x35c91d0> cluster.__dict__ {'_Base__context': 55360272, 'glusterhooks': <ovirtsdk.infrastructure.brokers.ClusterGlusterHooks object at 0x35c9210>, 'glustervolumes': <ovirtsdk.infrastructure.brokers.ClusterGlusterVolumes object at 0x35c9750>, 'superclass': <ovirtsdk.xml.params.Cluster object at 0x35c92d0>, 'networks': <ovirtsdk.infrastructure.brokers.ClusterNetworks object at 0x35c9650>, 'permissions': <ovirtsdk.infrastructure.brokers.ClusterPermissions object at 0x35c9710>}

Comment 1 Garry Tiedemann 2014-04-07 05:14:44 UTC
Seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=1073986.
I am happy to provide any additional information that is asked for.

Comment 2 Garry Tiedemann 2014-04-08 05:18:38 UTC
Hi guys,
I am not going to pursuse this one, as we're going to use CentOS as the base OS for ovirt now.
What I think: I had the nx bit turned off on this host at the time. It's my suspect.
I will not be able to provide further information, so close or dispose of this as you see fit.
thanks,
Garry

Comment 3 Sandro Bonazzola 2014-04-17 13:18:57 UTC
Can you try to reproduce on CentOS with nx bit turned off?

Comment 4 Garry Tiedemann 2014-04-28 22:19:39 UTC
Hi Sandro,
I can't test any further on this as I have moved ahead with CentOS on those machines. I did have the NX bit turned off on these hosts at the time I did the FC19 trial; it was only when going to CentOS that I got error messages which indicated turning on NX. So, maybe NX was important to FC19, just showed up differently.
Thanks,
Garry

Comment 5 Sandro Bonazzola 2014-05-08 13:37:48 UTC
This is an automated message

oVirt 3.4.1 has been released:
 * should fix your issue
 * should be available at your local mirror within two days.

If problems still persist, please make note of it in this bug report.