Bug 1238260 - RHEV deployments fail on SSL cert errors due to NTP/incorrect target host hwclock
RHEV deployments fail on SSL cert errors due to NTP/incorrect target host hwc...
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: Installation - RHEV (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: TP3
: 1.0
Assigned To: Fabian von Feilitzsch
Tasos Papaioannou
Dan Macpherson
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2015-07-01 09:32 EDT by Dave Johnson
Modified: 2018-02-26 14:58 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
If the hardware clock on the Red Hat Enterprise Virtualization hypervisor host is largely out of synchronization with the hardware clock on the unified installer machine, the Red Hat Enterprise Virtualization deployment fails with SSL errors in the logs. (Tech Preview)
Story Points: ---
Clone Of:
Last Closed: 2018-02-26 14:58:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Johnson 2015-07-01 09:32:05 EDT
Description of problem:
I had RHEV deployments failing with SSL cert errors which I determined to be related to the hwclock on a few targets was way off from that of the Sat server which is sync'd to NTP.  I believe during the deployment we need to sync the target hosts off of NTP as well, the question is, at least in my scenario, all the hosts were in a private network, is the Sat server doubling as a NTP server as well? 

Either the Sat server should be NTP or we need to set the hw clock time during the kickstart?

Version-Release number of selected component (if applicable):
v6.0  0618 iso

How reproducible:

Steps to Reproduce:
1.  on a target host, make the hwclock be atleast 24hours off
1.  create deployment for rhev 
2.  select the host with wrong hwclock
3.  deploy

Actual results:
Deployment fails with no clear reason, digging in the logs you find ssl cert errors

Expected results:
either the deployment fixes the time or errors with an appropriate error message

Additional info:
Comment 1 Fabian von Feilitzsch 2016-01-28 18:00:55 EST
Description of problem:
If the physical host machine's time does not match the satellite box (which ntp syncs to an outside source), then bringing up VMs on that physical will lead to them sharing a time with the physical host, and not with the satellite box. This will lead to the same SSL cert errors described above.

Steps to Reproduce:
1.  Make sure that your physical host is 24 hours off clock.redhat.com (or whatever ntp sync server you are using)
2.  create deployment for rhev 
3.  deploy

Additional info:
Can work around by syncing your physical host with the satellite box before creating more vms.
Comment 2 Fabian von Feilitzsch 2016-02-01 10:48:26 EST
PR up here: https://github.com/fusor/fusor-installer/pull/44
Comment 3 Fabian von Feilitzsch 2016-02-02 11:07:52 EST
New PR: https://github.com/fusor/fusor-installer/pull/45
Comment 4 John Matthews 2016-04-05 09:51:45 EDT
In TP3 RC2
Comment 5 Tasos Papaioannou 2016-04-12 16:52:25 EDT
Verified on QCI-1.0-RHEL-7-20160411.t.0. Manager and host get synced to the fusor host in the kickstart, before registering:

# cat /root/anaconda-ks.cfg
#update local time
echo "updating system time"
/usr/sbin/ntpdate -sub fusor.example.com
/usr/sbin/hwclock --systohc

# add subscription manager
yum -t -y -e 0 install subscription-manager
rpm -ivh http://fusor.example.com/pub/katello-ca-consumer-latest.noarch.rpm

No SSL errors seen in registration or subsequent communication with the Satellite.

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