[libvirt] [RFC] Automatically sync time on domain resume?
So I came across this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1156194 There's a request for us to automatically sync guest time on domain resume (e.g. bare virDomainResume(), or virDomainRestore() or after migration). I'd like to explore our options here and what would be acceptable upstream. I can think of two possibilities: 1) Invent new flag to all APIs in question and let mgmt applications call it. If the flag is set we would sync the guest time too. However, this masks two different operations under single API. What should be reported if resuming succeeded but syncing time did not? Success or failure? Mgmt applications will end up calling two APIs to distinguish error states anyway. 2) Do this as best effort. Unconditionally, whenever guest agent is available just issue the time sync command (possibly without waiting for reply). This, however, takes away control from users - they will no longer have possibility to just resume domain without time sync. There's of course the obvious solution - not change anything and have mgmt apps calling two separate APIs - like they oughtta be doing today. What's your view? Michal
On Tue, Oct 13, 2015 at 01:13:04PM +0200, Michal Privoznik wrote:
So I came across this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1156194
There's a request for us to automatically sync guest time on domain resume (e.g. bare virDomainResume(), or virDomainRestore() or after migration). I'd like to explore our options here and what would be acceptable upstream. I can think of two possibilities:
1) Invent new flag to all APIs in question and let mgmt applications call it. If the flag is set we would sync the guest time too. However, this masks two different operations under single API. What should be reported if resuming succeeded but syncing time did not? Success or failure? Mgmt applications will end up calling two APIs to distinguish error states anyway.
2) Do this as best effort. Unconditionally, whenever guest agent is available just issue the time sync command (possibly without waiting for reply). This, however, takes away control from users - they will no longer have possibility to just resume domain without time sync.
There's of course the obvious solution - not change anything and have mgmt apps calling two separate APIs - like they oughtta be doing today.
That's the right solution IMHO
What's your view?
I see no compelling reason to add anything to the API or implementation. We provide enough functionality already to deal with this scenario. Trying to overload multiple operations into a single API "for convenience" ends up not being convenient at all, due to the error reporting scenarios you mention. I don't see any real burden on applications to call these existing APIs when they wish to. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 10/13/2015 06:20 AM, Daniel P. Berrange wrote:
There's of course the obvious solution - not change anything and have mgmt apps calling two separate APIs - like they oughtta be doing today.
That's the right solution IMHO
What's your view?
I see no compelling reason to add anything to the API or implementation. We provide enough functionality already to deal with this scenario. Trying to overload multiple operations into a single API "for convenience" ends up not being convenient at all, due to the error reporting scenarios you mention. I don't see any real burden on applications to call these existing APIs when they wish to.
I still think virsh can be taught the convenience method. I agree that the lowlevel libvirt.so entry points don't need convenience, but we have already established that virsh is perfectly capable of doing 2 or more low-level API calls under a single command, in part because virsh has decent error reporting about which step of the sequence fails. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Oct 13, 2015 at 08:46:13AM -0600, Eric Blake wrote:
On 10/13/2015 06:20 AM, Daniel P. Berrange wrote:
There's of course the obvious solution - not change anything and have mgmt apps calling two separate APIs - like they oughtta be doing today.
That's the right solution IMHO
What's your view?
I see no compelling reason to add anything to the API or implementation. We provide enough functionality already to deal with this scenario. Trying to overload multiple operations into a single API "for convenience" ends up not being convenient at all, due to the error reporting scenarios you mention. I don't see any real burden on applications to call these existing APIs when they wish to.
I still think virsh can be taught the convenience method. I agree that the lowlevel libvirt.so entry points don't need convenience, but we have already established that virsh is perfectly capable of doing 2 or more low-level API calls under a single command, in part because virsh has decent error reporting about which step of the sequence fails.
Oh sure, virsh could do this. I was only considering the API. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, Oct 13, 2015 at 13:13:04 +0200, Michal Privoznik wrote: ...
1) Invent new flag to all APIs in question and let mgmt applications call it. If the flag is set we would sync the guest time too. However, this masks two different operations under single API. What should be reported if resuming succeeded but syncing time did not? Success or failure? Mgmt applications will end up calling two APIs to distinguish error states anyway.
2) Do this as best effort. Unconditionally, whenever guest agent is available just issue the time sync command (possibly without waiting for reply). This, however, takes away control from users - they will no longer have possibility to just resume domain without time sync.
There's of course the obvious solution - not change anything and have mgmt apps calling two separate APIs - like they oughtta be doing today.
What's your view?
As I've pointed out in a review a while ago [1] combining two operations into one API tends to be problematic. I'd advise that the users of the API call the two functions separately with the full control it allows them rather. Peter [1]: http://www.redhat.com/archives/libvir-list/2014-November/msg00134.html http://www.redhat.com/archives/libvir-list/2014-November/msg00137.html
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Michal Privoznik -
Peter Krempa