Bug 773323

Right, we do not have any specific check for virtual hardware at this place.

And I although thought that local time should be the virtual hw defaul, but actually in VirtualBox, I have correct time from start when I use UTC. So maybe there's some difference?

Werner, what do you think?

AFAIK you can configure this in the setup of VirtualBox on the host system
before starting any client system.

Using local time for CMOS even for virtual systems is a BUG.  The natural choise
is UTC the Universal Time Coordinated as network as well as the kernels system clock is in UTC.

Michal?

In the case of vmware it doesn't read the cmos clock of the host, which in my case it is UTC; it reads the clock from the host system time, which is local time (it can be seen in the bios setup display). That is the reason, the cmos clock it emulates is in sync with the host system clock, not with the real cmos clock.

Related settings:

tools.syncTime = "TRUE"

This makes the guest tools keep time in the guest synced to the host. Without that the time shifts.


I can not talk about vbox.

Then this is a bug of vmware!  It should not use the user space clock but the kernels system clock which is in UTC by definition.  To see from user space which clock the kernel uses simply use:

     TZ=UTC date

(In reply to comment #4)
> Then this is a bug of vmware! 

Or a feature. It is designed that way, and we have no control of it. And vmware products are widely used with Linux hosts, both oS and SLES, so it make sense to take them into account.

I agree that it would be better that vmw used the system UTC clock, though.

(In reply to comment #5)

Not using a hard reference clock but a dynamic clock is a BUG, regardless of the OS. Universal Time Coordinated is the worls wide reference and e.g. the timezone data base below /usr/share/zoneinfo and the network depends on it.

Issue is unchanged in 12.3

This is a bug in VMWARE, it should respect the real configuration

Issue is unchanged in 13.1
IMO, it is an openSUSE installation BUG.

Werner, any idea who could take care of the real issue here?

IMHO vmware has a bug as it does not resprect the system default that is if /etc/adjtime shows UTC in its last line vmware has to use that.

@Carlos: Why do you think this is an openSUSE installation BUG?

Do you really think you can tell the worldwide experts in virtualization how they should do things?

Instead of trying to convince them to change how they do things (and remember they use the same binary on all distributions), would it not be easier for yast to abstain of making the recommendation to use another clock when yast sees it is a vmware install (which it does elsewhere, as it automatically installs the virtualization guest tools)?

The proposal is simply to remove the popup for vmware client installs, because it confuses OUR users, or to change its text.

I'm not proposing that yast automatically chooses the clock to use.


Yes, of course it would be best if vmware used the system clock. Why don't SUSE, as a company, talk with them about it?

Hmmm ... please explain how ths is solved e.g. on Debian or RedHat?  I'm pretty sure that both uses UTC as default in their setups.  IMHO VMWare is third party and we have no maintainer for this.

Beside this with google search https://www.google.de/search?q=VMWare+UTC+CMOS&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&gws_rd=cr&ei=GcZKUpuqKc6f7Aag54GwBg shows the link

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

which is VMWare documentation with:

> Virtual Hardware clock configuration
> When configuring the Linux guest operating system, if you are given a choice
> between keeping the “hardware” clock (that is, the virtual CMOS time of day
> clock) in UTC or local time, choose UTC. This avoids any confusion when your
> local time changes between standard and daylight saving time (in England,
> "summer time").
> 
> For additional information, see <Timekeeping in VMware Virtual Machines.>

and AFAICS from the link http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf  below <Timekeeping in VMware Virtual Machines.>

> Specifically, the CMOS TOD clock shows UTC as kept by the host operating
> system software, plus an offset. The offset from UTC is stored in the virtual
> machine’s nvram file along with the rest of the contents of the virtual
> machine’s CMOS nonvolatile memory. The offset is needed because many guest
> operating systems require the CMOS TOD clock to show the time in the current
> local time zone, not in UTC. When a new virtual machine is created (or the
> nvram file of an existing virtual machine is deleted) and it is powered on,
> the offset is initialized, by default, to the difference of the host
> operating system’s local time zone from UTC. If software running in the
> virtual machine writes a new time to the CMOS TOD clock, the offset is
> updated.

therefore I've the question: Do you have configiured you VMWare setup to assume UTC in the CMOS clock of your host system?

From page `INFORMATION GUIDE / 10':

<cite>
You can force the CMOS TOD clock’s offset to be initialized to a specific value at power on. To do so, set the option rtc.diffFromUTC in the virtual machine’s .vmx configuration file to a value in seconds. For example, setting rtc.diffFromUTC = 0 sets the clock to UTC at power on, while setting rtc.diffFromUTC = -25200 sets it to Pacific Daylight Time, seven hours earlier than UTC. The guest operating system can still change the offset value after power on by writing a new time to the CMOS TOD clock.
You can also force the CMOS TOD clock to start at a specified time whenever the virtual machine is powered on, independent of the real time. To do this, set the configuration file option rtc.startTime. The value you specify is in seconds since Jan 1, 1970 00:00 UTC, but it is converted to the local time zone of the host operating system before setting the CMOS TOD clock (under the assumption that the guest operating system requires the CMOS TOD clock to read in local time). If your guest operating system is running the CMOS TOD clock in UTC or some other time zone, you should correct for this when setting rtc.startTime.
</cite>

(In reply to comment #15)
> Hmmm ... please explain how ths is solved e.g. on Debian or RedHat?  I'm 
> pretty sure that both uses UTC as default in their setups.  IMHO VMWare is 
> third party and we have no maintainer for this.

I have no idea how other distributions handle this. Obviously they are Linux, so the clock will be handled similarly (ie, system clock in UTC),


I'm sure SUSE is interested that vmware works well with SUSE distros, either as host or as clients. I know they have agreements.


> which is VMWare documentation with:
> 
> > Virtual Hardware clock configuration
> > When configuring the Linux guest operating system, if you are given a choice
> > between keeping the “hardware” clock (that is, the virtual CMOS time of day
> > clock) in UTC or local time, choose UTC. This avoids any confusion when your
> > local time changes between standard and daylight saving time (in England,
> > "summer time").

Well, vmplayer works wrong with that setting.


> therefore I've the question: Do you have configiured you VMWare setup to 
> assume UTC in the CMOS clock of your host system?

It has the default settings, I don't touch them.

> rtc.diffFromUTC = 0 sets the clock to UTC at power on, while setting

No such variable in the entire /etc/vmware tree, or the OpenSUSE 12.3.vmx file.

I'll try creating it.

(In reply to comment #17)

> No such variable in the entire /etc/vmware tree, or the OpenSUSE 12.3.vmx file.
> 
> I'll try creating it.

It would be a big win it this works well ... and it would one point more to add to http://en.opensuse.org/SDB:Configuring_the_clock

Thank you!

No such luck :-(

I created that variable, set to zero, and booted that virtual machine. The output of date matched the host date, which should not be the case after the change.


eleanor3:~ # hwclock --debug
hwclock from util-linux 2.21.2
Using /dev interface to clock.
Last drift adjustment done at 0 seconds after 1969
Last calibration done at 0 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2013/10/01 14:45:27
Hw clock time : 2013/10/01 14:45:27 = 1380631527 seconds since 1969
2013-10-01T14:45:27 CEST  -0.070763 seconds
eleanor3:~ # date
Tue Oct  1 16:45:28 CEST 2013
eleanor3:~ # 



It is also interesting that when the local clock changes from summer to winter, the guest has the correct time. If the clock had a fixed time difference (as per rtc.diffFromUTC), the guest clock would not match.

Notice that, AFAIK, the guest clock is kept in sync by the guest tools, which probably means that it depends on the host user (not system) time. It is not recommended to run NTP on the guest (so says their documentation).

Q: What happens if you start the VMWare with TZ=UTC in its environment?
   (IMHO this should cause that VMWare uses the kernels system clock).

It is ignored :-(

It might be taken from the init.d service.

Curious...

Ok ... then at the very first line in the init.d service but after sourcing any file try to add two lines

   TZ=UTC
   export TZ

... maybe then the kernels time zone is used

Oops. sorry, I forgot about this.

I'm testing with vmware® player, 5.0.2, which is not the latest version (I believe there is a version 6.x).

I edited "/etc/init.d/vmware" in the 12.3 host system. At about line 75, I now have:

#
# Are we running in a VM?
#
vmwareInVM() {
   "$BINDIR"/checkvm >/dev/null 2>&1
}

#CER - https://bugzilla.novell.com/show_bug.cgi?id=773323#c22
TZ=UTC
export TZ

I booted a virtual machine from the 13.1 64 iso image. I reach the clock and time screen. With the hardware clock set to UTC ticked, the clock shows "19:18", and without 18:18. None is the correct time for Spain. as displayed by the host:

cer@Telcontar:~> date --iso=seconds ; date --universal --iso=seconds
2014-01-08T17:21:02+0100
2014-01-08T16:21:02+0000  <-- UTC

So it is not working. I restart vmware service, remove that addition, and repeat test for comparison.

With the tick box ticked, the window displays 19:24. Without, it shows 18:24 - ie, the same thing as before editing the service file.

There is a new problem in 13.1 install disk, as no combination displays the correct wall time. However, unticking the box and really installing results on the correct time in the running system.

Going to a terminal (install live system) also says that UTC is 18:30 (which is wrong, current UTC is 16:30)

Well, I do not think this has anything to do with YaST, which does not do any specific check regarding VM during the installation (at least not to read the time).

When you install the virtual machine, and in YaST I select "local time", YaST pops up a big warning against this action. But this action is the correct one in this case, ie, the one that works.

The only thing I'm requesting is that YaST do not tell the user to change to UTC. Only that. Abstain from popping up that (wrong) warning.


The point of this report is not whether Vmware does things one way or the other. They do things as they do, and we know that. When YaST detects it is running in a virtual vmware machine (and it does, as it automatically installs the correct guest tools and the appropriate video drivers automatically), it could, should, also raise a flag or whatever you do so that clock source is automatically selected to local time, and the warning disabled.

I'll *never* support a broken setup for standard system without any need.  That is that teh default remains on UTC for CMOS clock. If vmware does require a broken setup (which IMHIO should reported to UPSTREAM) then YaST2 has to handle this.

(In reply to comment #25)

> The only thing I'm requesting is that YaST do not tell the user to change to
> UTC. Only that. Abstain from popping up that (wrong) warning.

Well, we could probably do that - for vmware. AFAIS, for other vertialization methods (like VirtualBox) the situation is different.

Ladislav, could you add the appopriate check to the place where the popup in question is raised? 

In current code, there's check for

!Timezone.windows_partition && hwclock_s == :hwclock_localtime

in include/timezone/dialogs.rb, line 904

Steffen, how could I detect VMware virtualization? AFAIK libhd supports only XEN detection...

Yes, it can detect vmware. There is an internal flag hd_data->flags.vmware that
gets set when you probe the system type. 'hwinfo --sys' shows it. Not sure
if the yast hardware agent read the flag, though.

Fixed in yast2-country-3.1.19 (https://github.com/yast/yast-country/pull/51/files) - added VMware detection, Yast should propose "local" time and should not display the warning pop-up when using "local" time.

Please test it later in Factory or Tumbleweed.

SUSE-RU-2015:1033-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 773323,903069,915938
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12 (src):    yast2-hardware-detection-3.1.7-6.1
SUSE Linux Enterprise Desktop 12 (src):    yast2-hardware-detection-3.1.7-6.1