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.

 

Parallels 20.4.1 running a Debian Bookworm instance .. <sigh> still an issue.

 

Can confirm this is still an issue on Parallels 26.0.1 and Ubuntu 24.04.3.

 

I never resolved this. Switched to Orbstack, haven't looked back.

 

I have a tentative solution which is in the form of a workaround:

• Apple M4 Pro with Tahoe 26.2
• Parallels Desktop 26 for Mac Pro Edition
• Ubuntu 24.04 LTS

We have been having the date flipping forward a century on our Parallels Ubuntu VMs for some time now. Working with Support at Parallels has not yet achieved a fix or repair to this situation. Restarting the VMs usually corrects the problem, but the log files are then full of incorrect, future dates, which disables AWStats a very helpful utility to track website activity.

At our shop, we researched workarounds on the Internet and discovered that the following settings have now worked for us on eight consecutive days, which has not happened before. I cannot guarantee these setting will work for anyone else, but we are running 6 Ubuntu VMs as important network servers, and the

• Disable time sync in the macOS settings of the Parallels Control Center
  
• Shut down the VM
• Manually edit the .pvs config file for the VM in the Parallels bundles (on macOS level). We found the prlctl command would not make all changes as requested.
• Edit the TimeSync section as follows to disable Time Sync and Timezone Sync:
  <TimeSync SyncHostToGuest_patch="1" SyncInterval_patch="1" dyn_lists="">
  <Enabled>0</Enabled>
  <SyncInterval>0</SyncInterval>
  <KeepTimeDiff>0</KeepTimeDiff>
  <SyncHostToGuest>0</SyncHostToGuest>
  <SyncTimezoneDisabled>1</SyncTimezoneDisabled>
  </TimeSync>
• Make sure the Ubuntu Date/Time service is installed and running:
  • Check if the package is installed: Run apt list --installed | grep systemd-timesyncd.
  • If not installed, install it with: sudo apt install systemd-timesyncd
  • sudo systemctl enable systemd-timesyncd
  • sudo systemctl start systemd-timesyncd
  • sudo systemctl status systemd-timesyncd
  • sudo timedatectl set-ntp true
  • sudo timedatectl set-timezone UTC
• The Ubuntu command timedatectl should show:
  
  Time zone: UTC
  System clock synchronized: yes
  NTP service: active