Bug 1533061
Summary: | [downstream clone - 4.1.9] [RFE] Warn user about VMs that have pending snapshot removal retries | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | rhev-integ |
Component: | ovirt-engine | Assignee: | Ala Hino <ahino> |
Status: | CLOSED ERRATA | QA Contact: | Lilach Zitnitski <lzitnits> |
Severity: | urgent | Docs Contact: | |
Priority: | high | ||
Version: | 4.0.2 | CC: | ahino, amureini, apinnick, bcholler, bgraveno, fcami, fgarciad, gveitmic, gwatson, ishaby, lsurette, lveyde, michal.skrivanek, mkalinin, ratamir, rbalakri, Rhev-m-bugs, srevivo, tnisan, ykaul, ylavi |
Target Milestone: | ovirt-4.1.9 | Keywords: | FutureFeature, ZStream |
Target Release: | --- | Flags: | lsvaty:
testing_plan_complete-
|
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.1.9.1 | Doc Type: | Enhancement |
Doc Text: |
When live or cold merge fails, snapshot disks may be left in an illegal state. If virtual machines with illegal snapshot disks are shut down, they will not re-start. Virtual machines with illegal snapshot disks are now marked with an exclamation mark and a warning message not to shut them down.
|
Story Points: | --- |
Clone Of: | 1372163 | Environment: | |
Last Closed: | 2018-01-24 14:43:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1372163 | ||
Bug Blocks: |
Description
rhev-integ
2018-01-10 12:03:18 UTC
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 |