Created attachment 1191300 [details] Engine and VDSM log Description of problem: Creating a VM from a template that was registered to the environment and has 2 disks (one disk on block-based storage domain and the other on file-based storage domain) fails with error: VDSM host_mixed_2 command failed: Image path does not exist or cannot be accessed/created Engine log Error: 2016-08-16 15:54:48,193 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler10) [] BaseAsyncTask::logEndTaskFailure: Task 'ea0db169-22 ea-407c-b74c-44ef73c6e115' (Parent Command 'CreateSnapshotFromTemplate', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with failure: -- Result: 'cleanSuccess' -- Message: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Image path does not exist or cannot be accessed/created, cod e = 254', -- Exception: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Image path does not exist or cannot be accessed/created, c ode = 254' Version-Release number of selected component (if applicable): vdsm-4.18.11-1.el7ev.x86_64 Engine-4.0.2.6-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1.Create a VM with 2 disks, one [disk-1]file-based and the other [disk-2]block-based 2.Create a template from the VM in step 1 3.Detach the storage domain that contains disk-2 4.Delete the template from step 2 5.Attach the storage domain from step 3 back to the environment 6.Import the template from the attached storage domain back to the environment 7.Try to create a VM from the imported template from step 6 Actual results: VM creation fails. Expected results: VM should create successfully. Additional info: Engine and VDSM logs are attached
Since the Template's disk was deleted, creating a VM from that Template should not be supported. The solution for this bug should be in the registration process of the Template. Every time a Template will be registered to the setup, the engine will validate if all its volumes exists. In that case we can have one of two outcomes: a. If one of the disks will not be found, the operation of registering the Template will fail. b. If one of the disks will not be found, the user will get a notification that some of the disks were not found, and the user will decide whether he wants to continue to import the Template without this disk or not. - Keep in mind that if we support this behavior then we might also support removing of Template's disks in an existing Template, with all its outcomes...
(In reply to Maor from comment #1) > Since the Template's disk was deleted, creating a VM from that Template > should not be supported. > > The solution for this bug should be in the registration process of the > Template. > Every time a Template will be registered to the setup, the engine will > validate if all its volumes exists. > In that case we can have one of two outcomes: > > a. If one of the disks will not be found, the operation of registering the > Template will fail. > > b. If one of the disks will not be found, the user will get a notification > that some of the disks were not found, and the user will decide whether he > wants to continue to import the Template without this disk or not. > - Keep in mind that if we support this behavior then we might also > support removing of Template's disks in an existing Template, with all its > outcomes... Based on the behavior of export storage domain, once a template is missing one of its disks the import of the template fails since the copy operation fails. Based on that, and to keep the behavior consistent, I would consider to go on option 1, which means that the engine will fail the operation
(In reply to Maor from comment #2) > (In reply to Maor from comment #1) > > Since the Template's disk was deleted, creating a VM from that Template > > should not be supported. > > > > The solution for this bug should be in the registration process of the > > Template. > > Every time a Template will be registered to the setup, the engine will > > validate if all its volumes exists. > > In that case we can have one of two outcomes: > > > > a. If one of the disks will not be found, the operation of registering the > > Template will fail. > > > > b. If one of the disks will not be found, the user will get a notification > > that some of the disks were not found, and the user will decide whether he > > wants to continue to import the Template without this disk or not. > > - Keep in mind that if we support this behavior then we might also > > support removing of Template's disks in an existing Template, with all its > > outcomes... > > Based on the behavior of export storage domain, once a template is missing > one of its disks the import of the template fails since the copy operation > fails. > Based on that, and to keep the behavior consistent, I would consider to go > on option 1, which means that the engine will fail the operation Agreed.
When trying to register (import) the template: Error while executing action: Cannot import Template. Template's image doesn't exist.
4.0.5 has been released, closing.