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! <n...@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" <shadow...@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 <shadow...@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! <n...@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" <shadow...@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.
