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 shadowsor@gmail.com
 designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1347443500.54157.1423213375921.JavaMail.zimbra@li.nux.ro>
References: 
 <CAKprHVYf1W+HsM==iWA-yao3-vL8hOTed10NxvSJRLs0g6_sLA@mail.gmail.com>
	<CACOnxCh038+ejOJR_85EJdDKbV86jtKBSafELQfYomi2LBwYgQ@mail.gmail.com>
	<CACOnxCh-SnTDbxdAvAsWoOwR6q79Ec+miiPbtmdevsdU84spkQ@mail.gmail.com>
	<8040763.2530.1423174019236.JavaMail.andrei@tuchka>
	<CACOnxCiADBmLfeU2MXRU_=Sp=Rvsf9-FDSD2sX2_H0yp9bWJPA@mail.gmail.com>
	<29899357.2561.1423177509882.JavaMail.andrei@tuchka>
	<CACOnxCgSxpUVW2m4yBbC2jSK4tygomPD+U6EihFEpfWJYYV=Lg@mail.gmail.com>
	<CALFpzo66KT88OPo7Z7kxZt6SNHqtEA+3zUCssp5CCQ6SJ0O=tA@mail.gmail.com>
	<1347443500.54157.1423213375921.JavaMail.zimbra@li.nux.ro>
Date: Fri, 6 Feb 2015 08:19:46 -0800
Message-ID: 
 <CALFpzo7oPkpr8SqLFH=XaZUvkOjC8_0fZcZ7cBq+Ky+fq+v-YQ@mail.gmail.com>
Subject: Re: [VOTE] Apache CloudStack 4.5.0 RC1
From: Marcus <shadowsor@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=UTF-8

If a vm is pv enabled, it gets the kvmclock timer xml attribute,
regardless. Setting kvmclock.disable makes that timer xml explicitly
disable kvmclock, it doesn't remove it from the xml (You might be
thinking "why do we need a setting to enable it if we have to
explicitly disable it to make it go away?"... this is again due to
variations in version behavior, some versions make pv guests have
kvmclock regardless unless explicitly disabled). There were some
issues in certain kvm (kernel) versions that would cause problems with
live migration and kvmclock, so this option would fix that if someone
runs into it, but we can't leverage this agent option to remove the
xml that the ubuntu 12.04 libvirt version doesn't support.

Nux, some more background, at one point system vms were having various
issues because of clock drift. A few of the other hypervisor platforms
were leveraging their hypervisor to fix this. Running ntp in the
system vm was mentioned (and perhaps even implemented, I'd have to go
back and look), but some didn't like that solution, either, because
without a project to add ntp settings as a 'thing' in cloudstack it
would require internet access or an admin rolling their own system vm.
Network issues aside, f you look around at the greater KVM ecosystem
there is quite a bit of back and forth on whether kvmclock or NTP is
ideal, and the best option seems to be to have both.

So that, combined with the live migration issues, is what introduced
the kvmclock xml both to make it available to pv guests and to
explicitly disable it if there are issues.

I spoke to Mike about this last night, and hopefully we'll be seeing a
fix that simply acts like older CS versions if we detect the feature
is unsupported. So we'll automagically work on newer platforms like
Ubuntu 13+ and CentOS 7 and fail back correctly for old Ubuntu, with
the only downside being that CentOS users can't leverage kvmclock even
though their build supports it (the fault of RH backporting features
without changing versions).


On Fri, Feb 6, 2015 at 1:02 AM, Nux! <nux@li.nux.ro> wrote:
> That's unfortunate, but I don't think many people will care.
>
> Pretty much everyone in virt uses ntp religiously and am yet to hear complains about clock performance in VMs.
>
> Having said that, could the feature be enforceable through agent.properties if desired? Something like Rohit is suggesting with kvmclock.disable=false?
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> ----- Original Message -----
>> From: "Marcus" <shadowsor@gmail.com>
>> To: dev@cloudstack.apache.org
>> Sent: Friday, 6 February, 2015 06:45:14
>> Subject: Re: [VOTE] Apache CloudStack 4.5.0 RC1
>
>> I think we can wrap this in a version check as we have many other
>> things, that way Ubuntu 12.04 users who leverage newer libvirt
>> packages (as I'm temped to believe the majority of actual deployments
>> do) can still see the benefit, and we don't have to worry about
>> targeting a specific release. This will have the negative side effect
>> of not allowing centos 6.x people from leveraging their backported
>> support since their version numbers are deceptive, but it's probably
>> the smartest, most compatible way to indroduce it.