Bug 1372163

See also BZ 1332038

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.

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

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?

Idan,
Can you asses both please?

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.

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.

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

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.

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

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?

Ala, can you add some doctext to this please?

--------------------------------------
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!

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/RHEA-2018:1488

BZ<2>Jira Resync