Description of problem: If one have virtual machines with outstanding configuration changes, which require the virtual machine to reboot and the Cluster CompatibilityVersion will be upgraded to a newer version, it will overwrite the change and will use the current active configuration instead. Version-Release number of selected component (if applicable): ovirt-engine-4.2.6.4-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Make change to virtual machine (ex. increase iothread through api-call) 2. increase cluster version Actual results: The change is lost on upgrade cluster CompatibilityVersion Expected results: Beside the new ClusterCompatibility Version, the change should also included in the next_run configuration. If not possible, Customers should made aware if increase Cluster Version on running virtual machines, any configuration change which is not already applied will be lost. Additional info: [root@rhhi ansible]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibilit y_version from vm_static where vm_name='faye-pulanco.crazy.lab'" num_of_io_threads | custom_compatibility_version -------------------+------------------------------ 0 | (1 row) [1]: made change of iothreads ====================== [root@rhhi ansible]# ansible localhost -m ovirt_vms -e @cred.yml --args='auth={{ ovirt_auth }} name=faye-pulanco.crazy .lab io_threads=1' [2]: verify the change ================ [root@rhhi ansible]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -t -c "select vm_configuration from snapshots where snapshot_type='NEXT_RUN' and vm_id=(select vm_guid from vm_static where vm_name='faye-pulanco.crazy.lab');"| cut -c 2- | xmllint --format - | grep -E "CompatibilityVersion|NumOfIoThreads" <NumOfIoThreads>1</NumOfIoThreads> <ClusterCompatibilityVersion>4.1</ClusterCompatibilityVersion> [3]: increase ClusterCompatVersion using UI and verify the Change! [root@rhhi ansible]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -t -c "select vm_configuration from snapshots where snapshot_type='NEXT_RUN' and vm_id=(select vm_guid from vm_static where vm_name='faye-pulanco.crazy.lab');"| cut -c 2- | xmllint --format - | grep -E "CompatibilityVersion|NumOfIoThreads" <NumOfIoThreads>0</NumOfIoThreads> <ClusterCompatibilityVersion>4.2</ClusterCompatibilityVersion> ==> the prior change is reverted.
I would suggest to document the behaviour, aka telling the customer to update the cluster compatibility level once all pending changes have been applied as otherwise the changes will be lost. @Michal: Thoughts?
(In reply to Martin Tessun from comment #1) > I would suggest to document the behaviour, aka telling the customer to > update the cluster compatibility level once all pending changes in admin guide we say "After you update the cluster’s compatibility version, you must update the cluster compatibility version of all running or suspended virtual machines by restarting them from within the Manager" I agree it could be more verbose and talk about implications on configuration changes, suggest to do it at earliest convenient maintenance window, etc It's also fixable in code, but updating the NEXT_RUN instead of active configuration should still be discouraged as it increases the likelihood of failing to apply it later.
My suggestion to this would be to don't allow increase of cluster’s compatibility version if there are outstanding configuration changes of running virtual machines. This also needs to be documented in update guide, that's impossible to perform the upgrade, if there are VMs left, which require a restart. That would prevent customers from unwanted behavior.
(In reply to Steffen Froemer from comment #3) > My suggestion to this would be to don't allow increase of cluster’s > compatibility version if there are outstanding configuration changes of > running virtual machines. > > This also needs to be documented in update guide, that's impossible to > perform the upgrade, if there are VMs left, which require a restart. > > That would prevent customers from unwanted behavior. Ack. Sounds good to me.
it does sound to me too restrictive though.
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
sync2jira
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3247