On 24. 9. 2021, at 11:28, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

On Fri, Sep 24, 2021 at 11:05 AM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:

On 24. 9. 2021, at 9:43, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:

BTW: there are two things that are not so clear to me:
1. Is this only impacting SHE environments or is it a general problem also with external standalone engine ones?

it’s affecting all VMs, in standalone envs engine is not a VM

Of course... I meant if I have standalone external engine that manages VM1 and VM2 and I update from 4.4.7 to 4.4.8-5, will VM1 and VM2 impacted?
I presume yes from your answer

yes

2. Is it correct to say that if I already upgraded in the past to 4.4.7 and at that time I updated my cluster level from 4.5 to 4.6 (both in case of SHE and external engine), then I shouldn't have this kind of problems if then I updated to the impacted 4.4.8-5 version? And then I can go and continue updating to 4.4.8-6 without any risk/problems?

the cluster level update problem is just a side effect of the time zone missing. You will see problems in other flows, or next time you upgrade to 4.7 if we ever have one.

So I don't understand if I need to rollback or if I can anyway update to 4.4.8-6 and eventually modify from database.
By the way in my env all my VMs in 4.4.7 had timezone set to the default value "Etc/GMT". Does this imply no impact at all?

you should set it to something.

It sets it to default on its own whenever that VMs get "touched" in some way, and since Etc/GMT is the default you won't really notice much, but there might be places where it may cause issues (dunno, OVF export maybe)

Eg on another environment I see that after updating from 4.4.7 to 4.4.8-5 and then 4.4.8-6, in Web Admin GUI if I select a VM, in general subtab I have for 2 of them

Hardware Clock Time Offset: Etc/GMT

for all the other ones there isn't the "Hardware Clock Time Offset" item...
Fot these VMs under edit virtual machine -> system -> Hardware Clock Time Offset I see they have the value
default:(GMTZ) Greenwich Standard Time

and from database point of view:

engine=# select time_zone,count(*) from vm_static group by time_zone;
time_zone | count
-----------+-------
| 18
Etc/GMT | 2
(2 rows)

engine=#

engine=# select vm_name from vm_static where time_zone='Etc/GMT';
vm_name
-----------
testcl1
c76client
(2 rows)

yeah, so those are vms which you have probably edited and saved in the meantime.

engine=#

So I should use the db statement too, correct?

Hard to say, to minimize changes HE might be enough as long as you do not see any other issues anywhere else and you would use the default anyway.