Time sync issues on silicon mac running Ubuntu 22 VM

BrianD12

Bit poster
I am running the latest version of Parallels on an M2 Max Mac Studio. I have two VMs running Ubuntu 22.04. The clock is being set 100+ years ahead on both of them. This happens when I just leave the VMs running, not paused or suspended. I set up a script to check the date every 5 seconds and it shows this:
Sun Dec 3 08:35:28 PM CST 2023
Sun Dec 3 08:35:33 PM CST 2023
... all fine until ....
Fri Dec 8 01:53:21 PM CST 2023
Fri Dec 8 01:53:26 PM CST 2023
Fri Dec 8 05:24:50 PM CST 2023
Sun Jan 29 12:52:18 PM CST 2119
Sun Jan 29 12:52:23 PM CST 2119

So it skipped ahead 4 hours and then 96 years. There was nothing going on with the VM, it was just running with no activity.

The hardware clock seems fine:
sudo hwclock -r
2023-12-09 10:29:41.569973-06:00
~ $ date
Sat Jan 28 10:23:07 AM CST 2119

I've tried with and without time sync from VM turned on, but I get the same behavior. I've tried ntp/chrony/timesyncd but once the time is off by that much, they can't get back in sync. The only way to get things back is to reboot. I even tried renaming prltimesync to prltimesync.stop to make sure that program wasn't causing it.

Trying to set the date manually looks like this:
sudo date --debug --set='2023-12-09 10:21:10'
date: parsed date part: (Y-M-D) 2023-12-09
date: parsed time part: 10:21:10
date: input timezone: system default
date: using specified time as starting value: '10:21:10'
date: starting date/time: '(Y-M-D) 2023-12-09 10:21:10'
date: '(Y-M-D) 2023-12-09 10:21:10' = 1702138870 epoch-seconds
date: timezone: system default
date: final: 1702138870.000000000 (epoch-seconds)
date: final: (Y-M-D) 2023-12-09 16:21:10 (UTC)
date: final: (Y-M-D) 2023-12-09 10:21:10 (UTC-06)
date: cannot set date: Invalid argument

Since that's obviously a valid date, my guess is it won't let you adjust the date that much in one command. Setting it back one day works:

date
Sun Jan 29 10:21:29 AM CST 2119
~ $ sudo date --set='2119-01-28 10:21:10'
Sat Jan 28 10:21:10 AM CST 2119
~ $ date
Sat Jan 28 10:21:11 AM CST 2119

I've been running on Parallels Intel for years with Ubuntu and never seen this so I have to think it's an ARM issue with Parallels.

Any ideas? At this point I'd be happy if I could just run a command to manually change the clock to the right time.

Thanks
Brian
 
I've been having this problem with Ubuntu 24.04 as well. Fortunately for me, it does not impact my workflow drastically because I can rollback to an earlier snapshot without losing much. The first time it happened, I noticed in the kernel log that there was an array index out of bounds exception in what appeared to be some bit of parallels code, judging by the function name. Regrettabely, I did not know about this forum at the time, else I would have posted the details. I figured the issue had to do with some parallels tools time sync, so I disabled time-sync, and installed ntpd instead. Today, the issue happened again, immediately after an auto-snapshot was taken. I rolled back to the earlier snapshot and the problem was gone again. If/when it happens again, I'll be sure to post the kernel stack trace.
 
I just realized that when I upgraded to the latest Parallels and MacOS version, I also disabled Smart-Guard based on some of the comments in this thread. My uptime is 7 days now without the issue. It seems that there could be several causes.
 
I just realized that when I upgraded to the latest Parallels and MacOS version, I also disabled Smart-Guard based on some of the comments in this thread. My uptime is 7 days now without the issue. It seems that there could be several causes.
So it could be the pause and resume when creating a snapshot?
 
I have the exact same issue. It started when I upgraded to the latest macOS major update 15.0.1

Before that it never happened.

It happens very reliably when a snapshot is taken.

If I manually, or an auto-snapshot, takes place - the VM will suddenly corrupt and set the year into the future.

It will need restarting the VM to fix the time, but the VM will be permanently damaged (for example the MOTD message is cached and now its cached for 95 years in the future so never updates and now MOTD messages are broken). Some can be fixed, but its a massive hassle. So this is a very serious issue.

If the VM is shutdown, a snapshot can be taken. If a snapshot is taken while the VM is running the clock runs wild.

I have had to disable auto-snapshots, which I am not happy about.

Please Parallels will you instruct us if you can reproduce and if a fix is being worked on?

I have tried using the Mac/Linux VM sync time setting both on and off.

Arm64 ubuntu 24.04 AND 22.04 both tested with issue. Parallels 19 and 20 BOTH tested and have the issue. Must be MacOS 15.0.1. Prior macOS was fine.

To reproduce just use macos 15.0.1 and take a live snapshot of a running VM and look at the clock.

TO users effected by this, you may need to develop some find commands to look for files created >2024 and track them all down. Delete caches, rebuild or reinstall anything else. I hope your VM is not permanently broken. If you do have a snapshot, try and restore it but do not let it power up, as the break happens after it comes back from pause, and it actually should be fine in the snapshot if you can power it down after restore fast enough to avoid any damage.
 
There is a new Parallels update out now, 20.1.1, and also macOS 15.1. It's still a total mess. My time switched two times during the upgrade to 20.1.1 and presumably during the Parallels tool upgrade. Entirely unrelated, the only silver lining is that I think after three years or more, the arm64 version of Windows 11 no longer constantly stutters audio, making it somewhat usable. I'm hoping either Apple, Parallels, or Microsoft did something to fix that. The release notes never say so I lack confidence it'll stay working.
 
still having this issue, sometimes after VM resume system time jumps into the future:
Code:
timedatectl
               Local time: Wed 2120-01-03 15:10:08 CET
           Universal time: Wed 2120-01-03 14:10:08 UTC
                 RTC time: Tue 2024-11-12 10:14:42
                Time zone: Europe/Madrid (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no
 
Just discovered i have this issue on my Ubuntu 22.04 VM, after ugrading to Sequoia, al lnetworking from the vm just broke. Paralells suggested installing the parallels tools, eventually reinstalling Parallels fixed the networking issue, but now the time is also set to the year 2120 and nothing i try can fix this. Its causing all sorts of problems.....

Parallels - give us a solution PLEASE!
 
Yeah, tech support hasn't been helpful at all. I suggest everyone open cases. They don't seem to be escalating to development because not enough people are complaining. Terrible product support from Parallels.
 
I have same issue on ubuntu 2404 parallels. I turn off timedatectl
Code:
sudo timedatectl set-ntp no
sudo apt update
sudo apt install ntp
ntpq -p
then you reboot, the issue will gone
 
I started having an issue immediately after updating to parallels version 20.2.1.
I am running Ubuntu server in a VM and the time is now jumping to January 25th, 2120.
I have tried turning off the time sync with the mac and set the time in unbuntu's command line.
It is fine till I log out, when it then jumps around 96 years into the future.
 
I have this issue in both parallels 19 and 20. I tried all variations of disabling timectl, ntp, etc. the only thing that has stopped it is disabling smart guard snapshots.
 
I have same issue since updated to 20.1.2. Any permanent solution from parallels?
It seems to be an Ubuntu issue.
The list of time zones gets damaged/cleared and it has perhaps two time zones.
https ://askubuntu.com/questions/1528949/time-setting-problems-with-ubuntu-24-04
 
This time set in future give us all sort of problem. Mysql crash, all the log rotation stopped and log file size increased since current log file set in future. Anyone experiencing other issue?
 
Back
Top