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@xxxxxxxxxx>
> ---
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list