Description of problem: If you create 1 or more subsequent snapshots, and restore snapshot which is not the most recent one, all the future snapshots will disappear. Version-Release number of selected component (if applicable): 3.5.0-0.32el6 How reproducible: always Steps to Reproduce: 1. Create a VM 2. Create a snapshot 1 3. Create a snapshot 2 4. Restore to snapshot 1 5. Inspect the snapshots listed in the RHEV-M Actual results: Snapshot 2 is not displayed. Expected results: Snapshot 2 is displayed. Additional info: Very annoying in that sense that it's surprising and makes people do the (important, since it was snapshotted) work again.
Restoring a snapshot is essentially going back in time to when the snapshot was taken. This behavior is by design.
Unfortunately it is not documented, at least not here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html-single/User_Guide/index.html#Using_a_snapshot_to_restore_a_virtual_machine Also, it might be by design but the design itself is surprising for unsuspecting users (not for developers). E.g. VirtualBox can work with 'tree' snapshots just fine. The same is doable just fine with QEMU-img and COW disks. Having said that, I believe that this behavior warrants a warning in the user interface. It might be a pop-up dialog when a user tries to revert snapshot and this revert is going to cause deletion of another snapshot. Thank you for understanding.
(In reply to Petr Spacek from comment #2) > Unfortunately it is not documented, at least not here: > https://access.redhat.com/documentation/en-US/ > Red_Hat_Enterprise_Virtualization/3.5/html-single/User_Guide/index. > html#Using_a_snapshot_to_restore_a_virtual_machine > > Also, it might be by design but the design itself is surprising for > unsuspecting users (not for developers). E.g. VirtualBox can work with > 'tree' snapshots just fine. The same is doable just fine with QEMU-img and > COW disks. But not in RHEV. Never has been. > > Having said that, I believe that this behavior warrants a warning in the > user interface. It might be a pop-up dialog when a user tries to revert > snapshot and this revert is going to cause deletion of another snapshot. A warning is a possibility. Leaving open to hear what the PM's have to say about this.
(In reply to Petr Spacek from comment #2) > Unfortunately it is not documented, at least not here: > https://access.redhat.com/documentation/en-US/ > Red_Hat_Enterprise_Virtualization/3.5/html-single/User_Guide/index. > html#Using_a_snapshot_to_restore_a_virtual_machine > > Also, it might be by design but the design itself is surprising for > unsuspecting users (not for developers). E.g. VirtualBox can work with > 'tree' snapshots just fine. Right... ... why can't this be done by RHV, too ? Is there a RFE for this ? > The same is doable just fine with QEMU-img and > COW disks. > > Having said that, I believe that this behavior warrants a warning in the > user interface. It might be a pop-up dialog when a user tries to revert > snapshot and this revert is going to cause deletion of another snapshot. I have to agree with Peter here. Loosing snapshots means that you loose data, making this a potentially fatal issue for a customers business.
(In reply to Roland Mainz from comment #4) > (In reply to Petr Spacek from comment #2) > > Unfortunately it is not documented, at least not here: > > https://access.redhat.com/documentation/en-US/ > > Red_Hat_Enterprise_Virtualization/3.5/html-single/User_Guide/index. > > html#Using_a_snapshot_to_restore_a_virtual_machine > > > > Also, it might be by design but the design itself is surprising for > > unsuspecting users (not for developers). E.g. VirtualBox can work with > > 'tree' snapshots just fine. > > Right... > ... why can't this be done by RHV, too ? Is there a RFE for this ? Yup, bug 928820. This is a considerable amount of work, and was never deemed to be a priority. If you think it should get a higher priority, please weigh in there. > > > The same is doable just fine with QEMU-img and > > COW disks. > > > > Having said that, I believe that this behavior warrants a warning in the > > user interface. It might be a pop-up dialog when a user tries to revert > > snapshot and this revert is going to cause deletion of another snapshot. > > I have to agree with Peter here. Loosing snapshots means that you loose > data, making this a potentially fatal issue for a customers business. I must say I disagree. A user presses preview, and sees what the state of the VM is on that snapshot. He must manually select to commit it in order to lose the other snapshots. I get that a warning would make this clearer, but to say that the behavior is unexpected seems like a stretch.
(In reply to Allon Mureinik from comment #5) > (In reply to Roland Mainz from comment #4) > > I have to agree with Peter here. Loosing snapshots means that you loose > > data, making this a potentially fatal issue for a customers business. > I must say I disagree. > A user presses preview, and sees what the state of the VM is on that > snapshot. He must manually select to commit it in order to lose the other > snapshots. I get that a warning would make this clearer, but to say that the > behavior is unexpected seems like a stretch. Allon, could you be more specific, please? What specific indication is shown to a user after pressing 'Preview'? I.e. how is the information that 'newer' snapshots will be deleted displayed to the user who pressed 'Preview' but not 'Commit' button yet? Specifically, what makes current behavior 'expected'?
The way I understand it, a previewed VM is in a transient state where the user needs to either rollback, or confirm that the state is as he wishes and commit. Once committed, all other possible states (=snapshots) are removed. I'm not against this bug per se, I just think it's redundant - we already have too many warnings cluttering up too many flows, and well, Syndrome's Law - when everything is a warning, nothing is. Petr, can you please explain the IDM usecase (as referenced by bug 1213937)?
Allon, what you are saying makes perfect sense from developer's point of view, I agree with that. Main problem might be that an ordinary user has no idea about internal representation used by RHEV (list of images vs. tree vs. something else) and as a result, user is surprised by the current behavior. I do not how to describe it in better terms than I did in comment #6. Simply nothing indicates that 'commit' is going to remove snapshots taken after currently previewed one. Tomas, could you elaborate on that?
There is a difference between reverting to a most recent snapshot, and reverting to a snapshot more in the past. If user is reverting to a snapshot, which is not the most recent one, he has no indication available that he will lose the newer snapshots. At the very least, Web UI should show an explicit warning and require confimation in this case.
Additionally, when previewing a past snapshot, during the preview, the newer snapshots are still displayed and there is no indication it will not be the same after commiting.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
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.
Daniel, has this been taken care of by your latest work on the snapshots?
@Allon/Yaniv - do we want to add warnings to the commit snapshot flow? Note that currently commit doesn't invoke a popup. I.e. it would require to add a new one with a warning (and probably an approval latch).
(In reply to Daniel Erez from comment #15) > @Allon/Yaniv - do we want to add warnings to the commit snapshot flow? Note > that currently commit doesn't invoke a popup. I.e. it would require to add a > new one with a warning (and probably an approval latch). I can't seem to find the UX RFE on allowing user to choose 'don't not show again'. This bug should be blocked on that option. Do you the BZ number for that?
(In reply to Yaniv Dary from comment #16) > (In reply to Daniel Erez from comment #15) > > @Allon/Yaniv - do we want to add warnings to the commit snapshot flow? Note > > that currently commit doesn't invoke a popup. I.e. it would require to add a > > new one with a warning (and probably an approval latch). > > I can't seem to find the UX RFE on allowing user to choose 'don't not show > again'. This bug should be blocked on that option. Do you the BZ number for > that? @Oved - do we have a UX RFE for that? Maybe this one: https://bugzilla.redhat.com/show_bug.cgi?id=1188651
This will need to wait until we have the infra to 'not show again'. For now setting to future. Oved can we get the RFE on that option to block this RFE?
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
(In reply to Yaniv Dary from comment #21) > This will need to wait until we have the infra to 'not show again'. > For now setting to future. > Oved can we get the RFE on that option to block this RFE? Bug 1421473
Yaniv, Should we implement this warning now that the infrastructure for muting the alerts will not be implemented? Should the warning be shown each time snapshot will be committed?
(In reply to Eyal Shenitzky from comment #25) > Yaniv, > > Should we implement this warning now that the infrastructure for muting the > alerts will not be implemented? Should the warning be shown each time > snapshot will be committed? We agreed to add this without this capability due to the impact of the action. We should show it every time.
Getting the following warning in webadmin when committing a snapshot: Are you sure you want to commit snapshot from 2018-08-15, 18:19 with description '1'? Existing snapshots that were taken after this one will be erased. Used: 4.3.0-0.0.master.20180814113734.gitad81cd3.el7
This bugzilla is included in oVirt 4.2.7 release, published on November 2nd 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.7 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
Closed by mistake, moving back to qa -> verified
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.