Skip to main content
Unix & Linux

Return to Answer

Commonmark migration
Source Link
Community Bot
Community Bot
  • 1

background

#background OnOn most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

Answer

###Answer InIn a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

 

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Related:Tricking the VM BIOS RTC to set a time

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

 

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Related:Tricking the VM BIOS RTC to set a time

background

On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

Answer

In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Related:Tricking the VM BIOS RTC to set a time

added 522 characters in body
Source Link
user232326
user232326

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Related:Tricking the VM BIOS RTC to set a time

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Related:Tricking the VM BIOS RTC to set a time

added 522 characters in body
Source Link
user232326
user232326

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

#background On most computers, at booting time:

  • The time is read from the RTC (which has been working from a battery while the computer was off).
  • Some adjustment might be added depending on what was stored on a file the last time the computer was shut-down.
  • That is the new "hardware time", and the time of the computer.
  • Until some time client (sntp, ntpdate, ntpd, chronyd, etc), or hardware clock (GPS) updates that time to a better estimate.

If, for any reason, the RTC battery fails, the time at boot could be wildly off the correct time.

###Answer In a virtual computer, the RTC is not a real RTC but a virtual RTC, the time is read from the host computer time. If the host time is off, the boot time of the VM will be also wildly off. The same as if the RTC battery got bad.

That's why this happens (what you copied from the VM):

root@host001:~# timedatectl
                      Local time: Fri 2020-05-08 16:00:59 UTC  
                  Universal time: Fri 2020-05-08 16:00:59 UTC  
                        RTC time: Fri 2020-05-08 08:57:03  
                       Time zone: UTC (UTC, +0000)  
       System clock synchronized: no  
systemd-timesyncd.service active: no  
                 RTC in local TZ: no

The RTC time is different than real, or local, or UTC.

Solution

Ensure the time of the host is correct. Either use ntp or GPS there.

For example, from Qemu man page:

-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]

By default the RTC is driven by the host system time. This allows using of the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP.

Source Link
user232326
user232326