Bug 1238260 - RHEV deployments fail on SSL cert errors due to NTP/incorrect target host hwclock
Summary: RHEV deployments fail on SSL cert errors due to NTP/incorrect target host hwc...
Alias: None
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: Installation - RHEV
Version: 1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: TP3
: 1.0
Assignee: Fabian von Feilitzsch
QA Contact: Tasos Papaioannou
Dan Macpherson
Keywords: Triaged
Depends On:
TreeView+ depends on / blocked
Reported: 2015-07-01 13:32 UTC by Dave Johnson
Modified: 2018-02-26 19:58 UTC (History)
5 users (show)

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)
Clone Of:
Last Closed: 2018-02-26 19:58:38 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1250736 None None None Never

Internal Trackers: 1250736

Description Dave Johnson 2015-07-01 13:32:05 UTC
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 23:00:55 UTC
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 15:48:26 UTC
PR up here: https://github.com/fusor/fusor-installer/pull/44

Comment 3 Fabian von Feilitzsch 2016-02-02 16:07:52 UTC
New PR: https://github.com/fusor/fusor-installer/pull/45

Comment 4 John Matthews 2016-04-05 13:51:45 UTC
In TP3 RC2

Comment 5 Tasos Papaioannou 2016-04-12 20:52:25 UTC
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.