On Sun, Nov 29, 2015 at 12:41 AM, Yaniv Dary <ydary@redhat.com> wrote:

Can you please open a bug to track this issue?
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
        8272306
Email: ydary@redhat.com
IRC : ydary
On Fri, Nov 13, 2015 at 9:34 PM, Paul Groeneweg | Pazion <paul@pazion.nl> wrote:
I checked version, I am running 1.0.11
I restarted, but still not showing info in the tab ( none of the VMs )
See screenshot: http://screencast.com/t/JejTsLAxuXw

Regards,
Paul Groeneweg

Hello in my case I have a clean installed 3.6.0 environment with self hosted engine.

I installed and configured a CentOS 7.1 guest and I'm able to see guest info.

See screenshot.

https://drive.google.com/file/d/0BwoPbcrMv8mvVVY4NUJiRU0wTU0/view?usp=sharing

But I do have the time zone problem.

I verified that my self hosted engine (I did the deploy through the provided appliance) was by default configured with UTC timezone.

I then changed it using inside its OS the command:

timedatectl set-timezone Europe/Rome

then I made global maintenance and restarted both the host and the engine.

I still had the exclamation mark.

Then I modified the VM inside the GUI in Edit VM --> System --> General . As you see in screenshot it was Etc/GMT and then Europe/Berlin.

And finally shutdown/power on (because reboot doesn't instantiate a new qemu/kvm process)

And now it is ok from an OS point of view andalso GUI point of view.

See:

https://drive.google.com/file/d/0BwoPbcrMv8mvSmp1QjVEMEVPQms/view?usp=sharing

I don't know if the update itself from 3.5 to 3.6 could have scrambled anything, but in my case all is ok if the various configurations involved match.

BTW: I noticed that the "Guest Info" visualized data are not so dynamic: sometimes if I do some changes, I have to click another tab (eg affinity groups) and then "Guest Info" again to be able to see updated values

host:

# timedatectl status ; ssh ractorshe "timedatectl status" ; ssh 10.4.4.29 "timedatectl status"

Local time: Sun 2015-11-29 16:27:49 CET

Universal time: Sun 2015-11-29 15:27:49 UTC

RTC time: Sun 2015-11-29 15:27:49

Timezone: Europe/Rome (CET, +0100)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: no

Last DST change: DST ended at

Sun 2015-10-25 02:59:59 CEST

Sun 2015-10-25 02:00:00 CET

Next DST change: DST begins (the clock jumps one hour forward) at

Sun 2016-03-27 01:59:59 CET

Sun 2016-03-27 03:00:00 CEST

SH Engine:

Local time: Sun 2015-11-29 16:27:51 CET

Universal time: Sun 2015-11-29 15:27:51 UTC

RTC time: Sun 2015-11-29 15:27:50

Timezone: Europe/Rome (CET, +0100)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: no

Last DST change: DST ended at

Sun 2015-10-25 02:59:59 CEST

Sun 2015-10-25 02:00:00 CET

Next DST change: DST begins (the clock jumps one hour forward) at

Sun 2016-03-27 01:59:59 CET

Sun 2016-03-27 03:00:00 CEST

Guest:

# timedatectl status

Local time: Sun 2015-11-29 16:28:07 CET

Universal time: Sun 2015-11-29 15:28:07 UTC

RTC time: Sun 2015-11-29 16:28:06

Timezone: Europe/Rome (CET, +0100)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: no

Last DST change: DST ended at

Sun 2015-10-25 02:59:59 CEST

Sun 2015-10-25 02:00:00 CET

Next DST change: DST begins (the clock jumps one hour forward) at

Sun 2016-03-27 01:59:59 CET

Sun 2016-03-27 03:00:00 CEST

A strange thing with guest is that it seems it starts wrong because if current time is 16:25 I notice right after boot that I get both the "!" inside the GUI and wrong timestamp inside OS (1 hour ahead):

# date

Sun Nov 29 17:25:41 CET 2015

# timedatectl status

Local time: Sun 2015-11-29 17:25:46 CET

Universal time: Sun 2015-11-29 16:25:46 UTC

RTC time: Sun 2015-11-29 16:25:46

Timezone: Europe/Rome (CET, +0100)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: no

Last DST change: DST ended at

Sun 2015-10-25 02:59:59 CEST

Sun 2015-10-25 02:00:00 CET

Next DST change: DST begins (the clock jumps one hour forward) at

Sun 2016-03-27 01:59:59 CET

Sun 2016-03-27 03:00:00 CEST

with apparently chronyd going to set time correctly detecting a huge step:

# systemctl status chronyd -l

chronyd.service - NTP client/server

Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)

Active: active (running) since Sun 2015-11-29 17:24:04 CET; 57min left

Main PID: 1354 (chronyd)

CGroup: /system.slice/chronyd.service

└─1354 /usr/sbin/chronyd -u chrony

Nov 29 17:24:04 racclient.inside.polimi.it systemd[1]: Starting NTP client/server...

Nov 29 17:24:04 racclient.inside.polimi.it chronyd[1354]: chronyd version 1.29.1 starting

Nov 29 17:24:04 racclient.inside.polimi.it chronyd[1354]: Linux kernel major=3 minor=10 patch=0

Nov 29 17:24:04 racclient.inside.polimi.it chronyd[1354]: hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2

Nov 29 17:24:04 racclient.inside.polimi.it chronyd[1354]: Frequency -3.865 +/- 0.865 ppm read from /var/lib/chrony/drift

Nov 29 17:24:04 racclient.inside.polimi.it systemd[1]: Started NTP client/server.

Nov 29 17:26:14 racclient.inside.polimi.it chronyd[1354]: Selected source 131.175.12.3

Nov 29 17:26:14 racclient.inside.polimi.it chronyd[1354]: System clock wrong by -3599.147583 seconds, adjustment started

Nov 29 16:26:15 racclient.inside.polimi.it chronyd[1354]: System clock was stepped by -3599.148 seconds

and after 1-2 minutes time is ok and I don't see any more the "!" in the ovirt admin gui

# timedatectl status

Local time: Sun 2015-11-29 16:27:09 CET

Universal time: Sun 2015-11-29 15:27:09 UTC

RTC time: Sun 2015-11-29 16:27:08

Timezone: Europe/Rome (CET, +0100)

NTP enabled: yes

NTP synchronized: no

RTC in local TZ: no

DST active: no

Last DST change: DST ended at

Sun 2015-10-25 02:59:59 CEST

Sun 2015-10-25 02:00:00 CET

Next DST change: DST begins (the clock jumps one hour forward) at

Sun 2016-03-27 01:59:59 CET

Sun 2016-03-27 03:00:00 CEST

but this walking ahead 1 hour right after boot seems still wrong to me.

Donna if it is a problem with CentOS 7.1 itself or oVirt.

Gianluca