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:
Dafna, Did you delete the VM or import as clone?
(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.
(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?
(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.
Fede, Is it feasible that VDSM will support copyImage when the image chain is based on different Storage Domains?
(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.
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?
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?
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
Maor was in the middle of researching this. Maor - any conclusions?
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).
Opened bug https://bugzilla.redhat.com/show_bug.cgi?id=1161211 (RFE)
Eyal, can you please add the version it is fixed in? Thnaks
(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.
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
Liron, can you take a look please?
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.
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
RHEV-M 3.5.0 has been released, closing this bug.