Description of problem: A certain set of snapshot preview/undo/commit caused the VM to loose its disk completely. Version-Release number of selected component (if applicable): 4.0.3 How reproducible: Not sure Steps to Reproduce: More or less, something like this: Had a VM up and running, which was restored from a snapshot a few days ago Poweroff Chose a snapshot which is before the latest Pressed Preview Pressed Undo Chose latest snapshot Pressed Preview Pressed Commit Booted "Cannot get disk parameters" Tried again: Poweroff Preview latest snapshot Commit Boot, same. Pressed Disks - No items to display Tried preview a previous snapshot Failed too Actual results: Seems like at this point all snapshots have invalid disks Expected results: Keep disks :-) Not sure if possible/relevant, but it will be nice if a bug in a certain flow will at least keep the previous snapshots in good shape. Additional info:
OK, after investigating here are clear steps to reproduce: Create a VM with disks Create a snapshot "A" Create another snapshot - "B" Preview snapshot A and commit At this point snapshot B disks are marked as illegal yet the snapshot can be previewed Preview snapshot B and commit At this point we are back to the active snapshot but the disks are deleted
(In reply to Tal Nisan from comment #3) > OK, after investigating here are clear steps to reproduce: > > Create a VM with disks > Create a snapshot "A" > Create another snapshot - "B" > Preview snapshot A and commit > > At this point snapshot B disks are marked as illegal yet the snapshot can be > previewed > > Preview snapshot B and commit > > At this point we are back to the active snapshot but the disks are deleted Prior to 'single disk snapshot' and 'custom preview' features, snapshot commit action deleted the unneeded snapshots (i.e. snapshots on the top of the chain). Now, since each snapshot may contain different disk, it doesn't makes sense to maintain a deletion process. As we could delete a snapshot only when its disks can't be used any more. Even then, the VM configuration saved in the snapshot might still be used by selecting 'custom preview'. Hence, I think the logic is correct, perhaps we should document the behavior better.
Another option is adding a warning when previewing a snapshot with disks in status illegal.
TL;DR - we will revisit custom preview flow in 4.1, hence the BZ should be pushed out of 4.0.z. Currently, snapshots and VM configuration entities are coupled. I.e. upon committing a snapshot, the snapshots created at a later date are kept in order to allow previewing their VM configuration (or disks that didn't exist in the committed snapshot). Therefore, for simplifying and ensuring a consistent behavior, the VM configuration entity would act similar to a disk entity. That is - upon committing a snapshot, all newer VM configuration entities should be deleted (similar to disks). The snapshots objects should still be maintained as some of its disks could have been selected (as part of the custom preview flow). However, a snapshot without a VM configuration obviously could not be previewed. Note that we should probably detect a specific case of a snapshot without any entities (VM configuration/disks) and delete it completely upon committing. Also, any disks that don't exist in the committed snapshot should be deleted (from newer snapshots); unless been specified otherwise in custom preview dialog.
I did not fully follow the discussion, but IMO the flow I followed is reasonable, and the fact that it concludes with a dead VM seems like a major bug to me, that can't wait for 4.1. For 4.0 it might be enough to add warnings at some critical steps, not sure which exactly.
I ran into this problem also and I completely destroyed my VM. I normaly don't check if snapshot has its disk. So I previewed the corrupted one and committed. And after that I lost disk for the VM and in all other good snapshots... everything lost. It seems critical to me too. Tested in ovirt-engine-4.1.0-0.0.master.20161124131310.git7ecb4de.el7.centos.noarch
Setting as urgent, it used to work find in the past regardless handling of snapshots has changed internally.
Following steps on comment 3, after preview snapshot A the snapshot B is gone and cannot be previewed, is this the solution given to this issue? checked on :ovirt-engine-4.1.0.1-0.4.master.20170118134729.gitf34da1f.el7.centos.noarch
(In reply to Carlos Mestre González from comment #10) > Following steps on comment 3, after preview snapshot A the snapshot B is > gone and cannot be previewed, is this the solution given to this issue? > > checked on > :ovirt-engine-4.1.0.1-0.4.master.20170118134729.gitf34da1f.el7.centos.noarch Yes, the solution is the remove any newer (unneeded) snapshots than the restored one. As after restroing an older snapshot, the newer snapshots are no longer applicable for preview.
ovirt-engine-4.1.0.1-0.4.master.20170118134729.gitf34da1f.el7.centos.noarch