On 11.02.2014 22:45, 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.
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.
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).
I don't think we should add the <on_resume/> element. After all, it
would be the same as:
virDomainResumeFlags(dom, VIR_SYNC_TIME)
which as Dan correctly argues, makes sensible error reporting
impossible. If the domain is resumed, libvirt should execute the
<on_resume/> action, which may fail.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list