On Tue, Feb 11, 2014 at 02:45:28PM -0700, Eric Blake wrote:
> On 02/11/2014 02:37 PM, Marcelo Tosatti wrote:
>
> >> I think we may need both approaches. I too think that resume with
> >> syncing guest time is so common use case that is deserves to be
> >> exposed as a single operation outside the libvirt.
> >>
> >> On the other hand, we certainly want to expose this as a new
> >> virDomain{Get,Set}Time() API.
> >
> > Why a new API which requires modifications to every libvirt user (read:
> > current libvirt users are broken until patched) ?
>
> ALL existing libvirt users are "broken", in that NO ONE has been able to
> automatically resync guest time yet (at least, using supported libvirt
> API). This is a new feature; but as a new feature that involves guest
> cooperation, it must be explicitly requested by any client that wants to
> take advantage of it. We cannot change the default and automatically
> turn this feature on, because it has back-compat implications to
> existing libvirt clients that are not expecting libvirt to automatically
> try and munge guest time.
What libvirt clients expect is proper operation of their guests. Proper
operation, for 99% of usecases, is to have both guest and host time
synchronized to UTC.
>From the first message in this thread:
"Since QEMU commit "kvmclock: clock should count only if vm is running"
(http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg01225.html),
guests have their realtime clock stopped during pause."
So Linux guests did have their clocks counting during suspend/resume
before, which meant that on resume the realtime clock was synchronized
to UTC.
However, we can't do that (the link above contains more information),
but 99% of deployments still want their guests clock to be synchronized
to UTC.
So it is not really a new feature.
> > Note it requires applications to keep track of every pause/resume
> > instance (see item 1 above).
>
> Whether we make it a new API call that all clients must call every time
> they want, or a single knob that says that for the given VM, libvirt
> should automatically attempt to resync time after any resume action,
> isn't as important to me as the fact that it IS something new that gets
> explicitly requested. We already have <on_poweroff> and friends in the
> guest XML that control what the guest does on a state transition to
> poweroff, maybe we could add an <on_resume> element that has
> instructions on what actions libvirt should take when a guest
> transitions from paused back to running. But the point is that such an
> XML element is an explicit request, and only appropriate for guests
> where the management stack trusts interacting with the guest agent.
Sure.
> Maybe even both additions would be appropriate (a knob for automatic
> libvirt syncing as well as a new API for explicit syncing outside the
> events where libvirt would normally do it automatically).
OK, what i am trying to do is to make sure you understand why libvirt
users are not really interested in this as a new feature (because it is
not).
OK will improve on the knob and resubmit.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list