Bug 1551722
Summary: | Change in VM32BitMaxMemorySizeInMB not honored | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Javier Coscia <jcoscia> |
Component: | ovirt-engine | Assignee: | Michal Skrivanek <michal.skrivanek> |
Status: | CLOSED ERRATA | QA Contact: | Liran Rotenberg <lrotenbe> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.9 | CC: | apinnick, jcoscia, lsurette, mavital, michal.skrivanek, rbalakri, Rhev-m-bugs, smelamud, srevivo, ykaul, ylavi |
Target Milestone: | ovirt-4.2.3 | Keywords: | 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
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 |