Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1058661 - Memory is not restored from ram snapshot by default (REST)
Summary: Memory is not restored from ram snapshot by default (REST)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Shmuel Melamud
QA Contact: Shira Maximov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-28 10:01 UTC by Meital Bourvine
Modified: 2016-07-05 07:57 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-05 07:57:07 UTC
oVirt Team: Virt
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
logs (deleted)
2014-01-28 10:01 UTC, Meital Bourvine
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 25626 None None None Never
oVirt gerrit 57307 master MERGED core: Add memory when creating/restoring from snapshot 2016-05-25 13:24:35 UTC

Description Meital Bourvine 2014-01-28 10:01:09 UTC
Created attachment 856453 [details]
logs

Description of problem:
Restoring a ram snapshot from rest doesn't work

Version-Release number of selected component (if applicable):
IS33

How reproducible:
100%

Steps to Reproduce:
1. Create a vm with os
2. Run on the vm `cat /dev/zero > /dev/null &`
3. Create a snapshot with ram
4. Shut down the vm
5. via rest api:

Method: POST

URL: https://mbourvin-rhevm3-3.scl.lab.tlv.redhat.com/api/vms/<vm_id>/snapshots/<snapshot_id>/restore

Headers: 
Accept: application/xml
Content-type: application/xml

Body:
<action/>

6. Start the vm
7. Run on the vm: `ps ax | grep zero`

Actual results:
The process isn't running

Expected results:
The process should be running

Additional info:
Attaching logs, it happened around 2014-01-28 11:45:47

Comment 2 Arik 2014-01-30 14:35:58 UTC
Currently you should explicitly set that you want to restore the memory in the request, by setting restore_memory to true. please check to see that it works for you with it, and if so, we will modify this bug to just change the default settings of restore snapshot request to restore the memory (if the snapshot contains memory) by default

Comment 3 Juan Hernández 2014-03-11 16:46:45 UTC
In what version did we introduce the RAM snapshots? If it was in 3.3 then we can't change the default behavior in 3.4, as it is a backwards compatibility breaking change.

Comment 4 Arik 2014-03-12 08:23:18 UTC
(In reply to Juan Hernández from comment #3)
> In what version did we introduce the RAM snapshots? If it was in 3.3 then we
> can't change the default behavior in 3.4, as it is a backwards compatibility
> breaking change.

Right, the RAM snapshots were introduced in 3.3, so changing the create snapshot flow to take memory snapshot could be problematic in terms of backward compatibility, but I think we can change the restore snapshot flow to restore the memory by default even though it changes the previous behavior because the current state is logically wrong.

If the user keeps his previous methods for create and restore snapshots then the snapshots won't contain memory and we'll ignore requests to restore the memory anyway. If the snapshot contains memory, it means that the user used new capability in the API, so it does make sense to change the behavior when restoring such snapshot to restore the memory as well - otherwise the user might be confused as the reporter of this bug was: she created a snapshot with memory and she expected that unless explicitly saying otherwise, this memory will be restored as part of the snapshot restoration.

So what do you think about not taking memory snapshot by default when creating snapshot (which btw should be changed as well some day) but restore the memory by default when restoring snapshots?

Comment 5 Juan Hernández 2014-03-12 09:42:47 UTC
The RAM shouldn't be included in the snapshot by default. It is my understanding that it isn't. If it is then that is a problem in itself, and should be fixed before releasing 3.4. Please confirm.

Automatically restoring the RAM when it is contained in the snapshot seems logical, but anyhow it breaks the expectations of users that aren't aware of this new feature. Take into account that the user creating the snapshot and the user restoring it may be different. For example, a human user may be allowed to create the snapshots (with or without RAM) and an automatic system may be restoring them. This automatic system will now find some restored VMs in a different state than they used to be, for example, the VMs won't perform the boot process, which may be something the automatic system depends on. This is unlikely, but we already have other similar unlikely situations causing real issues.

Comment 6 Juan Hernández 2014-03-12 09:44:00 UTC
No objection to do these changes in a version where we explicitly allow and advertise backwards compatibility breaking changes. That means 4.0.

Comment 7 Arik 2014-03-12 09:56:40 UTC
(In reply to Juan Hernández from comment #5)
> The RAM shouldn't be included in the snapshot by default. It is my
> understanding that it isn't. If it is then that is a problem in itself, and
> should be fixed before releasing 3.4. Please confirm.
> 

From the REST API it is not, but from the UI it is (the "include memory" checkbox is set by default in the create snapshot dialog).

Comment 8 Arik 2014-03-12 09:57:11 UTC
(In reply to Juan Hernández from comment #6)
> No objection to do these changes in a version where we explicitly allow and
> advertise backwards compatibility breaking changes. That means 4.0.

Michal, can we postpone to 4.0?

Comment 9 Michal Skrivanek 2014-03-12 10:20:57 UTC
yes

Comment 11 Omer Frenkel 2015-08-27 07:53:44 UTC
this is changing the API, moving to 4.0

Comment 12 Sandro Bonazzola 2015-09-04 08:59:54 UTC
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Comment 13 Red Hat Bugzilla Rules Engine 2015-10-19 11:02:33 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 14 Sandro Bonazzola 2016-05-02 10:03:10 UTC
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

Comment 15 Yaniv Lavi 2016-05-23 13:18:09 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 16 Yaniv Lavi 2016-05-23 13:22:21 UTC
oVirt 4.0 beta has been released, moving to RC milestone.

Comment 17 Shira Maximov 2016-06-13 10:54:09 UTC
verified on :
oVirt Engine Version: 4.1.0-0.0.master.20160609051254.gita18ebb1.el7.centos

verification steps: 
1. Create a vm with os
2. Run on the vm `cat /dev/zero > /dev/null &`
3. Create a snapshot with ram
4. Shut down the vm
5. via rest api:

Method: POST

URL: https://mbourvin-rhevm3-3.scl.lab.tlv.redhat.com/api/vms/<vm_id>/snapshots/<snapshot_id>/restore

Headers: 
Accept: application/xml
Content-type: application/xml

Body:
<action/>

6. Start the vm
7. Run on the vm: `ps ax | grep zero`

Comment 18 Sandro Bonazzola 2016-07-05 07:57:07 UTC
oVirt 4.0.0 has been released, closing current release.


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