cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nux! <...@li.nux.ro>
Subject Re: [VOTE] Apache CloudStack 4.5.0 RC1
Date Fri, 06 Feb 2015 16:49:32 GMT
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