6:23 a.m.
On Mon, Aug 15, 2022 at 10:05 AM Yedidyah Bar David <didi(a)redhat.com> wrote:
On Fri, May 27, 2022 at 11:40 AM Alexandr Mikhailov <asm(a)pioner.kz> wrote:
>
> Hi!
> Just uprgaded from 4.4. to 4.5. Had all the problems with this update, such as
postgresql-jdbc version and with stripeCount in cli.y . But I managed it, everything works
more or less.
> Now I cannot raise the Cluster compatibility level. The problem is that increasing
the level tries to change something in the HE configuration but cannot.
> This is error massage:
> Error while executing action: Cannot update cluster because the update triggered
update of the VMs/Templates and it failed for the following: HostedEngine. "There was
an attempt to change Hosted Engine VM values that are locked." is one of the
error(s).
>
> To fix the issue, please go to each VM/Template, edit, change the Custom
Compatibility Version (or other fields changed previously in the cluster dialog) and press
OK. If the save does not pass, fix the dialog validation. After successful cluster update,
you can revert your Custom Compatibility Version change (or other changes). If the problem
still persists, you may refer to the engine.log file for further details.
> If i trying to edit HE machine without changing anything i se next error: There was
an attempt to change Hosted Engine VM values that are locked/ I think this is linked
issues.
> Log from engine log when i trying to update Cluster version:
> 2022-05-27 14:20:54,410+06 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-212)
[1b8b6b78] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Ca
> nnot update compatibility version of Vm/Template: [HostedEngine], Message: There was
an attempt to change Hosted Engine VM values that are locked.
> Log from engine log when i trying to save HE configuration without any changing:
> 2022-05-27 14:34:10,965+06 INFO [org.ovirt.engine.core.bll.UpdateVmCommand]
(default task-220) [9cdfe99b-b7a1-46a4-ab3f-fc110b939f08] Lock Acquired to object
'EngineLock:{exclusiveLocks='[HostedEngine=
> VM_NAME]',
sharedLocks='[4d6a0ffb-a221-4ef8-9846-6ada7690e74a=VM]'}'
> 2022-05-27 14:34:10,968+06 WARN [org.ovirt.engine.core.bll.UpdateVmCommand]
(default task-220) [9cdfe99b-b7a1-46a4-ab3f-fc110b939f08] Validation of action
'UpdateVm' failed for user admin@internal-auth
> z. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,VM_CANNOT_UPDATE_HOSTED_ENGINE_FIELD
> 2022-05-27 14:34:10,969+06 INFO [org.ovirt.engine.core.bll.UpdateVmCommand]
(default task-220) [9cdfe99b-b7a1-46a4-ab3f-fc110b939f08] Lock freed to object
'EngineLock:{exclusiveLocks='[HostedEngine=VM_
> NAME]', sharedLocks='[4d6a0ffb-a221-4ef8-9846-6ada7690e74a=VM]'}'
> It is not clear what is happening and what changes to the configuration are trying
to be saved and what to do about it. Help please.
On Sat, Aug 13, 2022 at 12:39 PM Alexandr Mikhailov <asm(a)pioner.kz> wrote:
>
> This is solution: update vm_static set time_zone='Etc/GMT' where
vm_name='HostedEngine';
Thanks for the update!
Arik/Liran - is this risky? If not, is it worth it to allow doing this
from the engine? And/or document this?
It's not risky, that's the way we proposed to work around an issue we
had with the timezones, see:
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/BQMHMKNLPANY...
That issue is fixed now but it sounds like a good idea to document
this somewhere as that fix doesn't prevent the issue from happening to
users that were already affected by that bug
Best regards,
--
Didi