Description of problem: There's an inconsistency of HotUnplugMemorySupported value in 4.1 clusters between RHV versions: 1. Clean RHV 4.1 installation option_name | option_value | version -------------------------+------------------------------+--------- HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 3.6 HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 4.0 HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 4.1 2. RHV 4.2 upgraded from RHV 4.1 option_name | option_value | version -------------------------+---------------------------------------------+--------- HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 3.6 HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 4.0 HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 4.1 HotUnplugMemorySupported | {"x86":"true","ppc":"true","s390x":"false"} | 4.2 3. Clean RHV 4.2 installation option_name | option_value | version -------------------------+---------------------------------------------+--------- HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 3.6 HotUnplugMemorySupported | {"x86":"false","ppc":"false"} | 4.0 HotUnplugMemorySupported | {"x86":"true","ppc":"false"} | 4.1 HotUnplugMemorySupported | {"x86":"true","ppc":"true","s390x":"false"} | 4.2
Michale, so what's the correct value for HotUnplugMemorySupported for 4.1 clusters?
Supported in 4.1 for x86_64 Not supported for ppc64le until 4.2 It was probably broken quite early in 4.1 already without people noticing
Workaround for existing 4.1/4.2 customers: 1. Login to RHV manager host as root 2. Execute following commands: . /etc/ovirt-engine/engine.conf.d/10-setup-database.conf PGPASSWORD="$ENGINE_DB_PASSWORD" psql -h "${ENGINE_DB_HOST}" \ -d "${ENGINE_DB_DATABASE}" -U "${ENGINE_DB_USER}" \ -c "update vdc_options set option_value='{\"x86\":\"true\",\"ppc\":\"false\"}' where option_name = 'HotUnplugMemorySupported' and version='4.1';" 3. Restart ovirt-engine service systemctl restart ovirt-engine
This is not specific to the HotUnplugMemorySupported values , in the attached document there are 24 values that are not correct when you compare 4.1 to 4.2 upgrade VS 4.2 clean install
Created attachment 1457836 [details] config diff between 4.1 to 4.2 upgrade and clean install
Marking as a blocker, this affects RHV 4.2 customers upgrading from 4.1 badly (new 4.2 installations are not affected)
The reason for most of those changes between upgrade an clean install is [1] which did a change in config in an upgrade script instead of modifying 0000_config.sql directly , since 0000_config.sql is running in each upgrade, the changes made by [1] to 4.0 are overridden whilw installing 4.1 [1] https://gerrit.ovirt.org/#/c/49299/8/packaging/dbscripts/upgrade/04_00_0080_rename_architecture_family.sql
(In reply to Martin Perina from comment #0) Please note that the original bug on the HotUnplugMemorySupported value for 4.1 will not be fixed since it is probably supported but was not tested for 4.1 Customers willing to use this feature will have to enable it manually for 4.1 on their DBs on their own risk
Workaround mentioned in Comment 3 is not valid, HotUnplugMemorySupported should be disabled in RHV 4.1 as it was not fully tested by QE (sorry for the confusion). And what's more important, there are much more inconsistencies on other values: HotPlugCpuSupported HotUnplugCpuSupported HotPlugMemorySupported HotUnplugMemorySupported IsMigrationSupported IsMemorySnapshotSupported IsSuspendSupported ClusterRequiredRngSourcesDefault So if RHV 4.1/4.2 customers, who upgraded from RHV 4.0, have issues around above features, they need to upgrade to RHV 4.2.5+.
Upgrade 4.1.9 -> 4.3 and clean 4.3 has no differences in vdc_options values and HotUnplugMemorySupported is {"x86":"false","ppc":"false"} for version < 4.2 verified in ovirt-engine-4.3.0-0.0.master.20180902070649.gita860c9c.el7.noarch
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:1085
sync2jira