+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1372163 +++ ====================================================================== Description of problem: Since latter 3.6 we have the recovery flows which can fix failed snapshot removals. Consider this case: - A snapshot may fail to remove - An image is left with illegal state in SD metadata - User does not try again (ie: removal might be part of a backup script) - Months later someone shuts down the VM The VM will fail to come up again due to the illegal image in the SD. It's very easy to fix, but it's not obvious, and the consequence might be downtime for production VMs. A simple retry fixes the problem but this is not shown to the user. Request: - For VMs with failed snapshots, put a mark on the VM (something similar to the cluster upgrade icon?) AND/OR - Add a confirmation dialog when shutting down the VM explaining the situation 1. Proposed title of this feature request Mark VMs that have a pending snapshot removal retry in the UI. 2. Who is the customer behind the request? Red Hat - GSS (Originally by Germano Veit Michel)
See also BZ 1332038 (Originally by Germano Veit Michel)
Tal - please assign this to someone to assess risk and complexity for the 2nd use case: "Add a confirmation dialog when shutting down the VM explaining the situation" - I'd argue that any task should have such a warning, but we also need one for failed tasks. (Originally by Yaniv Kaul)
Idan, please have a look, we need to understand if we can gather all the info about the failed snapshot upon deactivating, passing that indication to the UI and from there add a confirmation dialog if needed (Originally by Tal Nisan)
We need to differentiate between two cases: 1. The active snapshot is in an illegal state - in this case, indeed the vm can't be restarted. 2. A snapshot which is not the active one (an internal snapshot) is in an illegal state - in this case, the vm *can* be restarted. To me, in these two cases respectively, it makes sense to: 1. Add a popup when shutting down the VM explaining the situation. 2. Mark the vm in the ui (without a popup). But this is just my opinion about this. What do you guys think, before I assess the risk and complexity of it? (Originally by Idan Shaby)
Idan, Can you asses both please? (Originally by Marina Kalinin)
Sure, the risk is quite low as most of the changes should be made in the ui. We will also need to add a query to check for existing illegal snapshots in a given vm, and call it at the end of cold and live merge, and on run vm. I guess that it will take something like ~ two weeks to complete. (Originally by Idan Shaby)
I'd like to revisit the discussion here. If removing a snapshot fails, the chain as a whole is most certianly valid, an the VM can be run - except for during a short, minimal piovt operation. But marking the VM in some state can fail exactly like a pivot can fail, so you wouldn't be adding any resilence here, just adding another point of failure. Can you describe a simple usecase and how this RFE will solve it? I feel as though I might be missing something. (Originally by Allon Mureinik)
I see a couple of patches added here. Just to keep the scope clear, the required patches should include - Changes to the business entity / database / daos - adding this new field to the search mechanism - exposing it via the REST API (Originally by Allon Mureinik)
A note to QE guys: As the changes to implementing this RFE includes changes to 'vms' view, please verify the performance of the system when verifying this. (Originally by Ala Hino)
(In reply to Allon Mureinik from comment #28) > I see a couple of patches added here. > Just to keep the scope clear, the required patches should include > - Changes to the business entity / database / daos Merged. > - adding this new field to the search mechanism Merged. > - exposing it via the REST API Pending review on this one. Once it's merged, the bug should be moved to MODIFIED. (Originally by Allon Mureinik)
Proposed scope by engineering: 1. Cold merge should be usable as a recovery mechanism for live merge (bz#1384321 - targetted to 4.2) 2. Add some GUI indiciation that that the chain contains illegal imags FROM THE ENGINE'S DATABASE - a couple of days, need UXD's help. This bug is targeting to fix #2. Is that acceptable by CEE instead of the RFE request listed in the summary? (Originally by ylavi)
Ala, can you add some doctext to this please? (Originally by Allon Mureinik)
-------------------------------------- Tested with the following code: ---------------------------------------- ovirt-engine-4.2.0-0.0.master.20171112130303.git8bc889c.el7.centos.noarch vdsm-4.20.6-62.gitd3023e4.el7.centos.x86_64 Tested with the following scenario: Steps to Reproduce: 1. Create vm with disks and start the vm 2. start live merge 3. terminate the merge and cancel the live merge Actual results: An exclamation mark is shown next to the vm's name and when hovering over it a warning is shown about snapshots with illegal disks Expected results: Moving to VERIFIED! (Originally by Lilach Zitnitski)
-------------------------------------- Tested with the following code: ---------------------------------------- rhevm-4.1.9-0.2.el7.noarch vdsm-4.19.44-1.el7ev.x86_64 Tested with the following scenario: Steps to Reproduce: 1. Create vm with disks and start the vm 2. start live merge 3. terminate the merge and cancel the live merge Actual results: An exclamation mark is shown next to the vm's name and when hovering over it a warning is shown about snapshots with illegal disks Expected results: Moving to VERIFIED!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0135
BZ<2>Jira re-sync