Chiradeep, Is it possible to "back port" the 4.2 system VMs to 4.1? What would be involved in such an effort?
Thanks, -John On May 21, 2013, at 7:07 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > The latest 4.2 systemvms do have ntp built in. The earlier comment about > HVM is incorrect. It is PV (PVOPS, to be exact). With PVOPS Linux vms, > there is no sync between domU and dom0. > > On 5/21/13 2:45 PM, "Marcus Sorensen" <shadow...@gmail.com> wrote: > >> +1, it seems that it is no worse off then it ever has been, aside from >> the caveat that newer features are beginning to rely on it. I do agree >> though that it could perhaps be rolled into the newer system vm, as an >> option for people to use at their own risk. >> >> Of course, if someone wants to patch it up and get testing going, I'm >> all for that as well. I just don't see holding things up. >> >> On Tue, May 21, 2013 at 3:33 PM, John Burwell <jburw...@basho.com> wrote: >>> David, >>> >>> I am willing to do the work. However, as I understand the >>> circumstances, a complete build process for the system VMs has not been >>> released. If I am incorrect in my understanding, I will do the work >>> necessary to fix the problem. >>> >>> Thanks, >>> -John >>> >>> On May 21, 2013, at 5:29 PM, David Nalley <da...@gnsa.us> wrote: >>> >>>> On Mon, May 20, 2013 at 4:15 PM, Chip Childers >>>> <chip.child...@sungard.com> wrote: >>>>> All, >>>>> >>>>> As discussed on another thread [1], we identified a bug >>>>> (CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs >>>>> are not configured to sync their time with either the host HV or an >>>>> NTP >>>>> service. That bug affects the system VMs for all three primary HVs >>>>> (KVM, >>>>> Xen and vSphere). Patches have been committed addressing vSphere and >>>>> KVM. It appears that a correction for Xen would require the re-build >>>>> of >>>>> a system VM image and a full round of regression testing that image. >>>>> >>>>> Given that the discussion thread has not resulted in a consensus on >>>>> this >>>>> issue, I unfortunately believe that the only path forward is to call >>>>> for >>>>> a formal VOTE. >>>>> >>>>> Please respond with one of the following: >>>>> >>>>> +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 being >>>>> resolved >>>>> +0: don't care one way or the other >>>>> -1: do *not* proceed with any further 4.1 release candidates until >>>>> CLOUDSTACK-2492 has been fully resolved >>>>> >>>>> -chip >>>>> >>>>> [1] http://markmail.org/message/rw7vciq3r33biasb >>>> >>>> >>>> So it appalls me that this problem exists. If I understand correctly, >>>> from folks who commercially support derivatives of ACS. Lack of time >>>> synchronization has been a factor in major outages, but that's >>>> typically been between the hypervisors and management servers. >>>> Regardless we realize (or should) that time is important for so many >>>> reasons (encryption, logs, and scores of other reasons) >>>> >>>> But when the rubber meets the road - here are the two points that >>>> decide it for me. >>>> >>>> 1. This is not a new problem. It's bad, it shouldn't exist, but it >>>> does, and it has for some time it would seem. That suggests it's not >>>> catastrophic, and hasn't yet blocked folks from getting things done >>>> with CloudStack. >>>> >>>> 2. I see no one stepping up to do the work. I am not personally a fan >>>> of issuing what is the effective equivalent of an 'unfunded mandate'. >>>> The problem isn't just one of building a new SSVM - it's one of >>>> testing it, and repeating all of the validation that has already been >>>> done with the existing sysvm. >>>> >>>> Perhaps there is a middle ground (we have a default sysvm, but perhaps >>>> like we are doing with the IPv6-enabled sysvm we have a time-enabled >>>> sysvm available for folks. >>>> >>>> Regardless - you called a vote, so I'll reluctantly cast a +1 - I hate >>>> that we are seeing this problem, but with no one stepping up to do all >>>> of the work, I'm not quite ready to hold a release hostage waiting to >>>> find such a person. >>>> >>>> --David >>> >
