Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BAF3B99A9 for ; Wed, 15 May 2013 21:04:40 +0000 (UTC) Received: (qmail 96508 invoked by uid 500); 15 May 2013 21:04:40 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 96462 invoked by uid 500); 15 May 2013 21:04:40 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 96454 invoked by uid 99); 15 May 2013 21:04:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 May 2013 21:04:40 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Check-By: apache.org Received-SPF: error (nike.apache.org: local policy) Received: from [74.125.149.140] (HELO na3sys009aog120.obsmtp.com) (74.125.149.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 May 2013 21:04:34 +0000 Received: from mail-vc0-f182.google.com ([209.85.220.182]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUZP4OFS3If6eAZ9xVe+tiqb4gB9RKLSm@postini.com; Wed, 15 May 2013 14:04:13 PDT Received: by mail-vc0-f182.google.com with SMTP id ia10so2213449vcb.13 for ; Wed, 15 May 2013 14:03:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent:x-gm-message-state; bh=ToEraxBpze/Rw3UZZQ1mZnAgM3xKaSYiVEsZCTbMpt8=; b=LkEeLnsOcHiJhqQXT0g01Q6rlEGyu0s/93idtYdjcf+62G38uy9aTo7yo9VNB02e0M s3LJ613iMEhhnNl9w7HA1CBg+R+j1g+5Ml++NvC+VP7Cxp+VwmT/Ds5aONBpBYvCdbfQ DtIANkHMtronoif51k3sFCKCsvwpc4WENwdyWf7Q1uT5Fxi90om2j3yBV8Sqgw7FP7o3 ZMQgv2HPQ/22aHSWwyqca1UoN8Jxsmqs3wMZjOCXAChvmROpJOrf2pbK11HavGc6/R+v 5ySr9Uv/80jV89ern24kwVomOBU/WLaJr3VQbsdtwBmp169WK5HIdeml+HSGBxFWAo/p 15hA== X-Received: by 10.220.167.69 with SMTP id p5mr24482092vcy.57.1368651831259; Wed, 15 May 2013 14:03:51 -0700 (PDT) X-Received: by 10.220.167.69 with SMTP id p5mr24482087vcy.57.1368651831184; Wed, 15 May 2013 14:03:51 -0700 (PDT) Received: from localhost ([216.203.6.11]) by mx.google.com with ESMTPSA id mw6sm4160115vec.7.2013.05.15.14.03.50 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 15 May 2013 14:03:50 -0700 (PDT) Date: Wed, 15 May 2013 17:03:49 -0400 From: Chip Childers To: dev@cloudstack.apache.org Subject: Re: [ACS41] System VMs not syncing time - does this block the release? Message-ID: <20130515210349.GG24552@USLT-205755.sungardas.corp> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQlxVR1EvPsqkrdo5tdCDoNwURTv73MrpIz2XXEbHw+cDFtIV/WrqxnbcsNspzjP8QDx6tG3figdNQNS0U2e3eBr5/PIVGFIIIkCfzaGFqW2YL9xFzxrvF4N2dEF0QAd5mAJMEPLSrRyvdM0tx05Z917MBH2g3i3koNGDBbt7BzkAJblWrg= X-Virus-Checked: Checked by ClamAV on apache.org On Wed, May 15, 2013 at 01:59:13PM -0700, Chiradeep Vittal wrote: > Did some further digging around as to why > /proc/sys/xen/independent_wallclock is not there on the Debian system vm. > > 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 > > > http://www.gossamer-threads.com/lists/xen/users/234750 > > > 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. > > I suspect that it does not matter much for virtual routers or console > proxy vms. > > 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 Fair idea, but what about when the MS decides that it needs more SSVMs? Is another possibility to take the existing system VM templates and simply update them for this issue? The potential benefit of either approach above is that we would be able to ensure that we did it on all three templates if required. We also obviously need to consider what to do for 4.2, where we were planning on officially releasing new system VMs. > > -- > Chiradeep > > > > On 5/15/13 1:11 PM, "Chiradeep Vittal" wrote: > > >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 > > > > > >On 5/15/13 12:23 PM, "Chiradeep Vittal" > >wrote: > > > >>I am not sure why it is missing, but I will refer to > >>Citrix XenServer 6.0 Virtual Machine Installation Guide > >> > >>http://s.apache.org/YGn > >> > >>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 > >>�Release Notes� for specific distribution > >>instructions). > >>To set individual Linux VMs to maintain independent times > >>1. From 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=1 > >>3. As a third alternative, independent_wallclock=1 may also be passed as > >>a > >>boot parameter to the VM. > >>" > >> > >> > >>On 5/15/13 12:09 PM, "Chip Childers" wrote: > >> > >>>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. > >>> > >>>Backing up a bit... > >>> > >>>This is the current system VM image that the 4.1 software should be > >>>using on Xen: > >>> > >>>http://download.cloud.com/templates/acton/acton- > >>>systemvm-02062012.vhd.bz2 > >>> > >>>Does this system VM have the correct drives installed to set > >>>/proc/sys/xen to use the Dom0 time for sync? > >>> > >>>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. > >>> > >>>We do know that a patch for kvm was needed. > >>> > >>>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 > >>> > >> > > >