Bug 1393257 - Failed to register template that has disks on more than one storage domain
Summary: Failed to register template that has disks on more than one storage domain
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.0.5.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.1.0-beta
: ---
Assignee: Maor
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On: 1380365 1419364 1419470
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-09 08:16 UTC by Eyal Shenitzky
Modified: 2017-02-15 15:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
This update adds the ability to import partial Templates through REST. This allows you to register a template even if some of the storage domains are missing. The following is a REST request for importing a partial unregistered template. POST /api/storagedomains/xxxxxxx-xxxx-xxxx-xxxxxx/templates/xxxxxxx-xxxx-xxxx-xxxxxx/register HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <cluster id='bf5a9e9e-5b52-4b0d-aeba-4ee4493f1072'></cluster> <allow_partial_import>true</allow_partial_import> </action>
Clone Of:
Environment:
Last Closed: 2017-02-15 15:04:02 UTC
oVirt Team: Storage
rule-engine: ovirt-4.1+
rule-engine: planning_ack+
rule-engine: devel_ack+
ratamir: testing_ack+


Attachments (Terms of Use)
engine and vdsm logs (569.73 KB, application/x-bzip)
2016-11-09 08:16 UTC, Eyal Shenitzky
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 67463 0 master MERGED core: Use lazy init for template's images on register. 2016-12-06 18:39:44 UTC

Description Eyal Shenitzky 2016-11-09 08:16:48 UTC
Created attachment 1218843 [details]
engine and vdsm logs

Description of problem:

When trying to register template that has disks on 2 or more storage domains,
The operation failed with the following error massage:

"Cannot import Template. Template's image doesn't exist."

Log massage from the engine.log:

2016-11-09 09:52:14,843 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (default task-8) [73262dd] IrsBroker::getImageInfo::Failed getting image info imageId='3714793a-4ec2-423c-8d72-9d90b6669ead' does not exist on domainName='nfs_1', domainId='c0387a49-60d1-4735-9d3b-e4cf78492bf8', error code: 'ImagePathError', message: Image path does not exist or cannot be accessed/created: (u'/rhev/data-center/mnt/10.35.110.11:_Storage__NFS_storage__local__ge3__nfs__1/c0387a49-60d1-4735-9d3b-e4cf78492bf8/images/8d970315-a3e6-44f9-87fa-8fb4f43483e9',)


Version-Release number of selected component (if applicable):
Engine - 4.0.5.5-0.1.el7ev
Vdsm - 4.18.15.2-1.el7ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Create a VM with one disk on storage domain A an one disk on storage
domain B.
2.Make a template from the VM created in 1.
3.Detach domain A or domain B.
4.Remove the domain that detached in 3 from the data center without formatting   it.
5.Remove the template that created in 2 (the template should remain because it
has disks on two storage domain)
6.Import the storage domain from 4 to the data center and activate it.
7.Try to register the template from 2

Actual results:
Template registration failed

Expected results:
Template registration should succeed

Additional info:
Logs of the engine and vdsm are attached

Comment 1 Maor 2016-11-09 16:44:49 UTC
This is since we don't importing partial entities such as VMs and Templates, same as we don't allow to import Template form an export domain that has missing disks.

This scenario might be addressed as part of https://bugzilla.redhat.com/1380365

