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.