Time sync issues on silicon mac running Ubuntu 22 VM
- Thread starter BrianD12
- Start date
-
- Tags
- linux linux guest time sync ubuntu
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.
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.
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.
I've disabled SmartGuard until this issue is resolved.
Hello,
Indeed, this is a known issue which is currently being investigated by our Development Team.
Once there is a response from them - whether it is a request for additional information, a workaround, or a permanent fix - we will let you know.
In addition, you may also subscribe to the following article (Click Get Updates -> Subscribe) to be notified when the new update is released and see the list of changes.
Thank you.
Indeed, this is a known issue which is currently being investigated by our Development Team.
Once there is a response from them - whether it is a request for additional information, a workaround, or a permanent fix - we will let you know.
In addition, you may also subscribe to the following article (Click Get Updates -> Subscribe) to be notified when the new update is released and see the list of changes.
Thank you.
This still seems borked for me. My temp fix is as follows, which I do after every Parallels Tools update. All run under root
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:
chmod -x /usr/lib/parallels-tools/tools/tools-arm64/bin/prltimesync
chmod -x /usr/bin/prltimesyncThis 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 -gqIt 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
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.
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.
I have a tentative solution which is in the form of a workaround:
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
- Apple M4 Pro with Tahoe 26.2
- Parallels Desktop 26 for Mac Pro Edition
- Ubuntu 24.04 LTS
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
I can confirm that this no fix in my case. The only different in my setup is that I am running Ubuntu 22.04 LTS instead of 24.04.
Are you still good on 24.04?
Are you still good on 24.04?