Bug 1701205

Summary: Creating a new VM over the not defaulted cluster fails with "CPU Profile doesn't match provided Cluster" error.
Product: [oVirt] ovirt-engine Reporter: shani <sleviim>
Component: Frontend.WebAdminAssignee: bugs <bugs>
Status: CLOSED CURRENTRELEASE QA Contact: Polina <pagranat>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: ---CC: bugs, lsvaty, rbarry, sgratch, srosenbe, tnisan
Target Milestone: ovirt-4.3.3-1Flags: pm-rhel: ovirt-4.3+
lsvaty: testing_plan_complete?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.3.6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-30 10:18:12 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:
Attachments:
Description Flags
Can't create a new VM after changing the cluster.
none
ui.log none

Description shani 2019-04-18 11:23:19 UTC
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

Comment 1 Ryan Barry 2019-04-18 12:06:28 UTC
Shani, logs, please?

ui.log and engine.log

Comment 2 shani 2019-04-18 12:50:37 UTC
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]'}'

Comment 3 Steven Rosenberg 2019-04-21 13:35:03 UTC
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.

Comment 8 Polina 2019-04-29 13:53:51 UTC
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

Comment 9 Steven Rosenberg 2019-04-29 14:52:10 UTC
(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.

Comment 10 Polina 2019-04-30 07:57:51 UTC
So, if it works on Downstream version, the issue could be closed ?

Comment 11 Steven Rosenberg 2019-04-30 08:01:26 UTC
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.