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.