On 13.02.2014 19:51, Michal Privoznik wrote:
These APIs allow users to get or set time in a domain, which may
come
handy if the domain has been resumed just recently and NTP is not
configured or hasn't kicked in yet and the guest is running
something time critical. In addition, NTP may refuse to re-set the clock
if the skew is too big.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
include/libvirt/libvirt.h.in | 13 +++++++
src/driver.h | 13 +++++++
src/libvirt.c | 91 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 6 +++
4 files changed, 123 insertions(+)
+/**
+ * virDomainSetTime:
+ * @dom: a domain object
+ * @time: time to set in the domain
+ * @timezone: timezone of @time, currently not used, always pass NULL
+ * @flags: extra flags, not used yet, so callers should always pass 0
+ *
+ * When a domain is suspended or restored from a file the
+ * domain's OS has no idea that there was a big gap in the time.
+ * Depending on how long the gap was, NTP might not be able to
+ * resynchronize the guest.
+ *
+ * This API tries to set guest time to the given value. The time
+ * should be in seconds, relative to the Epoch of 1970-01-01 in UTC.
One question though. qemu-ga currently takes nanoseconds in its 'guest-set-time'
and returns nanoseconds in 'guest-get-time'. I know nanoseconds are out of scope
for libvirt. But aren't seconds too gross? Maybe we want something more finer -
miliseconds perhaps. In my measurements I was unable to get below 6-7 miliseconds:
for ((i=0; i<100; i++)) ; do virsh -t qemu-agent-command rhel7
'{"execute":"guest-ping"}' | grep Time; done | sort -n -t
':' -k 2
(Time: 7,590 ms)
(Time: 7,601 ms)
(Time: 7,635 ms)
(Time: 7,682 ms)
(although to be fair, this involves domain lookup API too)
Michal