Bug 1417201

Summary:	Updating a VM with 'next_run=true' returns the current memory instead of the next run memory
Product:	[oVirt] ovirt-engine	Reporter:	Juan Hernández <juan.hernandez>
Component:	RestAPI	Assignee:	Shahar Havivi <shavivi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Radim Hrazdil <rhrazdil>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.0.6.3	CC:	bugs, juan.hernandez, lsvaty, tjelinek
Target Milestone:	ovirt-4.2.0	Flags:	rule-engine: ovirt-4.2+ rule-engine: planning_ack+ tjelinek: devel_ack+ lsvaty: testing_ack+
Target Release:	4.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-20 11:03:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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

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.

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

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?

https://gerrit.ovirt.org/#/c/73433/1/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendVmResource.java

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.