Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1535603

Summary: Importing a template will fail with error "Template's image doesn't exist" if the template disk was copied from another storage domain
Product: Red Hat Enterprise Virtualization Manager Reporter: nijin ashok <nashok>
Component: ovirt-engineAssignee: Nobody <nobody>
Status: CLOSED ERRATA QA Contact: Yosi Ben Shimon <ybenshim>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.1.8CC: lsurette, mtessun, Rhev-m-bugs, siddharth, srevivo, tnisan
Target Milestone: ovirt-4.3.0   
Target Release: 4.3.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.0_alpha Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-08 12:36:59 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:

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