cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: [VOTE] Apache CloudStack 4.5.0 RC1
Date Fri, 06 Feb 2015 17:57:39 GMT
Sure, I agree. It just makes it tough to detect features when we're
targeting multiple platforms.

On Fri, Feb 6, 2015 at 8:49 AM, Nux! <nux@li.nux.ro> wrote:
> Roger that.
> Well, backports without version change is one of the main reasons I use (RH)EL, so depends
you look at it.
> Anyway, it does not seem like a big thing affecting users, so good job on finding a fix.
Thanks.
>
> 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 16:22:15
>> Subject: Re: [VOTE] Apache CloudStack 4.5.0 RC1
>
>> CentOS *6* users, that is...
>>
>>
>> On Fri, Feb 6, 2015 at 8:19 AM, Marcus <shadowsor@gmail.com> wrote:
>>> 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.

Mime
View raw message