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.
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
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
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?
(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). ~~~
So is the workaround applicable? Can we close this?
This was fixed in I2fb32a284e8dd2537f9fd01406b280fab4ea874a in 4.2, VM32BitMaxMemorySizeInMB is no longer "general" but a per-version value.
(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 ?
(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
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.
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
BZ<2>Jira Resync