Created attachment 951762 [details] screenshot Description of problem: While update VM cluster to other cluster with the same CPU family(SandyBridge) getting "CanDoAction" failure. Version-Release number of selected component (if applicable): rhevm: 3.5.0-0.17.beta.el6ev How reproducible: 1. Create 2 Cluster with CPU family:SandyBridge 2. Create VM on one cluster 3. Edit VM and select the second cluster Actual results: CanDoAction of action UpdateVm failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER Expected results: VM with be updated with new cluster Additional info: See attached screenshot From Engine log: 2014-10-29 11:44:18,425 INFO [org.ovirt.engine.core.bll.ChangeVMClusterCommand] (ajp-/127.0.0.1:8702-12) [6b98a143] Running command: ChangeVMClusterCommand internal: false. Entities affected : ID: 10f98c5d-fb97-4681-accc-c2d6619c3284 Type: VMAction group EDIT_VM_PROPERTIES with role type USER, ID: 68c28727-87a1-4cd4-8e53-d368f080aee9 Type: VdsGroupsAction group CREATE_VM with role type USER 2014-10-29 11:44:18,665 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-12) [6b98a143] Correlation ID: 6b98a143, Call Stack: null, Custom Event ID: -1, Message: VM test configuration was updated by admin. 2014-10-29 11:44:18,936 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] Lock Acquired to object EngineLock [exclusiveLocks= key: test value: VM_NAME , sharedLocks= key: 10f98c5d-fb97-4681-accc-c2d6619c3284 value: VM ] 2014-10-29 11:44:18,975 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] CanDoAction of action UpdateVm failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER 2014-10-29 11:44:18,975 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] Lock freed to object EngineLock [exclusiveLocks= key: test value: VM_NAME , sharedLocks= key: 10f98c5d-fb97-4681-accc-c2d6619c3284 value: VM
*** This bug has been marked as a duplicate of bug 1142629 ***
run automation test for vt12 (after fix). The update vm cluster failed: 2014-11-30 18:06:11,754 - MainThread - api_utils - ERROR - Failed to update element: Status: 400 Reason: Bad Request Detail: Cannot edit VM. CPU Profile doesn't match provided Cluster. Trace: org.ovirt.engine.sdk.web.HttpProxy.execute(Unknown Source) org.ovirt.engine.sdk.web.HttpProxyBroker.update(Unknown Source) org.ovirt.engine.sdk.decorators.VM.update(Unknown Source) test in jenkins: http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.5-git/view/Virt/job/3.5-git-compute-virt-reg_vms-nfs/120/ Note:With UI the operation of update VM cluster succeed.
so...UI works and this is only a REST problem. also, workaround would be to remove the profile and re-add after the move? If so then why should this block ga?
This is related to the way Java SDK works. In general the right way to handle it is fetch the VM, update the profile to a relevant one (or null) and update it. This is not a real blocker but we'll update the BZ soon.
just to elaborate: the test case using sdk is doing this: - fetching a VM object - changeing its cluster - sending it to the update the problem is that the vm is sent with the OLD profile so the REST api send update cluster cmd. it works. then send an update vm which fails. because the OLD profile is specified there. the api is behaving good imho. we can't make the api accept a wrong profile value and change it auto-magically to some working profile. that is surprising. APIs shouldn't be surprising or at least be as less surprising we can :) same as pinning, if you try to change a cluster, you have some problems with cluster specific configurations.
Juan, Gilad comments?
The solution in the proposed patch looks good to me.
see explanation in comment 6
Since the Rest API change and it sets the profile while update the cluster. This change break backward comparability for our customers. I think this should be consider in this case. And if it will not fixed this should be documented in release notes.
Hey Roy, I've updated the doctext for inclusion in Release Notes. Can you please review to ensure technical accuracy. Cheers
(In reply to Andrew Burden from comment #11) > Hey Roy, > > I've updated the doctext for inclusion in Release Notes. Can you please > review to ensure technical accuracy. > > Cheers seems good, thanks.
*** Bug 1218528 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 1218528 ***