Bug 1417201 - Updating a VM with 'next_run=true' returns the current memory instead of the next run memory
Summary: Updating a VM with 'next_run=true' returns the current memory instead of the ...
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: ovirt-4.2.0
: 4.2.0
Assignee: Shahar Havivi
QA Contact: Radim Hrazdil
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-27 14:13 UTC by Juan Hernández
Modified: 2017-12-20 11:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-12-20 11:03:40 UTC
oVirt Team: Virt
rule-engine: ovirt-4.2+
rule-engine: planning_ack+
tjelinek: devel_ack+
lsvaty: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 73433 0 master MERGED api: updating vm with next_run=true return the db vm 2017-03-07 12:41:26 UTC
oVirt gerrit 74750 0 master MERGED core: VMs creation date may fail on non-editable fields when updating from API 2017-03-30 07:58:50 UTC

Description Juan Hernández 2017-01-27 14:13:46 UTC
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):


How reproducible:


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


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 '
' \

3. Check the returned 'memory' attribute.

Actual results:


Expected results:


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.

Comment 1 Tomas Jelinek 2017-01-30 09:16:46 UTC
Hmmm, while I agree that it is not good, will we not break backward compatibility by fixing it?

Comment 2 Juan Hernández 2017-01-30 12:47:14 UTC
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.

Comment 3 Tomas Jelinek 2017-01-31 08:46:36 UTC
ok, sounds right. But I don't think it should go to z-stream, targeting to 4.2

Comment 4 Juan Hernández 2017-03-24 20:29:34 UTC
This doesn't work correctly. The following request:

  PUT /ovirt-engine/api/vms/{vm:id}?next_run=true

Fails with the following error:

    <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>

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';
   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.

Comment 5 Shahar Havivi 2017-03-26 07:48:48 UTC
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?


Comment 6 Juan Hernández 2017-03-28 08:30:18 UTC
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.

Comment 7 Radim Hrazdil 2017-09-06 07:56:41 UTC
Verified that memory amount used for next run is returned.

Comment 8 Sandro Bonazzola 2017-12-20 11:03:40 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.