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.htm explains 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? --thanks _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
