Bug 975032

Summary: webadmin: clone vm from template on multiple domain does not keep the disk location as default
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engine-webadmin-portalAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: acathrow, ecohen, iheim, jkt, Rhev-m-bugs, tnisan
Target Milestone: ---Keywords: Triaged
Target Release: 3.3.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-09 14:01:44 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:
Attachments:
Description Flags
screen shots and logs none

Description Dafna Ron 2013-06-17 13:02:09 UTC
Created attachment 762022 [details]
screen shots and logs

Description of problem:

I have a template with disks on multiple domains. 
when I clone a vm from the template we change the default location of the disks to one domain (alphabetically). 

if the user created a template with disks located on two different domains we should keep that original default when creating a vm. 

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

sf18

How reproducible:

1005

Steps to Reproduce:
1. create a DC with multiple domains
2. create a vm with multiple disks
3. create a template and make sure that the disks are located on each of the domains
4. clone a server type vm from the template

Actual results:

when we clone the vm from the template the default will be a single domain (alphabetically the first one on the list)

Expected results:

since the user created a template with images on different domains when we clone the vm from the template we should keep the original mapping since the user has created that mapping for a reason. 

Additional info:screen shots and logs

[root@cougar01 ~]# vdsClient -s 0 getStorageDomainsList
81ef11d0-4c0c-47b4-8953-d61a6af442d8
7414f930-bbdb-4ec6-8132-4640cbb3c722
38755249-4bb3-4841-bf5b-05f4a521514d

[root@cougar01 ~]# vdsClient -s 0 getStorageDomainInfo 81ef11d0-4c0c-47b4-8953-d61a6af442d8
	uuid = 81ef11d0-4c0c-47b4-8953-d61a6af442d8
	vguuid = Eq3hKP-LB4o-CSHb-U91Z-JKKN-4eQV-Pecf1l
	lver = -1
	state = OK
	version = 3
	role = Regular
	pool = ['7fd33b43-a9f4-4eb7-a885-e9583a929ceb']
	spm_id = -1
	type = ISCSI
	class = Data
	master_ver = 0
	name = Dafna-32-02

[root@cougar01 ~]# vdsClient -s 0 getStorageDomainInfo 7414f930-bbdb-4ec6-8132-4640cbb3c722
	uuid = 7414f930-bbdb-4ec6-8132-4640cbb3c722
	vguuid = yBbgfi-rjHK-TaFx-RcPj-WvMI-1Mu1-xuh8qz
	lver = 20
	state = OK
	version = 3
	role = Master
	pool = ['7fd33b43-a9f4-4eb7-a885-e9583a929ceb']
	spm_id = 2
	type = ISCSI
	class = Data
	master_ver = 3740
	name = tiger-01

[root@cougar01 ~]# vdsClient -s 0 getStorageDomainInfo 38755249-4bb3-4841-bf5b-05f4a521514d
	uuid = 38755249-4bb3-4841-bf5b-05f4a521514d
	vguuid = 4Ceo5k-vMud-sVKL-blqX-JwKo-ETN6-8ao4L9
	lver = -1
	state = OK
	version = 3
	role = Regular
	pool = ['7fd33b43-a9f4-4eb7-a885-e9583a929ceb']
	spm_id = -1
	type = ISCSI
	class = Data
	master_ver = 0
	name = Dafna-32-03

Comment 1 Tal Nisan 2013-07-09 14:01:44 UTC

*** This bug has been marked as a duplicate of bug 927342 ***