Bug 1646417 - Can't restore snapshot with disks as user
Summary: Can't restore snapshot with disks as user
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
high
high with 1 vote
Target Milestone: ovirt-4.2.8
: ---
Assignee: biakymet
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-05 14:32 UTC by biakymet
Modified: 2019-01-22 10:23 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.2.8.2
Clone Of:
Environment:
Last Closed: 2019-01-22 10:23:04 UTC
oVirt Team: UX
Embargoed:
rule-engine: ovirt-4.2+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 95273 0 master MERGED engine: Set GetJobByJobId as user query 2018-11-21 07:09:33 UTC
oVirt gerrit 95984 0 ovirt-engine-4.2 MERGED engine: Set GetJobByJobId as user query 2018-12-11 11:26:54 UTC

Description biakymet 2018-11-05 14:32:00 UTC
Description of problem:
When trying to restore snapshot that includes disks as user through RestAPI, I got error that 'Cannot revert to Snapshot. VM's Snapshot does not exist.'

Version-Release number of selected component (if applicable):
Version 4.3.0-0.0.master.20181024083809.git7991369.el7

How reproducible: Everytime


Steps to Reproduce:
1. Login as user
2. Try to restore snapshot with at least one disk

Actual results:
'Cannot revert to Snapshot. VM's Snapshot does not exist.' And Snapshot now in In Preview state.

Expected results:
Restores snapshot

Comment 1 Lucie Leistnerova 2018-12-13 17:33:06 UTC
I still was not able to restore snapshot.

2018-12-13 17:45:52,640+01 ERROR [org.ovirt.engine.core.bll.GetJobByJobIdQuery] (default task-15) [242aca10-bd1b-466d-8a16-4c823526849a] Query execution failed due to insufficient permissions.
2018-12-13 17:45:52,710+01 WARN  [org.ovirt.engine.core.bll.snapshots.RestoreAllSnapshotsCommand] (default task-15) [242aca10-bd1b-466d-8a16-4c823526849a] Validation of action 'RestoreAllSnapshots' failed for user test@internal-authz. Reasons: VAR__ACTION__REVERT_TO,VAR__TYPE__SNAPSHOT,ACTION_TYPE_FAILED_VM_SNAPSHOT_DOES_NOT_EXIST
2018-12-13 17:45:52,740+01 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-15) [] Operation Failed: [Cannot revert to Snapshot. VM's Snapshot does not exist.]

Steps to reproduce:
1. have non-admin user, add UserVmManager permissions to VM
2. log into VM portal with non-admin user
3. run the VM
4. go to dashboard view, create snapshot
5. stop VM
6. restore snapshot


tested in ovirt-engine-4.2.8.1-0.1.el7ev.noarch
with ovirt-web-ui-1.4.4-2.el7ev.noarch

Comment 2 Greg Sheremeta 2018-12-13 22:29:52 UTC
The backport patch did not make it into ovirt-engine-4.2.8.1-0.1.el7ev.noarch (bot shouldn't have moved this to ON_QA)

Please retest with the next 4.2.8 build

Comment 3 vnastasache 2019-01-07 13:59:01 UTC
We are also affected by this bug.

Until a new 4.2.8 build is released, we gave the SuperUser role to one of our Jenkins users for a specific VM.
I could restore being logged in in the Administration Portal, but not from the REST API.

Is there a workaround for this?

Comment 4 Greg Sheremeta 2019-01-07 15:46:28 UTC
(In reply to vnastasache from comment #3)
> Is there a workaround for this?

Granting admin permissions is the only thing I can think of. 4.2.8 is finishing up.

Comment 5 Lucie Leistnerova 2019-01-10 14:38:11 UTC
Snapshot from running VM was successfully restored with non-admin user.

verified in ovirt-web-ui-1.4.5-1.el7ev.noarch with ovirt-engine-4.2.8.2-0.1.el7ev.noarch

Comment 6 Sandro Bonazzola 2019-01-22 10:23:04 UTC
This bugzilla is included in oVirt 4.2.8 release, published on January 22nd 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.2.8 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.


Note You need to log in before you can comment on or make changes to this bug.