Bug 1058661

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

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.

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

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.

No objection to do these changes in a version where we explicitly allow and advertise backwards compatibility breaking changes. That means 4.0.

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

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

yes

this is changing the API, moving to 4.0

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.

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.

Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

oVirt 4.0 beta has been released, moving to RC milestone.

oVirt 4.0 beta has been released, moving to RC milestone.

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`

oVirt 4.0.0 has been released, closing current release.