Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1551722

Summary: Change in VM32BitMaxMemorySizeInMB not honored
Product: Red Hat Enterprise Virtualization Manager Reporter: Javier Coscia <jcoscia>
Component: ovirt-engineAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED ERRATA QA Contact: Liran Rotenberg <lrotenbe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.1.9CC: apinnick, jcoscia, lsurette, mavital, michal.skrivanek, rbalakri, Rhev-m-bugs, smelamud, srevivo, ykaul, ylavi
Target Milestone: ovirt-4.2.3Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Previously, the VM32BitMaxMemorySizeInMB and VM64BitMaxMemorySizeInMB parameters were defined incorrectly as both global and version-specific parameters. In the current release, they are defined per version and behave correctly.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-15 17:48:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Javier Coscia 2018-03-05 20:23:47 UTC 
Description of problem:

engine-config -s VM32BitMaxMemorySizeInMB=XXXX is not honored

This caused a cluster not being able to be moved to compatibility version 4.1, message: 

WARN  [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-51) [4b0aff8d] Validation of action 'UpdateVm' failed for user XXXXXXXX. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_MAX_MEMORY_CANNOT_EXCEED_PLATFORM_LIMIT,$maxMemory 32768,$platformLimit 20480

As a workaround user moved the VM OS to a 64Bits one and was able to complete the upgrade sequence, although, now, the VM cannot be moved back to a 32 Bit OS with the same message.



Version-Release number of selected component (if applicable):

rhevm-4.1.9.2-0.1.el7.noarch


How reproducible: 100%


Steps to Reproduce:
1. Have a 32 OS Bit VM installed / running, i.e. Windows 2003, with more than 20Gb configured as RAM
2. Upgrade engine to 4.1
3. Change cluster compatibility to 4.1: fails
4. Edit VM and switch OS to a 64Bits one, complete the upgrade sequence.
5. Try to move the VM OS back to a 32 Bits: fails

Actual results:

Change in VM32BitMaxMemorySizeInMB value has no effect in the environment

Expected results:

VM32BitMaxMemorySizeInMB value should be honored

Additional info:

ovirt-engine was restarted after setting VM32BitMaxMemorySizeInMB with engine-config command.
Comment 1 Michal Skrivanek 2018-03-06 06:09:58 UTC 
This vdc_option value is a per-cluster setting, I see the value was changed for "general" instead. So it was not taken into account and left at 20GB for the particular cluster level
Comment 2 Javier Coscia 2018-03-06 11:19:50 UTC 
Couldn't find / set this setting under cluster by passing the --cver option to engine-config, I didn't get the option to select the version if I don't pass any other flag.

For example if I try to set this for VM64BitMaxMemorySizeInMB I do get the option to which version I want to set it.

[root@rhvm41 ~]# rpm -q rhevm
rhevm-4.1.9.2-0.1.el7.noarch

[root@rhvm41 ~]# engine-config -a | grep -i bitmaxmemorysizeinmb
VM32BitMaxMemorySizeInMB: 65536 version: general
VM64BitMaxMemorySizeInMB: 4194304 version: 4.1
VM64BitMaxMemorySizeInMB: 4194304 version: 3.6
VM64BitMaxMemorySizeInMB: 4194304 version: 4.0

[root@rhvm41 ~]# engine-config -s VM32BitMaxMemorySizeInMB=65536 --cver=4.1
Error setting VM32BitMaxMemorySizeInMB's value. No such entry with version 4.1.

[root@rhvm41 ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select * from vdc_options where option_name ilike '%bitmaxmemorysizeinmb%' " 
 option_id |         option_name         | option_value | version 
-----------+-----------------------------+--------------+---------
       333 | VM32BitMaxMemorySizeInMB    | 65536        | general
       336 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.1
       337 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 3.6
       338 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.0
       339 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.1
       334 | VM64BitMaxMemorySizeInMB    | 4194304      | 3.6
       335 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.0



[root@rhvm41 ~]# engine-config -s VM64BitMaxMemorySizeInMB=65536 
Please select a version:
1. 4.1
2. 3.6
3. 4.0
Comment 10 Shmuel Melamud 2018-04-23 21:27:44 UTC 
Can you please test one more thing? If you assign a version to the option

update vdc_options set version='4.1' where option_name='VM32BitMaxMemorySizeInMB';

does it solves the problem?
Comment 11 Javier Coscia 2018-04-23 22:35:34 UTC 
(In reply to Shmuel Melamud from comment #10)
> Can you please test one more thing? If you assign a version to the option
> 
> update vdc_options set version='4.1' where
> option_name='VM32BitMaxMemorySizeInMB';
> 
> does it solves the problem?

It does, it works in both scenarios: 1) create a 32 bit OS VM with MaxMem = 48Gb  and 2) switch OS type from 64 to 32 on an existing VM which was configured with 48Gb MaxMem earlier.


