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
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
(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.
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.
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.
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.
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>
Yaniv, should this be solved only from the REST or do we want this also for the GUI?
(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?
Let ask the requestor.
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.
(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.
4.0.6 has been the last oVirt 4.0 release, please re-target this bug.
Maor, how can this be in MODIFIED status when it wasn't backported to 4.1?
Apparently patch was merged before the 4.1 branch creation but for some reason was not moved to ON_QA since
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>
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
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
(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?
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