On Jul 10, 2012 4:57 PM, "Kurt Albershardt" <[email protected]> wrote:
>
> On Jul 10, 2012, at 8:29 , Kurt Albershardt wrote:
>
> >> There seems be to a bug with ntpd service because of the leap second
day.
> >>
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second
> >>
> > This may indeed be an issue between the VM host and the VM.  I got to
thinking about NTP architecture in a VM environment last night - wondering
why run NTP on each individual VM when the host is providing the 'hardware
clock' the VMs use.
> >
> >> From http://forum.proxmox.com/threads/986-NTP-and-proxmox (by one of
the Proxmox team):
> >
> > you do not need a ntp server in a container (and its not possible) -
time comes from the host.
> >
> > The 'not possible' part concerns me a bit so I'm going to ask for more
info.
>
> Rebooting the host cleared the deadlock -- CPU usage is now minimal at
rest.
>
> Turns out that OpenVZ (by design) prevents client VMs from changing
system time.  Their position is to enable this on one container only and
not to run NTP on the host
>
http://download.swsoft.com/virtuozzo/virtuozzo4.0/docs/en/lin/VzLinuxUG/330.htmexplains
the OpenVZ
> BUT
> Proxmox runs NTP on the host by default.
> SO
> Rebooting and allowing NTP to update the VM actually did nothing, since
the CT was running on host time, which had not been rebooted.
>
>
> I can disable NTP on the CT, but if sipxecs (at least in the
groupinstall) has a dependency on ntp, I'd prefer to configure around it so
I don't get overwritten on a future update.  Preferred method

In ntp settings there's an option for unmanaged just for this case

>
>
> --thanks
>
>
>
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to