| Summary: | Create a template via the API ignores the destination storage domain | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Raz Tamir <ratamir> | ||||
| Component: | BLL.Storage | Assignee: | Tal Nisan <tnisan> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Eyal Shenitzky <eshenitz> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0.2.7 | CC: | amureini, bugs, ratamir, tnisan, ylavi | ||||
| Target Milestone: | ovirt-4.1.2 | Keywords: | Automation | ||||
| Target Release: | --- | Flags: | ylavi:
ovirt-4.1?
ylavi: planning_ack+ ratamir: devel_ack? ratamir: testing_ack? |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-03-15 15:50:43 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: | |||||
| Attachments: |
|
||||||
Is this the V3 or V4 API? V4 API This also occurs in V3 and this is actually the behavior since version 3.1 in which the option to specify a destination storage domain per disk was introduced. The behavior is that when a storage domain is specified it will be set as destination for all disks ONLY if a disk attachments list was supplied in the request body and in that case it is overriding all storage domain data that is defined for each disk in the list. With regards to this bug there are two options: 1. Continue ignoring this parameter if a disk attachments list was not supplied with the request (thus closing as NOTABUG) 2. Override all disks destination domain to the storage domain defined in the parameter even if a disk list was not supplied Aside for that there is another bug which ignores the storage domain defined to each disk attachment in the list in the request and for that another bug will be opened (In reply to Tal Nisan from comment #3) > 2. Override all disks destination domain to the storage domain defined in > the parameter even if a disk list was not supplied > We should use this behavior it makes more sense. > Aside for that there is another bug which ignores the storage domain defined > to each disk attachment in the list in the request and for that another bug > will be opened This there is no way to define a target storage then, right? If this works per disk, then this is good enough unless a user\customer requests to change this. |
Created attachment 1193929 [details] engine and vdsm logs Description of problem: Trying to create a template via the API and specifying the destination storage domain for the template's disk, will ignores the specified storage domain and will create the template's disk on the source storage domain which is the VM's disk storage domain from which the template was created. The REST API command: POST /api/templates <template> <name>test</name> <cluster id="2a2c5474-a207-42f0-8d5c-9c671fc99023"/> <storage_domain id="e4146ca7-9465-4fed-9ab3-07391953c859"/> <vm id="d18197e4-126d-437c-a29a-f4811d6417f8"/> </template> From the enving.log: 2016-08-25 11:45:12,648 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] (default task-4) [ca82b37] START, CopyImageVDSCommand( CopyImageVDSCommandParameters:{runAsync='true', storagePoolId='d06bd8de-ae75-45ce-8d15-7be11dad7e8a', ignoreFailoverLimit='false', storageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7', imageGroupId='0522f4e7-74fa-4066-8b34-33a201ed1100', imageId='2b860890-8503-4115-b379-1346ad2a2e0a', dstImageGroupId='3ea19e4c-3339-44a6-91c2-354dd7c28708', vmId='d18197e4-126d-437c-a29a-f4811d6417f8', dstImageId='2339fe60-f1dc-4589-be2a-d903830821cd', imageDescription='{"DiskAlias":"golden_mixed_virtio_template","DiskDescription":"golden_env_mixed_virtio_0_Disk1 (07f46b6)"}', dstStorageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7', copyVolumeType='SharedVol', volumeFormat='COW', preallocate='Sparse', postZero='false', force='false'}), log id: 41a5ce6f dstStorageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7' is equal to storageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7' and in the POST body <storage_domain id="e4146ca7-9465-4fed-9ab3-07391953c859"/> Via the UI this process is working fine Version-Release number of selected component (if applicable): ovirt-engine-4.0.2.7-0.1.el7ev.noarch vdsm-4.18.11-1.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create a vm with disk on storage domain A 2. Create a template via REST API of that VM specifying storage_domain='ID' where ID is the ID of storage domain B 3. Actual results: The template will create successfully but the template's disk will be created on storage domain A Expected results: Additional info: logs attached - creation of the template at 2016-08-25 11:45:12,648