Description of problem: When a virtual machine that is running is updated to change the memory that it will have the next time it is booted, the returned 'memory' attribute contains the current value instead of the next run value. Version-Release number of selected component (if applicable): ovirt-engine-4.0.6 How reproducible: Always. Steps to Reproduce: 1. Create a virtual machine with 100 MiB of RAM and make sure that it is up. 2. Send a request to update the memory (to 356 MiB in this example) that will be used during the next run: #!/bin/sh -ex ---8<--- url="https://engine40.example.com/ovirt-engine/api" user="admin@internal" password="..." vm_id="..." curl \ --verbose \ --cacert /etc/pki/ovirt-engine/ca.pem \ --user "${user}:${password}" \ --request PUT \ --header "Version: 3" \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data ' <vm> <memory>373293056</memory> </vm> ' \ "${url}/vms/${vm_id};next_run=true" 3. Check the returned 'memory' attribute. Actual results: <memory>104857600</memory> Expected results: <memory>373293056</memory> Additional info: The same will probably happen with all the other values that can be different for the current run and for the next run.
Hmmm, while I agree that it is not good, will we not break backward compatibility by fixing it?
We will change the behavior, which can be understood as breaking backwards compatibility. But I think that the current behavior is wrong enough to consider that backwards compatibility breakage justified.
ok, sounds right. But I don't think it should go to z-stream, targeting to 4.2
This doesn't work correctly. The following request: PUT /ovirt-engine/api/vms/{vm:id}?next_run=true <vm> <memory>402653184</memory> <memory_policy> <guaranteed>134217728</guaranteed> </memory_policy> </vm> Fails with the following error: <fault> <detail>[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.]</detail> <reason>Operation Failed</reason> </fault> The reason is that the update is applied to an instance of 'VmStatic' that is loaded using the 'GetVmNextRunConfiguration' query, and that query loads it from the OVF file, not from the database. The 'CreationDate' field in the OVF file has second precision: <CreationDate>2017/01/02 11:27:38</CreationDate> On the other hand the original 'VmStatic' is loaded from the database, where it has milisecond precission: engine=# select creation_date from vm_static where vm_name = 'myvm'; creation_date ---------------------------- 2017-01-02 12:27:38.093+01 This results in two instances of 'Date' with different values. The 'ObjectIdentityChecker.getChangedFields' considers this as a real change, and as a result the update is rejected because 'CreationDate' isn't an updatable field.
so we cannot call the query GetVmNextRunConfiguration in performUpdate. what about updating the VM after the performUpdate via query if next run is true as was posted in the first patch? https://gerrit.ovirt.org/#/c/73433/1/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendVmResource.java
We should be able to call it. I'd say this needs to be addressed in the backend, somehow. If I retrieve the next run configuration and I update it, then the expected result is that the update is performed, not that the system rejects it because an internal implementation detail of how dates are stored/compared. I'd suggest to change the code that generates the OVF files so that it stores also the milliseconds, and to do a data migration to remove the milliseconds from the existing virtual machines, as otherwise it won't match with the existing OVF files.
Verified that memory amount used for next run is returned.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.