Time sync issues on silicon mac running Ubuntu 22 VM

It seems like Ubuntu has fixed the issue, at least for me.
I have it fully updated and it is reporting the correct date/time.

 

I'm having the same issue, latest version of Parallels 20 and Debian 12, running on a M2 Mac Mini. After I manually change the time and enable automatic time sync again, it immediately reverts to the wrong time in the future, to March 2120. It only works again after I reboot the VM.

 

Got the same issue, which again creates lots of issues for me. Any fix for this yet?

 

It seems to be on the ubuntu side.
What I've started doing is backup the vm before updating, do the updates, restart the vm a time or two to be sure the time issue isn't present.
If it is, I revert the vm and wait on updating it.
If it is fine, I go ahead and backup after the updates too.
It was broken last time, around February 17th or at least that seems to be when I spotted the problem and reverted.

 

I have not seen any resolution. For now, I have disabled automatic snapshots of the affected VM. (I only run one Ubuntu VM). And then, I make sure that I shutdown the VM before taking a manual snapshot every few weeks.

 

In that case this issue exists on both 22.04 and 24.04.

 

Chiming in with a "me too!" comment. I have an ARM Ubunut 24.04 VM running on my M3, Parallels Desktop 20.2.2. The time change is intermittent but quite often, and very annoying. Rebooting clears the problem, but there is no guarantee that it won't pop up. I happen to have the current date/time in my shell prompt, and I've seen the problem manifest while the VM is basically idle (the prompt shows the correct time, I hit return and it shows the wrong time).

 

I reread this entire thread and saw the earlier post regarding SmartGuard. I tested that: checked that the date/time was correct, manually created a snapshot, checked date/time again. The date indeed jump 95 years into the future, and that was the only activity between the two date/time checks.

I've disabled SmartGuard until this issue is resolved.

 

This still seems borked for me. My temp fix is as follows, which I do after every Parallels Tools update. All run under root

Code:

chmod -x /usr/lib/parallels-tools/tools/tools-arm64/bin/prltimesync
chmod -x /usr/bin/prltimesync

This stops prltimesync from running at all, which appears to be the issue with the date jumping ahead (as mentioned earlier in this thread).

Then on each boot I sync time manually:

Code:

ntpd -gq

 

It does not seem to be caused by prltimesync but by suspsend-resume. Proof: i deleted both copies of prltimesync and the issue recurs. repro is easy. start vm. quite parallels letting it suspend the vm, reopen. view clock.


the dumb chatbot tried to blame a "known kernel issue" which is of course bullshit since the issue did not exist on the very same VM on parallels 19

i filed an actual ticket. let's see how they blame this on the kernel now

 

Yes actually I just had a time jump with my "fix" in place, so it looks like I haven't managed to patch it. Seems like it needs a proper fix.

I'm now creating snapshots before I suspend, so if it jumps I can rollback.

 

Opening tickets is good, but I've had mine open since early January, and they just keep trying to get me to go through the same troubleshooting steps, over and over. It seems clear that they have no idea how to fix this. More tickets might help, I suppose.

 

Joining the club who have this issue. Watching the thread with a hope there is a resolution from Parallels soon. . .

 

Original creator of the thread back 1.5 years later and still having the issue, this time on a brand new Ubuntu 24 VM. It's extremely frustrating to have to reboot whenever this happens. It happens regardless of suspend/resume. It may possibly be related to cpu usage, but I haven't been able to confirm that.