[Info-vax] clock problems with OpenVMS x86 on VirtualBox

[Johnny Billquist]

On 2023-05-13 01:32, Gary Sparkes wrote:
> On Friday, May 12, 2023 at 5:56:13 AM UTC-4, Johnny Billquist wrote:
>> On 2023-05-12 01:02, gah4 wrote:
>>> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, Craig A. Berry wrote:
>>>> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
>>>> Ventura 13.3.1 (a). The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
>>>> Intel Core i9. The clock isn't working right, most easily seen by the
>>>> fact that the following two commands were typed exactly one minute apart:
>>>
>>>> $ sh time
>>>> 5-MAY-2023 19:07:35
>>>> $ sh time
>>>> 5-MAY-2023 19:07:45
>>>
>>> I haven't thought about this recently.
>>>
>>> As well as I know it, many OS were designed to know about emulators,
>>> and virtual machines, and virtual machines to know about client systems.
>>>
>>> The OS should be able to request the right time from VirtualBox.
>> That is something you could/would do at boot time to get initial time,
>> but not after that.
>> During normal operation, most OSes uses a clock interrupt at a known
>> frequency, and this is in turn used to update the wall clock in the OS.
>> There are some tickless operating systems - mostly embedded RTOS stuff
>> where you want to reduce power consumption, but otherwise this is how
>> you normally do stuff, since you want to schedule all kind of things
>> based on time, and it would make no sense to have a VM go out and read
>> the host time hundreds of times per second as a way of just polling to
>> get time.
> 
> Virtualization aware OSes *Will* update/request host time at specified intervals.
> 
> Not just at boot.

That don't make much sense, and I've not see any who do it. But you 
might be right. And that would probably cause some interesting conflicts 
with most OSes that tend to have an NTP daemon running, which corrects 
local time on the OS as well.

> Most mainstream OSes have this capability to avoid VM time drift.

The VM drift is usually the responsibility of the VM itself, and not the 
host OS. And it's handled by the simple fact that clock interrupts are 
controlled by the VM, and can be monitored and tracked by the VM, so it 
knows if there is any drift in the first place.

> It can also be disabled, which is the recommended setting for Windows AD Domain
> controllers, for example - the PDC emulator hosting one does external time sync,
> all other DCs sync to that, and then you sync your hardware to those sources (the DCs)
> 
> All other guest VMs use host time sync. If the host's time drifts too far, you will
> have a Bad Day (tm) in a kerberos authentication environment because the guest
> VMs time will drift too. Without reboot. Because the guest VMs are hypervisor time aware
> unless you disable host time sync and/or don't install the VM tooling (if required, linux
> for example wouldn't need it if the hypervisor support is compiled into kernel for
> time sync to work)
> 
> So yes, it is done after boot. Constantly.

Yes. But usually not in the way you describe. At least not in any system 
I've seen.

What you normally have is the VM itself that corrects time though 
interrupt generation so that the guest OS is pretty much running the 
same time as the host. However, the guest OS usually also have NTP 
running (or some other time synchronization protocol), which are 
adjusting time, since there can still be drift because the host might 
not have correct time, and the VM might not be completely successful in 
getting clock interrupts at the correct rate over time to the guest.

   Johnny