Bug 1723578

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?

(Originally by Martin Tessun)

(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.

(Originally by michal.skrivanek)

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.

(Originally by Steffen Froemer)

(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.

(Originally by Martin Tessun)

it does sound to me too restrictive though.

(Originally by michal.skrivanek)

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

(Originally by Ryan Barry)

Verified on:
ovirt-engine-4.3.5.4-0.1.el7.noarch

Steps:
1. Create a 4.2 cluster.
2. Create a VM with iothreads=0.
3. Run the VM.
4. Verify iothreads:
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select num_of_io_threads,custom_compatibility_version from vm_static where vm_name='<VM_NAME>'"

5. Edit the VM to iothreads=1.
6. Verify next run change:
# /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='<VM_NAME>');"| cut -c 2- | xmllint --format - | grep -E "CompatibilityVersion|NumOfIoThreads"

7. Upgrade cluster to 4.3, the compatibility of the VM moved to 4.3.
8. Check next run again with the command of step 6.
9. Reboot VM.
10. Verify iothreads with the command of step 4.

Results:
In step 4 we have io threads disabled:
 num_of_io_threads | custom_compatibility_version 
-------------------+------------------------------
                 0 | 
(1 row)

After changing it, on next run we have(step 6):
    <NumOfIoThreads>1</NumOfIoThreads>
    <ClusterCompatibilityVersion>4.2</ClusterCompatibilityVersion>

When it changed to 4.3 (step 8):
    <NumOfIoThreads>1</NumOfIoThreads>
    <ClusterCompatibilityVersion>4.3</ClusterCompatibilityVersion>

After the reboot the VM had:
 num_of_io_threads | custom_compatibility_version 
-------------------+------------------------------
                 1 | 
(1 row)

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/RHEA-2019:2431

sync2jira

sync2jira