7:52 p.m.
Hi,
I'm seeing the following issue when attempting to update the guest's
clock on a running fc32 guest (using guest agent):
```
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --pretty
Time: 2020-04-30 23:27:29
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --sync
error: internal error: unable to execute QEMU agent command
'guest-set-time': hwclock failed to set hardware clock to system time
# now, this one works.
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --now
[root@virt-launcher-vmi-masquerade-44v2x /]# virsh domtime 1 --pretty
Time: 2020-04-30 11:15:45
```
This is the simplest reproducer I could come with; the original issue
is this call to libvirt's `setTIme` in [0].
Is there any workaround I could try ? Am I doing something wrong here ?
[0] -
https://github.com/kubevirt/kubevirt/blob/6bb516148ce4c29825ae74f473e0220...
8:15 p.m.
On Thu, Apr 30, 2020 at 01:52:12PM +0200, Miguel Duarte de Mora Barroso wrote:
Hi,
I'm seeing the following issue when attempting to update the guest's
clock on a running fc32 guest (using guest agent):
```
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --pretty
Time: 2020-04-30 23:27:29
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --sync
error: internal error: unable to execute QEMU agent command
'guest-set-time': hwclock failed to set hardware clock to system time
This error is ultimately coming from the QEMU guest agent inside
your guest. It spawns "hwclock" and this is failing for some reason.
You'll probably need to debug this inside the guest - strace the
QEMU guest agent, see where it fails, and then file a bug against
the distro for it.
# now, this one works.
[root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --now
[root@virt-launcher-vmi-masquerade-44v2x /]# virsh domtime 1 --pretty
Time: 2020-04-30 11:15:45
This doesn't run hwclock as its merely reading the current time,.
Is there any workaround I could try ? Am I doing something wrong here
?
I don't think you're doing anything wrong. This just looks like a guest
OS bug to me.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:39 p.m.
On Thu, Apr 30, 2020 at 2:15 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Thu, Apr 30, 2020 at 01:52:12PM +0200, Miguel Duarte de Mora Barroso wrote:
> Hi,
>
> I'm seeing the following issue when attempting to update the guest's
> clock on a running fc32 guest (using guest agent):
>
> ```
> [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --pretty
> Time: 2020-04-30 23:27:29
> [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --sync
> error: internal error: unable to execute QEMU agent command
> 'guest-set-time': hwclock failed to set hardware clock to system time
This error is ultimately coming from the QEMU guest agent inside
your guest. It spawns "hwclock" and this is failing for some reason.
You'll probably need to debug this inside the guest - strace the
QEMU guest agent, see where it fails, and then file a bug against
the distro for it.
Eventually I found out that if I make the call *without* specifying
the `libvirt.DOMAIN_TIME_SYNC` flag this works
as I intend. I've read the docs and could not understand what's the
purpose of this flag .
It reads "Re-sync domain time from domain's RTC" on [0]. It begs the
question: if I'm setting it to a fixed instant in time (which I am),
why would I want it to sync with the domain's RTC ?
Is there any obvious issue that will appear from calling
`virDomainSetTime` (defined at [1]) without the DOMAIN_TIME_SYNC flag
specified ?
I'm not sure if this (removing the DOMAIN_TIME_SYNC) is a fix, an ugly
hack, or a disaster waiting to happen.
> # now, this one works.
> [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --now
>
> [root@virt-launcher-vmi-masquerade-44v2x /]# virsh domtime 1 --pretty
> Time: 2020-04-30 11:15:45
This doesn't run hwclock as its merely reading the current time,.
> Is there any workaround I could try ? Am I doing something wrong here ?
I don't think you're doing anything wrong. This just looks like a guest
OS bug to me.
Thanks for the prompt reply!
[0] -
https://github.com/libvirt/libvirt/blob/bef10f6eaa93db649c36468143ce65564...
[1] - https://github.com/libvirt/libvirt/blob/master/src/libvirt-domain.c#L11292
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:59 p.m.
On Thu, Apr 30, 2020 at 05:39:45PM +0200, Miguel Duarte de Mora Barroso wrote:
On Thu, Apr 30, 2020 at 2:15 PM Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
>
> On Thu, Apr 30, 2020 at 01:52:12PM +0200, Miguel Duarte de Mora Barroso wrote:
> > Hi,
> >
> > I'm seeing the following issue when attempting to update the guest's
> > clock on a running fc32 guest (using guest agent):
> >
> > ```
> > [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --pretty
> > Time: 2020-04-30 23:27:29
> > [root@virt-launcher-vmi-masquerade-mh2xm /]# virsh domtime 1 --sync
> > error: internal error: unable to execute QEMU agent command
> > 'guest-set-time': hwclock failed to set hardware clock to system time
>
> This error is ultimately coming from the QEMU guest agent inside
> your guest. It spawns "hwclock" and this is failing for some reason.
> You'll probably need to debug this inside the guest - strace the
> QEMU guest agent, see where it fails, and then file a bug against
> the distro for it.
Eventually I found out that if I make the call *without* specifying
the `libvirt.DOMAIN_TIME_SYNC` flag this works
as I intend. I've read the docs and could not understand what's the
purpose of this flag .
It reads "Re-sync domain time from domain's RTC" on [0]. It begs the
question: if I'm setting it to a fixed instant in time (which I am),
why would I want it to sync with the domain's RTC ?
Is there any obvious issue that will appear from calling
`virDomainSetTime` (defined at [1]) without the DOMAIN_TIME_SYNC flag
specified ?
I'm not sure if this (removing the DOMAIN_TIME_SYNC) is a fix, an ugly
hack, or a disaster waiting to happen.
If you passing DOMAIN_TIME_SYNC, then the guest agent updates the
guest OS system time, to match the guest OS RTC time.
IOW, this assumes the guest RTC is in sync with the host time,
and we just need to resync the guest OS with the RTC.
If you don't pass DOMAIN_TIME_SYNC, then the time on the host
where you run virsh is sent to the guest OS and this is used
to set the guest OS system time. The issue here is all about
latency between when virsh reads the current time, and when
the guest OS sets this time.
IOW, I'd generally consider DOMAIN_TIME_SYNC a good thing.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
1591
days inactive
1591
days old
3 comments
2 participants
participants (2)
-
Daniel P. Berrangé -
Miguel Duarte de Mora Barroso