Bug 1535603 - Importing a template will fail with error "Template's image doesn't exist" if the template disk was copied from another storage domain
Summary: Importing a template will fail with error "Template's image doesn't exist" if...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.8
Hardware: All
OS: Linux
medium
medium
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Nobody
QA Contact: Yosi Ben Shimon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-17 17:53 UTC by nijin ashok
Modified: 2019-05-08 12:37 UTC (History)
6 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-08 12:36:59 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1085 0 None None None 2019-05-08 12:37:22 UTC
oVirt gerrit 92631 0 master MERGED backend: extract validations into new methods 2020-07-03 14:21:09 UTC
oVirt gerrit 92632 0 master MERGED backend: check template's SD before image availability 2020-07-03 14:21:09 UTC
oVirt gerrit 92633 0 master MERGED core: support template's disk copies in OVF 2020-07-03 14:21:09 UTC

Description nijin ashok 2018-01-17 17:53:58 UTC
Description of problem:

The template disk was created initially on storage domain "TEST-A" and then later the disk was also copied to storage domain "TEST-B". However, the OVF file for the template in the storage domain B is pointing to the storage domain "TEST-A" where the template was originally created.

====
engine=# select id,storage_name from storage_domains;
                  id                  | storage_name 
--------------------------------------+--------------
 92227e03-01c8-4f41-999e-032175f20116 | TEST-B
 5b7a9526-5747-4c31-988d-e4853406ed84 | TEST-A

dd if=/dev/92227e03-01c8-4f41-999e-032175f20116/8ff0837e-4743-45b6-a72e-6f47b64baeab bs=1M |tar -xv
info.json
b0c74ded-1132-4863-af43-fbaf05a9a960.ovf

cat b0c74ded-1132-4863-af43-fbaf05a9a960.ovf |xmllint --format - |grep -B 13 -A7 "<Type>disk</Type>"
      <Item>
        <rasd:Caption>test_vm_Disk1</rasd:Caption>
        <rasd:InstanceId>14306a8d-e413-41c3-b681-b7477294cefd</rasd:InstanceId>
        <rasd:ResourceType>17</rasd:ResourceType>
        <rasd:HostResource>a020dfde-9ee3-48d5-8322-f6a21b90d8b4/14306a8d-e413-41c3-b681-b7477294cefd</rasd:HostResource>
        <rasd:Parent>00000000-0000-0000-0000-000000000000</rasd:Parent>
        <rasd:Template>00000000-0000-0000-0000-000000000000</rasd:Template>
        <rasd:ApplicationList/>
        <rasd:StorageId>5b7a9526-5747-4c31-988d-e4853406ed84</rasd:StorageId>                   ==========> Storage domain is still pointing to TEST-A
        <rasd:StoragePoolId>00000001-0001-0001-0001-000000000311</rasd:StoragePoolId>
        <rasd:CreationDate>2018/01/17 17:25:35</rasd:CreationDate>
        <rasd:LastModified>1970/01/01 00:00:00</rasd:LastModified>
        <rasd:last_modified_date>2018/01/17 17:28:09</rasd:last_modified_date>
        <Type>disk</Type>
        <Device>disk</Device>
        <rasd:Address/>
        <BootOrder>1</BootOrder>
        <IsPlugged>true</IsPlugged>
        <IsReadOnly>false</IsReadOnly>
        <Alias/>
      </Item>


====

Now if you detach the storage domain "TEST-B" and attach to a different environment and then  try to import the template, it will fail with an error "Template's image doesn't exist."

====
2018-01-17 23:12:29,305+05 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (default task-11) [19a81ab0-4b1e-4f64-bd62-9a46e38772c8] START, GetVolumeInfoVDSCommand(HostName = hosted-engine1, GetVolumeInfoVDSCommandParameters:{runAsync='true', hostId='3b3a2603-45ad-426d-a613-01a5754f4081', storagePoolId='00000001-0001-0001-0001-000000000311', storageDomainId='5b7a9526-5747-4c31-988d-e4853406ed84', imageGroupId='a020dfde-9ee3-48d5-8322-f6a21b90d8b4', imageId='14306a8d-e413-41c3-b681-b7477294cefd'}), log id: 1eed348e
2018-01-17 23:12:29,870+05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand] (default task-11) [19a81ab0-4b1e-4f64-bd62-9a46e38772c8] Failed in 'GetVolumeInfoVDS' method
2018-01-17 23:12:29,902+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-11) [19a81ab0-4b1e-4f64-bd62-9a46e38772c8] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), Correlation ID: null, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: VDSM hosted-engine1 command GetVolumeInfoVDS failed: Storage domain does not exist: (u'5b7a9526-5747-4c31-988d-e4853406ed84',)

2018-01-17 23:12:29,905+05 WARN  [org.ovirt.engine.core.bll.exportimport.ImportVmTemplateFromConfigurationCommand] (default task-11) [19a81ab0-4b1e-4f64-bd62-9a46e38772c8] Validation of action 'ImportVmTemplateFromConfiguration' failed for user admin@internal-authz. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM_TEMPLATE,TEMPLATE_IMAGE_NOT_EXIST
====


This will cause issues in moving the disk from one environment to another since users will use a "temporary" data storage domain for moving data since the export domain is deprecated.


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

rhevm-4.1.8.2-0.1.el7.noarch

How reproducible:

100%

Steps to Reproduce:

1. Create a template and copy disk from one storage domain to another.
2. Detach the second storage domain and attach to another environment and try to import the template. Import will fail with error "TEMPLATE_IMAGE_NOT_EXIST"

Actual results:

Import of template is not working if the template disk was copied from another storage domain.

Expected results:

Import should work.

Additional info:

Comment 2 Yosi Ben Shimon 2018-11-07 15:15:42 UTC
Tested using:
ovirt-engine-4.3.0-0.0.master.20181101091940.git61310aa.el7.noarch

Actual result:
The template imported successfully without the error message saying that the template image not exist.

Additional info:
I was able to reproduce this bug using the same scenario on 4.2.7 but the target milestone is 4.3.

Moving to VERIFIED

Comment 4 RHV bug bot 2018-12-10 15:12:46 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 5 RHV bug bot 2019-01-15 23:35:14 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops

Comment 7 errata-xmlrpc 2019-05-08 12:36:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085


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