W2K19 Server Guest Not Syncing Time with W10-64 Host

[louisjjames]

Host: Windows 10 Pro / Version 2004
Guest: Windows Server 2019
VirtualBox 6.1.16 r 1409961 (Qt5.6.2)

The W2K19 Server (Guest) running on the W10Pro Host will not properly set the time. The HOST is on Central but the Guest changes to Pacific no matter what I do. I have done the following:

* Changed the Guest to Set Time Automatic off / Set Time Zone Off / Adjust for Daylight Savings Off / Set the time - NO LUCK
* Used the command line vboxmanage setextradata "W2K19 Server" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 0
* Used the same command with a 1 at the end

I have no idea what else to try. Would be grateful for any thoughts and help.

Thank you

Louis

[scottgus1]

Let's check for time-control settings in the guest 'recipe' file:

Please right-click the guest in the main Virtualbox window's guest list, choose "Show in Explorer/Finder/File Manager". In the window that opens, zip the guest's .vbox file, and post the zip file, using the forum's Upload Attachment tab.

[louisjjames]

Let's check for time-control settings in the guest 'recipe' file:

Scottgus1:
Thank you for helping. Attached is the ZIP file

I've even added the line:

<ExtraDataItem name="VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" value="0"/> to the VDI file with no success.

I look forward to your discovery. Thank you.

[scottgus1]

The only thing I see in the guest related to time is the command you ran. (You might want to undo it, btw.)

FWIW websearching "windows OS keeps reverting to different time zone" shows this happens on real PCs too, indicating it's a problem with Windows sometimes. Some of the results, especially on the non-Microsoft sites , might help to disable Windows's auto-time-zone picker and let you set it manually.

I think your Windows OS has a glitch in it.

Try mackling a new guest and see if the same problem happens.

[fth0]

Guest: Windows Server 2019

Please try if setting System > Acceleration > Paravirtualization Interface to Hyper-V makes a difference.

[louisjjames]

Guest: Windows Server 2019

Please try if setting System > Acceleration > Paravirtualization Interface to Hyper-V makes a difference.

Good Morning:

Firstly, I created a NEW VM and the problem continues. I also made the change on Paravirtualization with no change. I'm stumped.

[mpack]

Unless the time is random then it isn't being plucked out of thin air, so it should be fairly simple to establish that the Windows guest is configured for the wrong time zone and is therefore applying the wrong hourly offset to the UTC provided by the host. Any failure of Windows to respond as expected to a time zone change should be taken up on a Windows forum!

[louisjjames]

Unless the time is random then it isn't being plucked out of thin air, so it should be fairly simple to establish that the Windows guest is configured for the wrong time zone and is therefore applying the wrong hourly offset to the UTC provided by the host. Any failure of Windows to respond as expected to a time zone change should be taken up on a Windows forum!

Definitely not a Windows Issue and I've discovered the fix. It's simple and regrettably all the instructions found failed to mention one time. REBOOT the HOST. All the information suggested rebooting the GUEST but never the Host System.

Here's the Solution:

1.- Shut Down the VM (Silly as that sounds, it's important)
2.- In the .Vbox config file add "<ExtraDataItem name="VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" value="1"/> in the ExtraData section
3.- Save the file
4.- Reboot the host ( I never did that. Turns out it's critical)
5.- Start the VM
6.- Turn OFF "Set Time automatically"
7.- Turn OFF "Set Time zone Automatically"
8.- Change the Time
9.- IGNORE the Time Zone (My Time Zone is Central but the VM insists on Pacific)
10.-- Turn ON Adjust for Daylight Savings Time
11.- Reboot the GUEST
12.- Check the Time.

I was doing ALL the steps except for Step 4.

HERE'S ANOTHER IMPORTANT PART. Because I was NOT rebooting the host, Oracle VirtualBox was rewriting my .vBox file. Each time I would change it, (and the corresponding .vbox-prev,) it would rewrite both back to the prior config. That's definitely not Windows but VirtualBox.

Amazingly, there is NO problem with a Windows 7 Ultimate VM Guest. Who knows why??

In any case, it seems to be solved. YAY!!!

Thank you to everyone for your kind help.

[scottgus1]

Oracle VirtualBox was rewriting my .vBox file. Each time I would change it, (and the corresponding .vbox-prev,) it would rewrite both back to the prior config.

This is known behavior. Virtualbox's VboxSVC service stores all .vbox file contents in memory and overwrites existing .vbox files with memory contents as needed. Which probably explains why this:

I've even added the line:

<ExtraDataItem name="VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" value="0"/> to the VDI file with no success.

didn't work. I suspect you were adding that line by inserting it into the .vbox and .vbox-prev in a text editor. Virtualbox will overwrite it. In fact there's a warning at the top of both files that says Virtualbox will overwrite manual edits.

Using the correct 'vboxmanage' command gets around the overwrite so the change stays. (There is no way to properly 'vboxmanage'-edit the .vbox-prev file, thus I deduce that you must have been manually editing the files, thus losing the manual edits and having them not take effect.)

1. Shut Down the VM (Silly as that sounds, it's important)

If you also shut down all other Virtualbox windows and allow the VboxSVC service to die off, then this:

2.- In the .Vbox config file add "<ExtraDataItem name="VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" value="1"/> in the ExtraData section (thus ignoring the warning at the beginning of the file hint hint)

would be allowed to stay in place.

The safer way to insert these edits and abide by posted warnings is to use command-line 'vboxmanage'. The edits will stick regardless of the Virtualbox service state, and a host reboot would then not be necessary.