Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of jburwell@basho.com designates
 209.85.216.41 as permitted sender)
Content-Type: text/plain; charset=euc-kr
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [ACS41] System VMs not syncing time - does this block the
 release?
From: John Burwell <jburwell@basho.com>
In-Reply-To: <CDB93FD5.164B8%chiradeep.vittal@citrix.com>
Date: Wed, 15 May 2013 17:07:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6793AD0-CB32-40CA-A776-2F619E7B20BA@basho.com>
References: <CDB93FD5.164B8%chiradeep.vittal@citrix.com>
To: dev@cloudstack.apache.org

Chiradeep,

As I think thought it, I don't think a documentation note will =
sufficient because the SSVM can be destroyed and respawned by CloudStack =
without intervention by a human.  Therefore, we can get into a situation =
where an operator installs and configures NTP, and then at some point in =
the future, the SSVM gets respawned and clocks drift.  The worst part =
about this scenario is that the failures for S3 sync become silent since =
we have no mechanism to surface the failure to a dashboard or monitoring =
system.

How much effort (i.e. hours/days) would it be to build a new image?

Thanks,
-John

On May 15, 2013, at 4:59 PM, Chiradeep Vittal =
<Chiradeep.Vittal@citrix.com> wrote:

> Did some further digging around as to why
> /proc/sys/xen/independent_wallclock is not there on the Debian system =
vm.
>=20
> TLDR; the kernel is PvOps (I.e., just a regular kernel that works like =
a
> PV kernel, not a specialized paravirt kernel). To eliminate
> special-casing, the independent_wallclock feature was dropped. =
However,
> this means that the domU clock is NO LONGER synch'ed to dom0 and NTP =
is
> required on ANY domU. So the clock on the domU is only sync'ed at domU
> creation time. I suspect Citrix XenServer might have some workaround
>=20
>=20
> http://www.gossamer-threads.com/lists/xen/users/234750
>=20
>=20
> What this means is that we *may* need to run ntp on system vms on Xen.
> This is of course a non-trivial change involving updates to systemvms.
>=20
> I suspect that it does not matter much for virtual routers or console
> proxy vms.
>=20
> We could have an advisory that for those users that care (e.g., those
> using S3 sync) that they need to run ntp after the SSVM has been =
created.
> I.e, login to the SSVM and run
> apt-get update
> apt-get install ntp
>=20
> --
> Chiradeep
>=20
>=20
>=20
> On 5/15/13 1:11 PM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com> =
wrote:
>=20
>> For VMWare, the command
>> vmware-toolbox-cmd timesync status returns 'Disabled'. I can submit a
>> patch for /etc/init.d/cloud-early-config to enable it
>>=20
>>=20
>> On 5/15/13 12:23 PM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com>
>> wrote:
>>=20
>>> I am not sure why it is missing, but I will refer to
>>> Citrix XenServer 6.0 Virtual Machine Installation Guide
>>>=20
>>> http://s.apache.org/YGn
>>>=20
>>> And quote
>>> "Time Handling in Linux VMs
>>> By default, the clocks in a Linux VM are synchronized to the clock
>>> running
>>> on the control domain, and cannot be
>>> independently changed. This mode is a convenient default, since only =
the
>>> control domain needs to be running the
>>> NTP service to keep accurate time across all VMs. Upon installation =
of a
>>> new Linux VM, make sure you change the
>>> time-zone from the default UTC to your local value (see the section
>>> called
>>> =A9=F8Release Notes=A9=F7 for specific distribution
>>> instructions).
>>> To set individual Linux VMs to maintain independent times
>>> 1. =46rom a root prompt on the VM, run the command: echo 1 >
>>> /proc/sys/xen/independent_wallclock
>>> 2. This can be persisted across reboots by changing the =
/etc/sysctl.conf
>>> configuration file and adding:
>>> # Set independent wall clock time
>>> xen.independent_wallclock=3D1
>>> 3. As a third alternative, independent_wallclock=3D1 may also be =
passed as
>>> a
>>> boot parameter to the VM.
>>> "
>>>=20
>>>=20
>>> On 5/15/13 12:09 PM, "Chip Childers" <chip.childers@sungard.com> =
wrote:
>>>=20
>>>> On Wed, May 15, 2013 at 12:02:41PM -0700, Chiradeep Vittal wrote:
>>>>> /proc/sys is not a regular filesystem and cannot be added to from =
the
>>>>> shell.
>>>>> Drivers need to add nodes into this filesystem.
>>>>=20
>>>> Backing up a bit...
>>>>=20
>>>> This is the current system VM image that the 4.1 software should be
>>>> using on Xen:
>>>>=20
>>>> http://download.cloud.com/templates/acton/acton-
>>>> systemvm-02062012.vhd.bz2
>>>>=20
>>>> Does this system VM have the correct drives installed to set
>>>> /proc/sys/xen to use the Dom0 time for sync?
>>>>=20
>>>> If so, then is this a devcloud only issue for Xen?  If that's the =
case,
>>>> then we shouldn't block a release to simply improve things.
>>>>=20
>>>> We do know that a patch for kvm was needed.
>>>>=20
>>>> We still don't have any
>>>> answer or comments about the VMware system VM (specifically this
>>>> template:  http://download.cloud.com/templates/burbank/burbank-
>>>> systemvm-08012012.ova
>>>>=20
>>>=20
>>=20
>=20