Bug 1059713
| Summary: | Vm update not work via REST api | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Artyom <alukiano> | ||||
| Component: | ovirt-engine-core | Assignee: | Juan Hernández <juan.hernandez> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Gadi Ickowicz <gickowic> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.4 | CC: | acathrow, amureini, bdagan, gickowic, gklein, iheim, nlevinki, sbonazzo, s.kieske, yeylon | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 3.4.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | storage | ||||||
| Fixed In Version: | ovirt-3.4.0-beta3 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-03-31 12:27:10 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
What happens here is the following: 1. The RESTAPI receives the request to update the VM, and to do so it loads from the database the VM entity, using the GetVmByIdQuery. This contains all the information, including disks, network interfaces, guest agent information, etc. 2. The RESTAPI applies the requested changes to the entity loaded from the database. 3. The RESTAPI sends this modified entity to the UpdateVm command. 4. The UpdateVm command checks that the update is legal, and it does so loading again the entity from the database, but it is done in AuditLogableBase.getVm() which loads it using VmDAO.get(). This doesn't load all the VM details, in particular it doesn't load the disk. Howevr, AuditLogableBase.getVm() explicitly loads the network interfaces, but not the disks. 5. The UpdateVm command compares the entity loaded from the database and the entity given in the parameters, and it finds that the entity given in the parameters contains disks that the entity loaded from the database doesn't have. This is a wrong conclusion. 6. The UpdateVm command generates an error. 7. The RESTAPI interprets this error as an attempt to change some property that can't be changed when the VM is down. Allon, I see that you were the last to work in that code in AuditLogableBase. What do you think? Juan - this refactoring was done a long time ago (oVirt Engine 3.1, IIRC). This error comes from org.ovirt.engine.core.bll.VmHandler#isUpdateValid which fails since diskList is not annotated as editable. However, I can't image how this used to work. I think that the problem is not that diskList isn't marked as editable, the problem is that the backend is wrongly assuming that the disk list is being modified, but it actually isn't. all patches merged. This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA *** Bug 1067083 has been marked as a duplicate of this bug. *** Verified on av2.1.
request:
url: api/vms/9e09ab52-51e7-4242-9a9e-413557f8312b
<vm>
<name>test_1</name>
</vm>
reponse:
Status Code: 200 OK
<vm href="/api/vms/9e09ab52-51e7-4242-9a9e-413557f8312b" id="9e09ab52-51e7-4242-9a9e-413557f8312b">
...
<name>test_1</name>
...
</vm>
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released |
Created attachment 857467 [details] engine.log Description of problem: Update of vm via REST api not working correct and return error message: [There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.] Version-Release number of selected component (if applicable): ovirt-engine-3.4.0-0.5.beta1.el6.noarch How reproducible: Always Steps to Reproduce: 1. Create new vm 2. Try to update vm via REST(vm is down), for example: <vm> <name>test_1</name> </vm> 3. Actual results: Update is failed and error message appear: [There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.] Expected results: Update success without any error messages. Additional info: