|Summary:||Failed to update VM Cluster|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||Israel Pinto <ipinto>|
|Component:||ovirt-engine-restapi||Assignee:||Roy Golan <rgolan>|
|Status:||CLOSED DUPLICATE||QA Contact:||Israel Pinto <ipinto>|
|Version:||3.5.0||CC:||aburden, alukiano, bazulay, dfediuck, ecohen, gklein, iheim, juan.hernandez, lpeer, lsurette, michal.skrivanek, rbalakri, rgolan, Rhev-m-bugs, yeylon|
|Target Milestone:||---||Keywords:||AutomationBlocker, Reopened, Triaged|
|Fixed In Version:||Doc Type:||Known Issue|
Using the Java SDK to fetch and change the cluster of a virtual machine sends the entire element to the API, including the outdated CPU profile of the previous cluster. Attempts to then update the virtual machine fails as CPU profile does not match with target cluster. The current workaround is to clear the cluster-specific fields when using the Java SDK to fetch and change the cluster of a virtual machine.
|Last Closed:||2014-12-07 09:48:29 UTC||Type:||Bug|
|oVirt Team:||SLA||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1164308, 1164311|
Description Israel Pinto 2014-10-29 12:34:32 UTC
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
Comment 2 Roy Golan 2014-11-19 08:52:51 UTC
*** This bug has been marked as a duplicate of bug 1142629 ***
Comment 3 Israel Pinto 2014-12-01 11:07:15 UTC
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.
Comment 4 Michal Skrivanek 2014-12-01 16:47:15 UTC
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?
Comment 5 Doron Fediuck 2014-12-01 17:05:51 UTC
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.
Comment 6 Roy Golan 2014-12-02 08:05:46 UTC
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.
Comment 7 Roy Golan 2014-12-02 08:10:52 UTC
Juan, Gilad comments?
Comment 8 Juan Hernández 2014-12-02 08:42:26 UTC
The solution in the proposed patch looks good to me.
Comment 10 Israel Pinto 2014-12-03 12:57:36 UTC
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.
Comment 11 Andrew Burden 2014-12-08 04:49:09 UTC
Hey Roy, I've updated the doctext for inclusion in Release Notes. Can you please review to ensure technical accuracy. Cheers
Comment 12 Roy Golan 2014-12-08 07:12:03 UTC
(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.
Comment 13 Roy Golan 2015-05-11 10:53:23 UTC
*** Bug 1218528 has been marked as a duplicate of this bug. ***