Bug 928399

Summary: Cloned template disk does not end up in proper storage domain
Product: [Retired] oVirt Reporter: DHC <deadhorseconsulting>
Component: ovirt-engine-userportalAssignee: Daniel Erez <derez>
Status: CLOSED UPSTREAM QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: acathrow, amureini, derez, dyasny, ecohen, iheim, ykaul
Target Milestone: ---   
Target Release: 3.3.4   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 953619 (view as bug list) Environment:
Last Closed: 2013-04-18 16:16:50 UTC Type: Bug
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:    
Bug Blocks: 953619    
Attachments:
Description Flags
engine debug log none

Description DHC 2013-03-27 15:00:21 UTC 
Description of problem:
Disks cloned from a template do not end up in the selected destination storage domain.

In further attempt to debug this I added the user as both a SuperUser and PowerUser to the entire Datacenter so the role would cascade down to all objects. I found that with the admin portal this was not an issue. However it still occurs with the UserPortal. The same issue actually occurs for the built in admin@internal user via the user portal as well. Thus this infers some interaction with the UserPortal specifically causing this.

Version-Release number of selected component (if applicable):
Master

How reproducible:
100%

Steps to Reproduce:
Assign a user UserTemplateVM permissions to storage domain "A".
Create a template in storage domain "A".
Ensure the user has PowerUserRole permissions to another storage domain (Storage domain "B").

As the user create a VM from the template in storage domain "A".
Choose to "clone" the disk to Storage Domain "B".
  
Actual results:
The attached disk of resultant VM gets created but the disk is created in Storage domain A
instead of storage domain B.

Expected results:
Disk is cloned into proper destination storage domain.

Additional info:
Comment 1 DHC 2013-04-04 17:03:55 UTC 
Created attachment 731681 [details]
engine debug log

I patched in the code changes in the gerrit fix against engine commit: b4cc077888ba11871aa4837a73498a231050e2fc

Now the user gets a permissions denied error instead. Attaching engine.log for debug purposes.

- DHC
Comment 2 Daniel Erez 2013-04-04 23:11:57 UTC 
(In reply to comment #1)
> Created attachment 731681 [details]
> engine debug log
> 
> I patched in the code changes in the gerrit fix against engine commit:
> b4cc077888ba11871aa4837a73498a231050e2fc
> 
> Now the user gets a permissions denied error instead. Attaching engine.log
> for debug purposes.
> 
> - DHC

Hi DHC,
Can you please check that the user has permissions that include Disk Provisioning Operations (e.g. PowerUserRole/UserVmManager) on both source storage domain (A) and target storage domain (B).
Comment 3 DHC 2013-04-05 21:19:39 UTC 
The source Storage Domain (A) has UserBasedTemplateVM permissions (Everyone)
The destination Storage Domain (B) has PowerUserRole permissions for the user initiating the clone operation. EG: they have R/W permissions for disks to that storage domain.

The idea here is that Storage Domain (A) be only limited to acting as template storage domain as PowerUserRole would allow for VM's to be created which is undesired.

This issue is pretty much linked to the other bug I reported around this: Bug 928410

The overall thought process here is to be able to isolate users/groups to specific storage domains/quotas. However allow users to clone a template in dedicated storage domain for templates OR be able to clone a template (if allowed) from others storage domains that they may not be allowed to create VM's or Templates in (Basically R/O access for clone operation).

I would think both use cases to be a perfectly valid and normal.

- DHC
Comment 4 DHC 2013-04-05 21:20:39 UTC 
Note to above typo UserBasedTemplateVM  should have been UserTemplateBasedVM :-)
Comment 5 Daniel Erez 2013-04-10 14:36:03 UTC 
(In reply to comment #1)
> Created attachment 731681 [details]
> engine debug log
> 
> I patched in the code changes in the gerrit fix against engine commit:
> b4cc077888ba11871aa4837a73498a231050e2fc
> 
> Now the user gets a permissions denied error instead. Attaching engine.log
> for debug purposes.
> 
> - DHC

Fixed on Change-Id: I7b942af8b5093848922f060c6be44e8a69374634
Comment 6 DHC 2013-04-18 15:58:55 UTC 
Verified in latest master
- DHC