HPE OneView
1752743 Members
5127 Online
108789 Solutions
New Discussion

OneView - Server NTP configuration hijacked

 
k2skaterii
Regular Visitor

OneView - Server NTP configuration hijacked

I understand why each system's clock needs to be confifured to use the same time across the board.  That's why everysystem should be pointed to a valid NTP server.  If I didn't have an NTP server already, I'd appreciate the NTP server service that comes built in with my freshly deployed HPE OneView Appliance...  

Yes, I searched the forums and read a couple of posts where other users had similar concerns.  The posts I read were responded to... I'm asking a similar question again because the answers I read are unacceptable.  The kind of unacceptable that could prevent further implementation.

I work for a companty that has switches, servers, storage arrays, and who knows what else deployed to 300+ sites across the US.  Syncronizing time across each site was a problem, 20 years ago.  Since then a robust NTP infastructure has been deployed, and every device is already configured to use our own local NTP servers - Hard to justify using OneView as an NTP server where you are already pulleding a Stratum-2 time.  

OneView_NTP.JPG

I can't be the only one with this problem?  There's got to be some other users out there who have run into the same problem... Some other users who were not happy to find their NTP settings had been overwritten... 

Is there a way to override / disable the NTP configuration changes that OneView makes when systems are managed by OneView?  

If there's no way to override the changes when systems are added to OneView, has anyone come up with a creative solution?  

 

As it stands today, my firewall team will not allow connectivity from end devices to my OneView Appliance on UDP-123, so now instead of pointing to "a stratum-2 NTP server" my systems are pointed to an NTP server that does not exist / is not accessible. 

Should I stop where I am.... Power my VM down... and move on to some other problem?

 

Thanks for the Rant!

 

 

 

17 REPLIES 17
AmRa
HPE Pro

Re: OneView - Server NTP configuration hijacked

There is no way to override / disable the NTP configuration changes that OneView makes when systems are managed by OneView.

HPE advise to set the appliance to use a specific NTP server or servers, or your Hypervisor host. The reason of doing this is, we don't want logs that OneView records are different time than the iLO time. 

I am an HPE Employee.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]

Accept or Kudo
PeterWolfe
Respected Contributor

Re: OneView - Server NTP configuration hijacked

> If I didn't have an NTP server already, I'd appreciate the NTP server service that comes built in with my freshly deployed HPE OneView Appliance...  

That is not really what OneView is offering here. The best practice is to have an NTP server configured in OV and then OV can push that setting to all the managed devices. So OV is strictly a NTP client of your NTP server. On a VM, by default OV uses the VM host as it's NTP server and assumes you have configured the hypervisor host appropraitely as an NTP client to your NTP server. Same applies to Synergy Composer - you are expected to configure NTP server there as well. 

> As it stands today, my firewall team will not allow connectivity from end devices to my OneView Appliance on UDP-123, so now instead of pointing to "a stratum-2 NTP server" my systems are pointed to an NTP server that does not exist / is not accessible. 

That is the real issue here. If there was a OV feature to allow you to configure per-device NTP servers, would it be the same set of NTP servers for a single OV instance? That would be easy to support. Or would a single OV instance have to support managed devices that each could habe a separate set of NTP servers? In that case it couldn't be a server profile attribute. or you'd end up with server profile bloat. How would you envision it working?  

k2skaterii
Regular Visitor

Re: OneView - Server NTP configuration hijacked

PeterWolfe -

Thanks to the failures of those before me, i prefer to NOT synchronize any of my VMs with the hosting hypervisor. The stories... And the reasons why i shouldn't / 2ae scolded for correcting the host whose time was off by 3 days... Let's just say i didn't agree!

Best practice to configure OV to point to an NTP server - won't catch me arguing here. I didn't know it was a best practice, but it works with NTP, so i configure it!

I think you hit the nail on the head with your last comment. If there was an OV feature that allowed me to point OV to "NTP-1" and "NTP-2", while also allowing managed devices to point to "NTP-1" and "NTP-2"... Then i think that would solve my problem.

Using OV as an NTP server for synergy blades in the same enclosure, makes enough sense... Can't really argue it. In my case i am trying to use the Virtual OV, for a couple of seemingly simple reasons. Since it's forced upon us with each Synergy, using the same tool, same GUI, same processes to manage non-Synergy pizza boxes and enclosures seemed like a good idea. A real improvement over the firmware was updated "when the server was installed, 7 years ago" or "when we ran into a problem that we couldn't figure out, so it seemed like a good idea.". It's hard enough to convince management to take a system out of production, the easier it is to deploy updated firmware and drivers, the better!

