Bug 976243 - [rest-api] When creating template, target domain is passed as a source
Summary: [rest-api] When creating template, target domain is passed as a source
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.2.0
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
: 3.3.0
Assignee: Shahar Havivi
QA Contact: Pavel Novotny
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-20 08:00 UTC by Jakub Libosvar
Modified: 2015-09-22 13:09 UTC (History)
9 users (show)

Fixed In Version: is11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
engine vdsm logs (39.76 KB, application/gzip)
2013-06-20 08:00 UTC, Jakub Libosvar
no flags Details

Description Jakub Libosvar 2013-06-20 08:00:00 UTC
Created attachment 763312 [details]
engine vdsm logs

Description of problem:
When I have two storage domains (SD0 and SD1) and want to create a template on SD1, while source image is on SD0, it fails because target domain (SD1) is passed as a source - i.e. SD1 is passed instead of SD0

Version-Release number of selected component (if applicable):
rhevm-3.2.1-0.31.el6ev.noarch


How reproducible:
Always

Steps to Reproduce:
1. Have two storage domains, VM with a disk on SD0
2. Via API create a template on SD1

Actual results:
GetImageInfoVDSCommand fails due to wrong SD uuid:

GetImageInfoVDSCommand( storagePoolId = a86b5970-7340-4808-96e0-0f0f9c3aaa10, ignoreFailoverLimit = false, compatabilityVersion = null, storageDomainId = b58d59a4-c5ba-4ea9-8dff-29685175cc59, imageGroupId = ecde57a6-e7fa-475a-97c0-24e0738a9707, imageId = 968de0cf-8051-4797-84bd-a1c6e34b1a65), log id: 43658fe7


Expected results:
Same as webadmin does:

GetImageInfoVDSCommand( storagePoolId = a86b5970-7340-4808-96e0-0f0f9c3aaa10, ignoreFailoverLimit = false, compatabilityVersion = null, storageDomainId = 6a083563-0483-46be-8ef0-ce7d5bce4e8f, imageGroupId = ecde57a6-e7fa-475a-97c0-24e0738a9707, imageId = 968de0cf-8051-4797-84bd-a1c6e34b1a65), log id: 6fbce0df


Additional info:
Logs are attached
Body sent to /api/templates:
<template>
    <name>test_templ</name>
    <vm id="3f011275-4cab-4d56-b88d-936eef779e5c"/>
    <cluster id="be951814-2c61-48d0-80e6-1b6cdb8ac4f4"/>
    <storage_domain id="b58d59a4-c5ba-4ea9-8dff-29685175cc59"/>
</template>

Comment 1 Shahar Havivi 2013-08-08 11:00:00 UTC
It's looks like a regression from the following fix:
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=083eb0820b88d40f40f19006f97cfc580b84d4a6

The fix in this patch is overriding the source image domain with the destination domain (and as long as they the same we didn't have any problem).
Patch:
http://gerrit.ovirt.org/#/c/17827/

Jakub,
This patch will not fix your problem,
The reason that you have a different results in the UI and the API is that you need to set the API disks.

By doing so the API will build the diskInfoDestinationMap which you get for free in the UI.
This suppose to work for you without applying the patch.

Comment 3 Pavel Novotny 2013-09-27 16:43:09 UTC
Verified in rhevm-3.3.0-0.23.master.el6ev (is16).

Creating a VM template via API with a request body described in comment#0 is now successful.
But as was explained in comment#1, tempate disk(s) will be created on the original storage domain (refereced as SD0 in the reproducer). In other words, the <storage_domain> element in the request body does not affect the target location of template disks.

Comment 4 Itamar Heim 2014-01-21 22:24:02 UTC
Closing - RHEV 3.3 Released

Comment 5 Itamar Heim 2014-01-21 22:25:04 UTC
Closing - RHEV 3.3 Released

Comment 6 Itamar Heim 2014-01-21 22:28:38 UTC
Closing - RHEV 3.3 Released


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