Bug 966103 - webadmin: can't import a vm linked to template which has a snapshot if the template does not exist in the export domain but exists in the setup
webadmin: can't import a vm linked to template which has a snapshot if the te...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.2.0
x86_64 Linux
unspecified Severity high
: ---
: 3.5.0
Assigned To: Liron Aravot
lkuchlan
storage
:
Depends On: 1120721 1135987 1169100
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-22 09:34 EDT by Dafna Ron
Modified: 2016-02-10 13:24 EST (History)
15 users (show)

See Also:
Fixed In Version: ovirt-engine-3.5.0_vt9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1169100 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
amureini: Triaged+


Attachments (Terms of Use)
Engine and vdsm logs (266.45 KB, application/x-gzip)
2014-11-30 03:42 EST, lkuchlan
no flags Details
xml and json logs (4.15 MB, application/x-gzip)
2014-12-02 03:29 EST, lkuchlan
no flags Details

  None (edit)
Description Dafna Ron 2013-05-22 09:34:42 EDT
Description of problem:

we actually have twp scenarios here which have a user impact: 

1. create a vm from template + add a snapsht -> export the vm without the template -> import the vm ->  UI: One of the templates cannot be found in the system, VM(s) cannot be imported

2. create a vm from template and run the vm -> LSM the vm -> shut down the vm -> export the vm -> remove the vm -> import the vm: Some imported VMs depend on one or more templates which are not available in the system. Therefore you must Import those VMs with 'collapse snapshots', another option is to Import missing templates first and then try import the VMs again

 
Version-Release number of selected component (if applicable):

sf17.2

How reproducible:

100%

Steps to Reproduce:
1. create a vm based on template 
2. create a snapshot
3. export the vm without the template
4. try to import the vm
5. export the template
6. try to export the vm

Actual results:

1. we cannot import the vm if the template does not exist in export domain although it exists in the setup. 
2. if the template exists in the export domain we still do not detect it in the setup and force the user to collapse and import the vm as an independent image. 

Expected results:

we should be able to detect the template and import the vm


USER IMPACT: aside from forcing the user to create an independent image, if the user did a LSM and wants to back up the vm before the merge, every time they will try to import the backup we will merge the snapshots created during LSM (so if we had corruption it will happen over and over again). 
 
Additional info:
Comment 2 Ayal Baron 2013-05-23 03:11:55 EDT
Dafna,

