Xen is a platform that allows multiple operating systems running in virtual systems on one physical box of hardware.

At a customer site before deploying the product in a production environment he may want to test the product or component. To test or demo the product, multiple systems with different servers and clients might be required which might be cumbersome to have. At that point of time SUSE Linux Enterprise Server, which has a Xen virtualization platform serves the purpose. SLES Xen has become solid and provides support for a large series of OS’s (Windows, NetWare, SLES, OES, etc.).

There might be various scenarios or deployments where time synchronization across the servers and setups is needed. This document helps to resolve the time synchronization issues to have successful setups on guest virtual systems. In one of the cases, while attaching a eDirectory server to an exiting Tree, time synchronization plays a major role. In this document one such scenario/problem is considered with workarounds to have time synchronization across the servers.


One of the scenarios where time synchronization plays a vital role is while attaching a eDirectory Read/Write to an exiting eDirectory Tree. At that point of time both master replica and read/write replica should be in time sync. The eDirectory configuration fails if the servers are not in timesync which is a major failure for the component. This article describes how time synchronization issues can be resolved.

While installing and configuring eDirectory the configuration will fail at 53% with an error: “ndsconfig failed to configure and start eDirectory”.

Click to view.

Figure 1: eDirectory configuration failure at 53 %

Failure of the eDirectory configuration is due to the time synchronization between the Tree server and the read/write server.


  1. SLES10 SP1/SP2/SP3 or SLES11 server along with Xen packages is installed as Xen Host.
  2. Tree installed and configured on NetWare or OES-Linux server.

Intend: To resolve time sync issues while configuring an OES-Linux eDirectory server into the exiting eDirectory Tree


Workaround Steps on OES-Linux Guest System

Perform the following steps to resolve time synchronization issues.

  1. Check the time synchronization between the Virtual Host and Tree server. As the guest operating system periodically synchronizes the time with the host machine, both Xen host and Tree server should be in time sync.
    • Both Tree server and the Virtual Host system are configured with the same NTP source.
    • Or, the Virtual Host is configured with Tree server as the time source.
  2. Inspite of both Guest system and Host system being configured with the same NTP source, there might be a time drift between them which needs to be synchronized.

    Restarting NTP service frequently to get the time regularly will solve the problem, for which crontab can be used. Do the following:

    1. On the virtual guest system enter “crontab –e” to edit the crontab
    2. Enter the following

      0-59/1 * * * * root rcntp <<public time source>>

    A crontab file has five fields for specifying day , date and time. In the above command the first entry 0-59/1 represents minutes, the first * is for hour (0-23), next for day of month (1-31), next is month (1-12) and the other is day of week (0-6) (Sunday=0).

    This contab entry in the above command will restart NTP service for every minute by which the system get the time from NTP server for every minute.

    Now, the time synchronization issue should be resolved. If not, check the below steps.

  3. If the firewall is running on the server, see that port 123 (TCP and UDP) is open in the firewall for time synchronization.
  4. If you are using VMs anywhere it’s recommended if you can avoid using the VM as a time source unless you really trust it. At this point of time point to a public time source.
  5. One more option to check for time synchronization failure is the wallclock setting. When booting, virtual systems get their initial clock time from their host. After getting their initial clock time, fully virtual systems manage their time independently from the host. Paravirtual systems manage clock time according to their independent wallclock setting. If the independent wallclock is enabled, the virtual system manages its time independently and does not synchronize with the host. If the independent wallclock is disabled, the virtual system periodically synchronizes its time with the host clock.

To view the Independent Wallclock Setting do the following:

  1. Log in to the virtual system’s operating system as root.
  2. In the virtual system environment, enter
  3. cat /proc/sys/xen/independent_wallclock
    • 0 means that the virtual system is getting its time from the host and is not using independent wallclock.
    • 1 means that the virtual system is using independent wallclock and managing its time independently from the host.

Permanently Changing the Independent Wallclock Setting

  1. Log in to the virtual system environment as root.
  2. Edit the virtual system’s /etc/sysctl.conf file.
  3. Add or change the following entry:
  4. xen.independent_wallclock=0

    Enter 1 to enable or 0 to disable the wallclock setting.

    See that it is set to 0 so that it will get the time from Host system which is synchronized with the tree server.

  5. Save the file and reboot the virtual system operating system.

    While booting, a virtual system gets its initial clock time from the host. Then, as the wallclock setting is set to 0 in the sysctl.conf file, it manages to get the time from the host clock time and does not get from its clock time independently.

Temporarily Changing the Independent Wallclock Setting

  1. Log in to the virtual system environment as root.
  2. Enter the following command:
  3. echo “0” > /proc/sys/xen/independent_wallclock

    Enter 1 to enable or 0 to disable the wallclock settting.

  4. Add or change the following entry: in /etc/sysctl.conf file


    Enter 1 to enable or 0 to disable the wallclock setting.

Although the current status of the independent wallclock changes immediately, its clock time might not be immediately synchronized. The setting persists until the virtual system reboots. Then, it gets its initial clock time from the host and uses it as the independent wall clock is disabled in the sysctl.conf file.


The SUSE Linux Enterprise 10.X & 11 Xen platform is a very useful environment to be able to demo or test OES components without requiring multiple systems. Time synchronization plays a major role in a Xen platform to have successful setups.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • aburgemeister says:

    If you really need to restart cron that often I do not believe the line provided is valid. Instead try:

    * * * * * root /etc/init.d/ntp restart

    The public time source on the end in the example is, as far as I can tell, not ever used. During the startup of ntp, though the time is “slammed” which is probably the desired outcome of the operation. Also 0-59/1 is the same thing as * so no need to confuse the syntax at the start. Next full paths should always be used in cron as cron can very in the environment provided. Finally the ‘root’ parameter (the sixth on the line, right before the command) is only valid when modifying /etc/crontab specifically and not needed when using any of the other cron tables (the ones for users, accessed via `crontab -e`, or the /etc/cron.* directories which automatically run as ‘root’ as well).

  • ksarkies says:

    It might be better to run ntp normally on the host where time is far more stable than in the guests. Get the guests to synchronize to the host ntp service. That way the public servers will be spared the extra traffic load.

Jul 9, 2009
5:24 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow