Bug 1367488
| Summary: | Failed to create VM from registered template | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Eyal Shenitzky <eshenitz> | ||||
| Component: | BLL.Storage | Assignee: | Maor <mlipchuk> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Carlos Mestre González <cmestreg> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.0.2.6 | CC: | amureini, bugs, tnisan, ylavi | ||||
| Target Milestone: | ovirt-4.0.5 | Keywords: | Automation | ||||
| Target Release: | 4.0.5 | Flags: | rule-engine:
ovirt-4.0.z+
rule-engine: blocker+ ylavi: planning_ack+ tnisan: devel_ack+ acanan: testing_ack+ |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Cause:
Registering an unregistered Template to oVirt which some of its disks were deleted from the storage domains will fail to create VMs from it duo to the error "mage path does not exist or cannot be accessed/created"
Consequence:
The user was detaching a storage domain which one of the Template's disks were reside on it and afterwards remove the Template.
Once the storage domain was imported again to the engine and the Template were registered, the other Template disks were deleted already but the Template was imported successfully, and once the user tried to create a VM based on that template, the operation failed.
Fix:
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.
Result:
The registration of the unregistered Template will fail once the disk won't exists in the storage domain
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-11-24 09:40:31 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: | |||||||
| Attachments: |
|
||||||
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. |
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