~~~~~~~

[root@rhvm41 ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "update vdc_options set version = '4.1' where option_name = 'VM32BitMaxMemorySizeInMB' "
UPDATE 1


[root@rhvm41 ~]# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select * from vdc_options where option_name ilike '%bitMaxMemorySizeInMB%' "
 option_id |         option_name         | option_value | version 
-----------+-----------------------------+--------------+---------
       336 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.1
       337 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 3.6
       338 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.0
       339 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.1
       333 | VM32BitMaxMemorySizeInMB    | 65536        | 4.1
       334 | VM64BitMaxMemorySizeInMB    | 4194304      | 3.6
       335 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.0


Case 2

2018-04-23 19:23:07,952-03 INFO  [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-10) [6a7b48e0-a43f-4d77-be65-f7067b35c10c] Running command: UpdateVmCommand internal: false. Entities affected :  ID: 9a851c76-d29a-492e-8687-f2861754346d Type: VMAction group EDIT_VM_PROPERTIES with role type USER

2018-04-23 19:23:08,145-03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-10) [c09c868] EVENT_ID: USER_UPDATE_VM(35), Correlation ID: 6a7b48e0-a43f-4d77-be65-f7067b35c10c, Job ID: fdfd2fb6-2ed2-42ee-b989-d0f62b0e63c3, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: VM rhel7.32.bits configuration was updated by admin@internal-authz.




Case 1


2018-04-23 19:23:55,005-03 INFO  [org.ovirt.engine.core.bll.AddVmFromTemplateCommand] (default task-16) [cecd2ad0-ac43-4b8f-9426-a278c61a876d] Running command: AddVmFromTemplateCommand internal: false. Entities affected :  ID: 00000002-0002-0002-0002-00000000017a Type: ClusterAction group CREATE_VM with role type USER,  ID: 00000000-0000-0000-0000-000000000000 Type: VmTemplateAction group CREATE_VM with role type USER


2018-04-23 19:23:55,270-03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-16) [5ea8f] EVENT_ID: USER_ADD_VM_STARTED(37), Correlation ID: cecd2ad0-ac43-4b8f-9426-a278c61a876d, Job ID: d4789c8e-015f-4fed-b01d-573a5437410c, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: VM win2003.32.bits creation was initiated by admin@internal-authz.



2018-04-23 19:23:57,065-03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5) [cecd2ad0-ac43-4b8f-9426-a278c61a876d] EVENT_ID: USER_ADD_VM_FINISHED_SUCCESS(53), Correlation ID: cecd2ad0-ac43-4b8f-9426-a278c61a876d, Job ID: d4789c8e-015f-4fed-b01d-573a5437410c, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: VM win2003.32.bits creation has been completed.






engine=# select vm_name, os, mem_size_mb, max_memory_size_mb from vms; 
     vm_name     | os | mem_size_mb | max_memory_size_mb 
-----------------+----+-------------+--------------------
 win2003.32.bits |  3 |       12288 |              49152
 rhel7.32.bits   | 18 |       12288 |              49152 <<<<<< switched to rhel6.32 flavor

~~~~~~~~


If I try to create a VM with a 32Bit OS with 18Gb of RAM and MaxMem in 72Gb it fails with the honoured 64Gb limit