To answer your question - "If there was a OV feature to allow you to configure per-device NTP servers, would it be the same set of NTP servers for a single OV instance?" - Yes it would be the same set of NTP servers per OV instance.

Truth be told, since i couldn't get around this problem... I haven't read enough to know how many OV instances would be required to manage / monitor the systems I'm thinking about. Perfect world, 1 instance in the center of the country would suffice!

Since posting my NTP Rant / disappointment, I've downloaded and deployed a new VM, the iLO Amplifer pack. I intended to connect a couple of systems to it, a small proof of concept to figure out how it worked, figure out if it was easy to use and most importantly figure out if it was the answer to my problems! I was showing one guy what i was working on, he gave me 1 CVS to import... 1500 systems. So much for small proof of concept...







uzimmermann
Frequent Advisor

Re: OneView - Server NTP configuration hijacked

As a customer I agree, I would prefer to be able to control if OneView sets NTP for iLO or not. This has been an annoying for myself. When you do a full NTP server setup (at least 4 servers with Stratum 1 or 2 as the masters), I shouldn't be pointing clients at a single source such as a VM instance of OneView. 

 

BradV
Esteemed Contributor

Re: OneView - Server NTP configuration hijacked

I'm not sure I'm understanding the problem statement?  You can tell OneView to use external NTP servers.  Using hponcfg you can configure all of your iLOs to use the same NTP servers.  Using your appropriate tools, you can set your OS's to use the same NTP servers.  I've never seen OneView forcing iLO's or OS's to change their NTP setup.  I do think the OneView server profile template should include a setting for the iLO NTP setup.  I think I might be missing your point?

Bobinhed
Occasional Advisor

Re: OneView - Server NTP configuration hijacked

If I have servers at multiple sites (or in DMZs), using local NTP devices is ALWAYS preferred, as having HPE OneView push NTP to those devices is incredibly stupid. I have complained about this issue since HPE OneView 3.0.

In my use case, we have servers in a DMZ that are monitored by HPE OneView. NTP is blocked on the upstream firewall by-design because we have local NTP servers that we are expected to use. Since the iLOs can't reach HPE OneView for time, they go out of sync. We have to run a script every day to change the NTP settings on every iLO to the correct and desired NTP servers to obtain correct time... and then HPE OneView changes the NTP settings back to itself.

There should be an option at the very least to either use HPE OneView for time or to NOT use it for time so it stops breaking all of our iLOs (can't log in using Active Directory if the time is not correct, and it never is)

FORCING changes to NTP is the absolute WORST design decision and HPE needs to FIX IT!

vx_it
Advisor

Re: OneView - Server NTP configuration hijacked

Just discovered today that all our ILO servers had their time server settings hijacked by OneView, with no indication whatsoever of this occurring during the setup process!

Is it still not possible to disable this and prevent OneView from doing it? Is our only option to manually set the time server for each ILO? 

BradV
Esteemed Contributor

Re: OneView - Server NTP configuration hijacked

We have two oneview instances (5.30) and hundreds of proliant DL360s, DL380s, and DL580s G9 and G10.  None of them have had their iLO SNTP settings changed.  We have all of the buttons on the SNTP page turned off.  Just have the time servers entered and the time zone.  If you have any of those buttons turned on, I wonder if that could be causing the problem you are seeing?

It is quite strange.  I hope you can find an answer.

vx_it
Advisor

Re: OneView - Server NTP configuration hijacked

We also only have the primary time server and time zone entered, with the rest of the settings disabled. (OneView 5.50)

I have confirmed that performing a "Refresh" in OneView for any node will overwrite the existing SNTP settings in the ILO, replacing "Primary Time Server" with the OneView server's IP address. When watching the progress indicator for the Refresh action, one of the readouts is "Configuring NTP..."

TsKMhavcfi.png

In addition to this, any new server added to OneView will have its ILO NTP set to the OneView server's IP address by default, and has to be changed after deployment. 

This is unacceptable behavior and I'd like an explanation from HPE as to how we can stop it from happening. I want the ILO NTP setting to be permanent and not subject to being overwritten by OneView (which is using the same server for NTP in its own settings!).