Description of problem: In the instance type or template create/edit menu in webadmin, under the host tab, the option to choose the migration mode exist and is changeable. This option should be reflected in API with the placement_policy attribute and affinity sub-attrbiute, same as it does for vms. In practice changing the value via webadmin affects the DB as expected, but the attribute doesn't exist in API so cannot be edited using it. Furthermore only with templates, the value that was set in webadmin and is changes in DB doesn't reflect in webadmin when you edit the template once more and always returns back to the default mode = 'Allow manual and automatic migration' Version-Release number of selected component (if applicable): How reproducible: rhevm-4.0.4.2-0.1.el7ev.noarch Steps to Reproduce: 1. Edit a template or an instance type. 2. Under Host tab choose 'migration mode' = Allow manual migration 3. call GET cmd via API for the template entity. Actual results: in DB the correct value is set (migration_support column in vm_static table is set to 1). In webadmin - the value persists for instance type, but is reverted to 'Allow manual and automatic migration' for templates. Via API the value isn't visible at all (tried all-content flag as well). Expected results: All values are aligned between webadmin-DB-API and are reflected properly. Additional info:
Is anyone looking at this? I assume not for 4.2.0?
Verification is done on rhv-release-4.2.3-2-001.noarch Verification steps: In the existent template choose Host tab and change migration mode to 'Allow manual migration only'. Create the VM from thos template. Results: 1. in postgres - select migration_support from vm_static where vm_guid='aa257ee2-3594-49b8-93a3-5fca07ee7bdc'; 1 2. In UI the VM is created with 'Allow manual migration only'. 3. In get vms API - <placement_policy> <affinity>user_migratable</affinity> </placement_policy>
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.