Bug 975032 - webadmin: clone vm from template on multiple domain does not keep the disk location as default
Summary: webadmin: clone vm from template on multiple domain does not keep the disk lo...
Keywords:
Status: CLOSED DUPLICATE of bug 927342
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.2.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.3.0
Assignee: Nobody's working on this, feel free to take it
QA Contact: Pavel Stehlik
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-17 13:02 UTC by Dafna Ron
Modified: 2016-02-10 19:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-09 14:01:44 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screen shots and logs (2.02 MB, application/x-gzip)
2013-06-17 13:02 UTC, Dafna Ron
no flags Details

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


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