Did you delete the VM or import as clone?
Comment 3 Dafna Ron 2013-05-23 04:03:01 EDT
(In reply to Ayal Baron from comment #2)
> Dafna,
> 
> Did you delete the VM or import as clone?

I deleted the vm from the setup.
Comment 4 Ayal Baron 2013-05-23 16:25:19 EDT
(In reply to Dafna Ron from comment #3)
> (In reply to Ayal Baron from comment #2)
> > Dafna,
> > 
> > Did you delete the VM or import as clone?
> 
> I deleted the vm from the setup.

Then please update the reproduction steps with the full set of actions so we'll understand the flow properly.

1. create a vm based on template 
2. create a snapshot
3. export the vm without the template
4. delete the vm
5. try to import the vm
6. export the template
7. try to export the vm

Is above correct? are we missing anything else?
What error does the user get?
Does the request reach vdsm? (it sounds like a bug Edu has already solved)
What about logs?
Comment 5 Dafna Ron 2013-05-27 02:51:03 EDT
(In reply to Ayal Baron from comment #4)
> (In reply to Dafna Ron from comment #3)
> > (In reply to Ayal Baron from comment #2)
> > > Dafna,
> > > 
> > > Did you delete the VM or import as clone?
> > 
> > I deleted the vm from the setup.
> 
> Then please update the reproduction steps with the full set of actions so
> we'll understand the flow properly.
> 
> 1. create a vm based on template 
> 2. create a snapshot
> 3. export the vm without the template
> 4. delete the vm
> 5. try to import the vm
> 6. export the template
> 7. try to export the vm
> 

these steps are correct

> Is above correct? are we missing anything else?
> What error does the user get?

its a UI bug, user can't send the request. 

if the template does not exist in the export domain but exists in the setup webadmin will give an alert in the export dialogue without an option to press OK: 

"One of the templates cannot be found in the system, VM(s) cannot be imported"

if the template exists in the export domain the collapse check box is checked and greyed out (forcing user to collapse). the following is shown to the user in the export dialogue: 

"Some imported VMs depend on one or more templates which are not available in the system. Therefore you must Import those VMs with 'collapse snapshots', another option is to Import missing templates first and then try import the VMs again" 

> Does the request reach vdsm? (it sounds like a bug Edu has already solved)

it does not even reach engine

> What about logs?

there are no logs for UI.
Comment 10 Maor 2014-09-01 11:03:51 EDT
Fede,

Is it feasible that VDSM will support copyImage when the image chain is based on different Storage Domains?
Comment 11 Federico Simoncelli 2014-09-03 18:24:09 EDT
(In reply to Maor from comment #10)
> Fede,
> 
> Is it feasible that VDSM will support copyImage when the image chain is
> based on different Storage Domains?

You mean use copyImage to copy+collapse images from one storage domain to another?

copyImage <sdUUID> <spUUID> <vmUUID> <srcImgUUID> <srcVolUUID> <dstImgUUID>
          <dstVolUUID> <dstDescr> <dstSdUUID> <volType> <volFormat> <preallocate>
          [<postZero>] [<force>]

The parameters sdUUID and dstSdUUID are the source and destination.

If instead you mean an image that somehow got split in two different storage domains, then no, it would be extremely hard.

Anyway comment 5 is identifying this as an UI issue, if there were new findings it would be better to update the bz because I am not getting the connection with copyImage and I can't help further.
Comment 12 Maor 2014-09-04 01:46:55 EDT
Hi Fede,

You guessed right, I meant the copy+collapse images from one storage domain to another, while there are on two different storage domains.

It is not a UI bug since even if we will enable the OK button, we can't still done the copy+collapse as you mentioned in the previous comment.

Allon, do you got other ideas or maybe should we leave the behavior as it is? meaning force the user to have the Template in the Export domain when he want to import a VM using copy collapse?
Comment 13 Allon Mureinik 2014-09-04 07:32:37 EDT
Actually, question - if the template exists in the data domain and the VM doesn't, it's just a stupid copy - why don't we support copy WITHOUT collapsing?
Comment 14 Maor 2014-09-04 10:37:57 EDT
Will try that.
If that works without copy collapse, there should be also  a change in the CDA message to indicate that import can only works without copy collapse
Comment 15 Allon Mureinik 2014-09-18 07:49:27 EDT
Maor was in the middle of researching this.
Maor - any conclusions?
Comment 16 Liron Aravot 2014-11-06 11:04:38 EST
1. I've tested the described scenario on 3.5 setup and it seems to work.

2. replying to Allon:
> Actually, question - if the template exists in the data domain and the VM
> doesn't, it's just a stupid copy - why don't we support copy WITHOUT
> collapsing?

When the template exists in the data domain there's no problem to import without collapse (the user should just choose the right domains for the operation - the one's with the template disks).

3.  As the described scenario works, moving to ON_QA, Allon - i believe that we have an RFE for the issue specified in [1], if not i'll open one for it.
(In reply to Allon Mureinik from comment #13)

[1] A general problem is to generally support clone without collapse (which will enable to import a vm based on a template when the template doesn't exist on the export domain and the vm already exist in the setup).
Comment 17 Liron Aravot 2014-11-06 11:14:05 EST
Opened bug https://bugzilla.redhat.com/show_bug.cgi?id=1161211 (RFE)
Comment 18 lkuchlan 2014-11-23 09:18:20 EST
Eyal, can you please add the version it is fixed in?
Thnaks
Comment 19 Allon Mureinik 2014-11-23 13:58:38 EST
(In reply to lkuchlan from comment #18)
> Eyal, can you please add the version it is fixed in?
> Thnaks
RHEVM 3.5.0, build vt9 should cover this.
Comment 20 lkuchlan 2014-11-30 03:42:10 EST
Created attachment 962867 [details]
Engine and vdsm logs

Tested using RHEVM 3.5 vt11
After exporting VM based on template, the VM blocked on status image locked
Comment 21 Allon Mureinik 2014-11-30 10:06:42 EST
Liron, can you take a look please?
Comment 22 Allon Mureinik 2014-12-01 03:30:59 EST
This bug should be blocked by bug 1169100.
According to that bug, there's a problem only with JSONRPC. QE can continue validating this one in XMLRPC in the meanwhile if they think there's any benefit in it - up to you guys.
Comment 23 lkuchlan 2014-12-02 03:29:46 EST
Created attachment 963586 [details]
xml and json logs

Tested on RHEVM 3.5 vt11
With xml rpc all the step works, on the other hand, with json rpc there is a problem with export operation, but this is other bug

attached xml and json logs
Comment 24 Allon Mureinik 2015-02-16 14:12:07 EST
RHEV-M 3.5.0 has been released, closing this bug.
Comment 25 Allon Mureinik 2015-02-16 14:12:09 EST
RHEV-M 3.5.0 has been released, closing this bug.

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