~~~
Cannot add VM. Maximum memory (73728MB) cannot exceed platform limit (65536MB).
~~~
Comment 12 Yaniv Kaul 2018-04-24 06:41:33 UTC 
So is the workaround applicable? Can we close this?
Comment 13 Michal Skrivanek 2018-04-24 07:35:01 UTC 
This was fixed in I2fb32a284e8dd2537f9fd01406b280fab4ea874a in 4.2, VM32BitMaxMemorySizeInMB is no longer "general" but a per-version value.
Comment 14 Javier Coscia 2018-04-24 13:26:36 UTC 
(In reply to Michal Skrivanek from comment #13)
> This was fixed in I2fb32a284e8dd2537f9fd01406b280fab4ea874a in 4.2,
> VM32BitMaxMemorySizeInMB is no longer "general" but a per-version value.

Thanks Michal, I've just verified it in 4.2 beta3 and I can see 'VM32BitMaxMemorySizeInMB' is set per-cluster version. 

The only thing I noticed is that there is no message indicating the MaxMem exceeded the platform value if you set a high RAM value (by default maxmem = mem * 4), not in the UI (the new/edit dialog won't close and the box is being rounded with a red shadow although no indication of what's wrong with it) and not in engine.log

It might be difficult to understand/catch what the issue is in this scenario

(In reply to Yaniv Kaul from comment #12)
> So is the workaround applicable? Can we close this?

Yaniv, the workaround is applicable, although, I would think it would be better to attach 4.2 errata into this BZ and/or associate https://gerrit.ovirt.org/#/c/81421/ to this bug too.

What do you guys think ?
Comment 15 Michal Skrivanek 2018-04-24 13:31:15 UTC 
(In reply to Javier Coscia from comment #14)
> (In reply to Michal Skrivanek from comment #13)
> > This was fixed in I2fb32a284e8dd2537f9fd01406b280fab4ea874a in 4.2,
> > VM32BitMaxMemorySizeInMB is no longer "general" but a per-version value.
> 
> Thanks Michal, I've just verified it in 4.2 beta3 and I can see
> 'VM32BitMaxMemorySizeInMB' is set per-cluster version. 
> 
> The only thing I noticed is that there is no message indicating the MaxMem
> exceeded the platform value if you set a high RAM value (by default maxmem =
> mem * 4), not in the UI (the new/edit dialog won't close and the box is
> being rounded with a red shadow although no indication of what's wrong with
> it) and not in engine.log

because it's a frontend validation. There is no popup help when you hover over that red field? If it's not there then it deserves another (minor) bug


> It might be difficult to understand/catch what the issue is in this scenario
> 
> (In reply to Yaniv Kaul from comment #12)
> > So is the workaround applicable? Can we close this?
> 
> Yaniv, the workaround is applicable, although, I would think it would be
> better to attach 4.2 errata into this BZ and/or associate
> https://gerrit.ovirt.org/#/c/81421/ to this bug too.
> 
> What do you guys think ?

sure
Comment 18 Liran Rotenberg 2018-04-25 12:25:57 UTC 
Verified on:
ovirt-engine-4.2.3.2-0.1.el7.noarch

Steps:
1. Set a new config to the VM32BitMaxMemorySizeInMB.
# engine-config -s VM32BitMaxMemorySizeInMB=65536 --cver=4.1
or
# engine-config -s VM32BitMaxMemorySizeInMB=65536
and choose 4.1.

2. Watch the change made in DB and using engine-config
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select * from vdc_options where option_name ilike '%bitMaxMemorySizeInMB%' "
 option_id |         option_name         | option_value | version 
-----------+-----------------------------+--------------+---------
       388 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.0
       383 | VM32BitMaxMemorySizeInMB    | 20480        | 3.6
       384 | VM32BitMaxMemorySizeInMB    | 20480        | 4.0
       386 | VM32BitMaxMemorySizeInMB    | 20480        | 4.2
       387 | VM64BitMaxMemorySizeInMB    | 4194304      | 3.6
       389 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.1
       390 | VM64BitMaxMemorySizeInMB    | 4194304      | 4.2
       391 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 3.6
       392 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.0
       393 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.1
       394 | VMPpc64BitMaxMemorySizeInMB | 1048576      | 4.2
       385 | VM32BitMaxMemorySizeInMB    | 65536        | 4.1
(12 rows)


# engine-config -a | grep -i bitmaxmemorysizeinmb

VM32BitMaxMemorySizeInMB: 20480 version: 3.6
VM32BitMaxMemorySizeInMB: 20480 version: 4.0
VM32BitMaxMemorySizeInMB: 65536 version: 4.1
VM32BitMaxMemorySizeInMB: 20480 version: 4.2
VM64BitMaxMemorySizeInMB: 4194304 version: 4.0
VM64BitMaxMemorySizeInMB: 4194304 version: 3.6
VM64BitMaxMemorySizeInMB: 4194304 version: 4.1
VM64BitMaxMemorySizeInMB: 4194304 version: 4.2

3. Restart engine service
# service ovirt-engine restart

4. Create a cluster with Compatibility Version: 4.1.
5. Check if the VM32BitMaxMemorySizeInMB is honored.
a) Create a 32bit OS with 12GB memory, 48GB max memory.
b) Create a 64bit OS with 12GB memory, 48GB max memory, after creation, edit the VM to 32bit.
c) Create a VM with 32bit, 18GB memory, 72GB max memory.
d) Edit a VM from step a or b, set 18GB memory, 72GB max memory.

Results:
In step 2, we can see the change was made to the config per version without general as mentioned in comment #13.
In step 5, cases a and b, passed without any error as expected.
In cases c and d, the creation and edit didn't pass, as expected. The max memory passed the limitation, the field was with a red border indicating the wrong value.
Comment 23 errata-xmlrpc 2018-05-15 17:48:31 UTC 
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-2018:1488
Comment 24 Franta Kust 2019-05-16 13:04:11 UTC 
BZ<2>Jira Resync