+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1649685 +++ ====================================================================== Description of problem: If Clustercompatibility version is increased and the virtual machine is not rebooted instantly, an additional configuration change will persist the CustomCompattibilityVersion Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install RHV Cluster in Version 4.1 and start a VM in this cluster 2. Increase ClusterCompatibilityVersion to 4.2. The VM will be markes with outstanding config-change and CustomCompatibilityVersion is set on active configuration [1] 3. Make an additional configuration change through API. For example, iothreads=1 [2] 4. Check results [3] Actual results: The previous CustomCompatibilityVersion will be persisted and prevent the virtual machine from restarting. Expected results: The CustomCompatibilityVersion should not be persisted to old configuration in NEXT_RUN configuration Additional info: [1]: [root@rhhi ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibility_version from vm_static where vm_name='faye-pulanco.crazy.lab'" num_of_io_threads | custom_compatibility_version -------------------+------------------------------ 0 | 4.1 (1 row) [root@rhhi ~]# /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 CompatibilityVersion <ClusterCompatibilityVersion>4.2</ClusterCompatibilityVersion> [2]: [root@rhhi ansible]# ansible localhost -m ovirt_vms -e @cred.yml --args='auth={{ ovirt_auth }} name=faye-pulanco.crazy .lab io_threads=1' [3]: root@rhhi ansible]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibility_version from vm_static where vm_name='faye-pulanco.crazy.lab'" num_of_io_threads | custom_compatibility_version -------------------+------------------------------ 0 | 4.1 (1 row) [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 CompatibilityVersion <CustomCompatibilityVersion>4.1</CustomCompatibilityVersion> <ClusterCompatibilityVersion>4.2</ClusterCompatibilityVersion> (Originally by Steffen Froemer)
Seems the ansible fix of bug 1639894 wasn't entirely complete? Ondro? It took me some time to understand:) But the problem is that after step 2 the temporary CustomCompatibilityVersion is written to the NEXT_RUN which then cause problems when the changes are applied on reboot. The intended behavior is that during step 2 the NEXT_RUN is created (copied from current, and run through UpdateVmCommand to match the new cluster parameters) and the current running config is modified to CustomCompatibilityVersion=<old cluster version> and it's otherwise unchanged. That is then thrown away on reboot. (Originally by michal.skrivanek)
Well, I am unsure I understand. The fix in bug 1639894, is about the check if the update should be done, not doing the actual update. The PR which is solving it is here: https://github.com/ansible/ansible/pull/48286/ So if you want to update the VM and keep the old next_run configurations, you should pass next_run=true, if you want to remove all previsou configuration and do update to current configuration just pass next_run=False. (Originally by Ondra Machacek)
ah, it makes sense, actually. when the first change is done (by cluster update) it stores CustomCompatibilityVersion to the current config which is supposed to be overwritten later when next_run is applied. But if you make another permanent configuration change in the meantime it creates a new next_run which now contains everything from the current config - i.e. also CustomCompatibilityVersion. And then it's all wrong as on reboot it will get applied and becomes permanent. (Originally by michal.skrivanek)
(In reply to Steffen Froemer from comment #0) > [root@rhhi ansible]# ansible localhost -m ovirt_vms -e @cred.yml > --args='auth={{ ovirt_auth }} name=faye-pulanco.crazy.lab io_threads=1' Did you try to execute update with next_run=1 parameter? Does it work properly in this situation? Shmuel (Originally by Shmuel Melamud)
(In reply to Shmuel Melamud from comment #5) > Did you try to execute update with next_run=1 parameter? Does it work > properly in this situation? > Yes, after using the not already general available ovirt_vm module, I was able to update the system without causing an issue. But I'm not confirming this as solution for the initial problem. How a customer can be sure, he need to use this flag for his configuration change via API? Imagine there are different responsibilities for managing the ClusterUpgrade version and Configuration of virtual machines. In big old companies, those guys would not talk each other, so they would not know of the changes. In the end, this problem will be caused again. Are there plans to cover this? (Originally by Steffen Froemer)
(In reply to Steffen Froemer from comment #6) > Are there plans to cover this? Yes, I've already posted the patch. (Originally by Shmuel Melamud)
Shmuel, can you add proper doc text please? (Originally by michal.skrivanek)
Verified on: ovirt-engine-4.2.8.2-0.1.el7ev.noarch Steps: 1. Install RHV Cluster in Version 4.1 and start a VM in this cluster 2. Increase ClusterCompatibilityVersion to 4.2. The VM will be markes with outstanding config-change and CustomCompatibilityVersion is set on active configuration [1] 3. Make an additional configuration change through API. For example, iothreads=1 [2] 4. Check results [3] Results: In [1] and [2]: # /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibility_version from vm_static where vm_name='test'" num_of_io_threads | custom_compatibility_version -------------------+------------------------------ 0 | (1 row) # /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='test');"| cut -c 2- | xmllint --format - | grep CompatibilityVersion <CustomCompatibilityVersion>4.2</CustomCompatibilityVersion> <ClusterCompatibilityVersion>4.1</ClusterCompatibilityVersion> In [3]: # /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibility_version from vm_static where vm_name='test'" num_of_io_threads | custom_compatibility_version -------------------+------------------------------ 1 | 4.2 (1 row) # /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='test');"| cut -c 2- | xmllint --format - | grep CompatibilityVersion -:2: parser error : Start tag expected, '<' not found The CustomCompatibilityVersion did not persist to old configuration in NEXT_RUN configuration. The changes(iothreads and compatibility version) were set correctly.
Hi Shmuel, I'm not sure what should be said about this ticket in the Errata / Release Notes. Can you please verify the Doc Type and Doc Text? Thanks
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, 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/RHBA-2019:0343