Created attachment 1556125 [details] Can't create a new VM after changing the cluster. Description of problem: While creating a new VM from the UI, and selecting a cluster which is not the default selected one on the clusters' list, the operation fails with the following error: "Cannot add VM. CPU Profile doesn't match the provided Cluster." In case of not changing the cluster - the operation succeeds. Version-Release number of selected component (if applicable): master - commit 49eeae3334e How reproducible: 100% Steps to Reproduce: 1. Make sure you have more than 1 cluster on your system. 2. From the UI: New VM 3. Name the VM and choose a different cluster from the clusters' list. Actual results: Operation Canceled - Cannot add VM. CPU Profile doesn't match provided Cluster. And also a UI error on the screen. Expected results: Operation should succeed Additional info: Attached screen capture
Shani, logs, please? ui.log and engine.log
Created attachment 1556128 [details] ui.log Only thing on the engine log is: 2019-04-18 15:50:08,126+03 INFO [org.ovirt.engine.core.bll.AddVmCommand] (default task-19) [84e5e475-fbaa-4393-b59f-e23431a4138f] Lock Acquired to object 'EngineLock:{exclusiveLocks='[1=VM_NAME]', sharedLocks='[00000000-0000-0000-0000-000000000000=TEMPLATE]'}' 2019-04-18 15:50:08,135+03 WARN [org.ovirt.engine.core.bll.AddVmCommand] (default task-19) [] Validation of action 'AddVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER 2019-04-18 15:50:08,136+03 INFO [org.ovirt.engine.core.bll.AddVmCommand] (default task-19) [] Lock freed to object 'EngineLock:{exclusiveLocks='[1=VM_NAME]', sharedLocks='[00000000-0000-0000-0000-000000000000=TEMPLATE]'}'
I simulated this, the failure is in the setAndValidateCpuProfile function and failed because the CPU Profile Id is set to the default while the Cluster Id is for the new Cluster that was chosen. However, after re-basing the problem no longer occurred so someone else seems to have already applied a fix. Please verify if this is the case for you.
The problem happens on master version ovirt-engine-4.3.3.6-0.0.master.20190416081415.git5975555.el7.noarch (there is an exception in ui.log) and doesn't happen on Downstream v. 4.3.3.6-0.1.el7
(In reply to Polina from comment #8) > The problem happens on master version > ovirt-engine-4.3.3.6-0.0.master.20190416081415.git5975555.el7.noarch (there > is an exception in ui.log) and doesn't happen on Downstream v. > 4.3.3.6-0.1.el7 Currently our master branch is 4.4.0.
So, if it works on Downstream version, the issue could be closed ?
If your testing shows it does not happen in the latest 4.3.z release, nor in the current 4.4.0 release, then I would think so. It was a regression that appears to have been fixed after rebasing.