HPE OneView
cancel
Showing results for 
Search instead for 
Did you mean: 

OneView - Server NTP configuration hijacked

 
Highlighted
Frequent 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!

 

 

 

6 REPLIES 6
Highlighted
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

Accept or Kudo
Highlighted
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?  

Highlighted
Frequent 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...







Highlighted
Occasional 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. 

 

Highlighted
Respected 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?

Highlighted
Established Member

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!