Bug 1053847 - Recommended default clock/timer settings
Summary: Recommended default clock/timer settings
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-15 20:09 UTC by Cole Robinson
Modified: 2018-10-09 14:44 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-10-09 14:44:04 UTC
Embargoed:


Attachments (Terms of Use)

Description Cole Robinson 2014-01-15 20:09:17 UTC
Recently there was an internal discussion with several qemu developers about default VM clock/timer configuration. What they recommended maps to this libvirt XML:

  <clock ...>
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
  </clock>

This maps to the qemu command line options:

  -rtc driftfix=slew -no-hpet -no-kvm-pit-reinjection

Explicitly this was recommended for all guest OS. Some bits don't affect certain OS, but in those cases they are harmless.

Libguestfs is currently only adding:

  <timer name="kvmclock" present="yes"/>

This is actually non-functional with qemu AFAICT from inspecting the code: if kvm is enabled, kvmclock is enabled by default. if kvm is not enabled, kvmclock will never be enabled, even if the user requests it. So trying to force it on  the command line has no effect (maybe it did in older qemu versions).

Comment 1 Richard W.M. Jones 2014-01-15 20:19:27 UTC
I've long suspected that libguestfs is doing the wrong thing.  Pino?

Comment 2 Pino Toscano 2014-01-16 17:21:14 UTC
(In reply to Cole Robinson from comment #0)
> Recently there was an internal discussion with several qemu developers about
> default VM clock/timer configuration. What they recommended maps to this
> libvirt XML:
> 
>   <clock ...>
>     <timer name="rtc" tickpolicy="catchup"/>
>     <timer name="pit" tickpolicy="delay"/>
>     <timer name="hpet" present="no"/>
>   </clock>
> 
> This maps to the qemu command line options:
> 
>   -rtc driftfix=slew -no-hpet -no-kvm-pit-reinjection
> 
> Explicitly this was recommended for all guest OS. Some bits don't affect
> certain OS, but in those cases they are harmless.

Easy enough to change. From a quick test here, using
- libvirt 1.0.5.8-1.fc19.x86_64
- qemu-kvm 1.4.2-15.fc19.x86_64
I see in libvirt's log:
  -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet
(we pass <clock offset="utc">, hence "base=utc"), so should be working.

Is there any minimum combination of libvirt and/or qemu for the options above to work? Currently we require:
- qemu >= 1.1 (although 1.2 is strongly recommeded)
- libvirt >= 0.10.2

> Libguestfs is currently only adding:
> 
>   <timer name="kvmclock" present="yes"/>
> 
> This is actually non-functional with qemu AFAICT from inspecting the code:
> if kvm is enabled, kvmclock is enabled by default. if kvm is not enabled,
> kvmclock will never be enabled, even if the user requests it. So trying to
> force it on  the command line has no effect (maybe it did in older qemu
> versions).

Not useful indeed.

Comment 3 Cole Robinson 2014-01-16 18:17:45 UTC
(In reply to Pino Toscano from comment #2)
> (In reply to Cole Robinson from comment #0)
> > Recently there was an internal discussion with several qemu developers about
> > default VM clock/timer configuration. What they recommended maps to this
> > libvirt XML:
> > 
> >   <clock ...>
> >     <timer name="rtc" tickpolicy="catchup"/>
> >     <timer name="pit" tickpolicy="delay"/>
> >     <timer name="hpet" present="no"/>
> >   </clock>
> > 
> > This maps to the qemu command line options:
> > 
> >   -rtc driftfix=slew -no-hpet -no-kvm-pit-reinjection
> > 
> > Explicitly this was recommended for all guest OS. Some bits don't affect
> > certain OS, but in those cases they are harmless.
> 
> Easy enough to change. From a quick test here, using
> - libvirt 1.0.5.8-1.fc19.x86_64
> - qemu-kvm 1.4.2-15.fc19.x86_64
> I see in libvirt's log:
>   -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet
> (we pass <clock offset="utc">, hence "base=utc"), so should be working.
> 
> Is there any minimum combination of libvirt and/or qemu for the options
> above to work? Currently we require:
> - qemu >= 1.1 (although 1.2 is strongly recommeded)
> - libvirt >= 0.10.2

I see the timer XML changes went into libvirt in 2010, which is before 0.10.2. So I think those checks should be sufficient.

Comment 4 Richard W.M. Jones 2014-01-16 20:05:17 UTC
I'm going to make the minimum version of libvirt be 1.1.1 (since
that is the version we will ship in RHEL 7.0).

https://github.com/libguestfs/libguestfs/commit/6b3e05e8da490fc11a2f07f0cc9022216a744ac7

Comment 5 Richard W.M. Jones 2014-01-18 14:25:26 UTC
I've fixed this as a side-effect of cleaning up some libguestfs
backend code.  Will post a patch shortly.

Comment 6 Richard W.M. Jones 2014-01-18 21:17:28 UTC
Fixed in
https://github.com/libguestfs/libguestfs/commit/b6ff6421686e6fd7e5f7db8eed24419c7bd09688

As we should probably backport this to earlier branches,
leaving this bug open for now.

Comment 7 Richard W.M. Jones 2014-01-22 20:59:36 UTC
FYI, qemu now prints out this warning:

Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.

I assume it's talking about -no-kvm-pit-reinjection.

Comment 8 Cole Robinson 2014-01-23 13:19:05 UTC
Yeah I believe upstream libvirt has a fix to use the new option, or at least there was a patch posted once

Comment 9 Richard W.M. Jones 2014-01-23 13:25:25 UTC
Thanks .. Seems to be this one:

http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=1569fa14d8f6b6636cf78d7ee62ae3bd205f5638

Comment 10 Richard W.M. Jones 2014-01-23 13:33:32 UTC
The new option would appear to be:

-global kvm-pit.lost_tick_policy=discard

I've posted a patch for libguestfs:

https://www.redhat.com/archives/libguestfs/2014-January/msg00216.html


Note You need to log in before you can comment on or make changes to this bug.