Comment 2 Maor 2016-11-15 00:44:17 UTC
(In reply to Maor from comment #1)
> This is since we don't importing partial entities such as VMs and Templates,
> same as we don't allow to import Template form an export domain that has
> missing disks.
> 
> This scenario might be addressed as part of
> https://bugzilla.redhat.com/1380365

Closing it after discussed this with Allon.
The behavior of importing entities from export domain and register unregistered entities  should be the same.
Since we don't support importing of partial templates from export domain the behavior should stay the same also unregistered entities.

Comment 3 Eyal Shenitzky 2016-11-16 06:29:09 UTC
In the past, when we tried to import template that has disks on different domain it works.
We can see that the behavior is not consistent.
If we shouldn't be an able to import that template so why do we have that option?
And even if they want it to behave that way, there should be more verbose error message.

Comment 4 Maor 2016-11-16 07:40:58 UTC
We basically want to keep the same behavior being done today for export domain

(In reply to Eyal Shenitzky from comment #3)
> In the past, when we tried to import template that has disks on different
> domain it works.
> We can see that the behavior is not consistent.

That case is different, in this case the Template has missing disk and not a disk on a different domain.
You removed the disk at step 5 while the OVF in the first storage domain still kept the old OVF of the Template which indicated two disks.
This scenario is like you will have an export domain which contains a Template's OVF with 2 disks while one of the disks is missing.

> If we shouldn't be an able to import that template so why do we have that
> option?

It is the same behavior for export domain which contains a Template with missing disk.
We want to show the user there is a candidate Template to import, once it will fail the user can check in the log what is the problem and decide what to do.
There might be a backed up storage domain.

> And even if they want it to behave that way, there should be more verbose
> error message.

It basically the same error which is being presented when importing from an Export storage domain and one of the disks is missing.
I agree that a more appropriate message will be: "The Template's disk on storage domain A is missing"
The problem is that once a disk cannot be found most of the times is because the domain was not imported yet so the engine cannot print the storage domain name that is missing from the VM's OVFm we can only know the storage id and that is being printed in the engine log.

Comment 5 Maor 2016-11-16 07:41:20 UTC
We basically want to keep the same behavior being done today for export domain

(In reply to Eyal Shenitzky from comment #3)
> In the past, when we tried to import template that has disks on different
> domain it works.
> We can see that the behavior is not consistent.

That case is different, in this case the Template has missing disk and not a disk on a different domain.
You removed the disk at step 5 while the OVF in the first storage domain still kept the old OVF of the Template which indicated two disks.
This scenario is like you will have an export domain which contains a Template's OVF with 2 disks while one of the disks is missing.

> If we shouldn't be an able to import that template so why do we have that
> option?

It is the same behavior for export domain which contains a Template with missing disk.
We want to show the user there is a candidate Template to import, once it will fail the user can check in the log what is the problem and decide what to do.
There might be a backed up storage domain.

> And even if they want it to behave that way, there should be more verbose
> error message.

It basically the same error which is being presented when importing from an Export storage domain and one of the disks is missing.
I agree that a more appropriate message will be: "The Template's disk on storage domain A is missing"
The problem is that once a disk cannot be found most of the times is because the domain was not imported yet so the engine cannot print the storage domain name that is missing from the VM's OVF we can only know the storage id and that is being printed in the engine log.

Comment 6 Maor 2016-11-20 20:06:06 UTC
We can use the fix for BZ1380365.
Using the allow_partial_import flag through REST to import a partial Template

POST /api/storagedomains/xxxxxxx-xxxx-xxxx-xxxxxx/templates/xxxxxxx-xxxx-xxxx-xxxxxx/register HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <cluster id='bf5a9e9e-5b52-4b0d-aeba-4ee4493f1072'></cluster>
    <allow_partial_import>true</allow_partial_import>
</action>

Comment 7 Maor 2016-12-06 21:29:18 UTC
Yaniv, should this be solved only from the REST or do we want this also for the GUI?

Comment 8 Maor 2016-12-06 21:33:15 UTC
(In reply to Maor from comment #7)
> Yaniv, should this be solved only from the REST or do we want this also for
> the GUI?

Rephrase: This bug is solved with the partial_import flag implemented through the REST, do we want this option also in the GUI or this should be enough?

Comment 9 Yaniv Lavi 2016-12-06 23:24:48 UTC
Let ask the requestor.

Comment 10 Eyal Shenitzky 2016-12-11 07:18:21 UTC
I think that a template with disks of more than one storage domain is a common thing, so there should be implementation in the GUI for this feature.

Comment 11 Yaniv Lavi 2016-12-11 10:30:33 UTC
(In reply to Eyal Shenitzky from comment #10)
> I think that a template with disks of more than one storage domain is a
> common thing, so there should be implementation in the GUI for this feature.

Until there is a external request to get GUI for this feature, we will support for the HC use case and for your automation. We won't add GUI unless it is needed for a use case.

Comment 12 Sandro Bonazzola 2017-01-25 07:56:20 UTC
4.0.6 has been the last oVirt 4.0 release, please re-target this bug.

Comment 13 Tal Nisan 2017-01-30 10:55:50 UTC
Maor, how can this be in MODIFIED status when it wasn't backported to 4.1?

Comment 14 Tal Nisan 2017-01-30 11:10:23 UTC
Apparently patch was merged before the 4.1 branch creation but for some reason was not moved to ON_QA since

Comment 15 Eyal Shenitzky 2017-02-05 12:03:58 UTC
 Verified with the following code:
------------------------------------------
rhevm-4.1.0.4-0.1.el7

Verified with the following scenario:
------------------------------------------
Steps to reproduce:
------------------------------------------
1.Create a VM with one disk on storage domain A an one disk on storage
domain B.
2.Make a template from the VM created in 1.
3.Detach domain A or domain B.
4.Remove the domain that detached in 3 from the data center without formatting   it.
5.Remove the template that created in 2 (the template should remain because it
has disks on two storage domain)
6.Import the storage domain from 4 to the data center and activate it.
7.Try to register the template from 2 using:

POST /api/storagedomains/xxxxxxx-xxxx-xxxx-xxxxxx/templates/xxxxxxx-xxxx-xxxx-xxxxxx/register HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <cluster id='bf5a9e9e-5b52-4b0d-aeba-4ee4493f1072'></cluster>
    <allow_partial_import>true</allow_partial_import>
</action>

Verification failed.

Result:
<action>
    <allow_partial_import>true</allow_partial_import>
    <cluster id="a205d3ea-e61c-4d0e-ad55-daaf4ab7f782"/>
    <fault>
        <detail>java.lang.NullPointerException</detail>
        <reason>Operation Failed</reason>
    </fault>
    <status>failed</status>
</action>

Comment 16 Maor 2017-02-05 14:01:08 UTC
The bug you have encounter was caused due to the following change https://gerrit.ovirt.org/#/c/69772/
Once an unregistered template is being registered the updateMaxMemorySize will try to call getOsId on vmBase which is null.

It is not related to partial_import but this is a failure that will happen on every import of unregistered template.
Please open a blocker bug on that issue and put this bug as dependent on the new bug

Comment 18 Raz Tamir 2017-02-14 09:18:45 UTC
Moving this to assign as it still fails and we don't have a fix for it because it depend on different bug https://bugzilla.redhat.com/show_bug.cgi?id=1419364 that is also ON_QA

Comment 19 Maor 2017-02-14 09:45:59 UTC
(In reply to Raz Tamir from comment #18)
> Moving this to assign as it still fails and we don't have a fix for it
> because it depend on different bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1419364 that is also ON_QA

https://bugzilla.redhat.com/1419364 is ON_QA, so this bug should be solved.
What is the exception that you see?

Comment 20 Raz Tamir 2017-02-15 12:53:56 UTC
Hi Maor,
After trying to register a template with the flag - <allow_partial_import> the registration succeeds.
However, it is impossible to clone a VM from that template - bug 1422508

Moving to verified - rhevm-4.1.1-0.1.el7


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