Bug 967523 - engine: after LSM failure of vm based on template we fail to delete the template image in dst domain because volume is still marked as shared
Summary: engine: after LSM failure of vm based on template we fail to delete the templ...
Keywords:
Status: CLOSED DUPLICATE of bug 965936
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.2.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 3.3.0
Assignee: Ayal Baron
QA Contact: Haim
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-27 10:53 UTC by Dafna Ron
Modified: 2016-02-10 20:48 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-09 07:57:48 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (465.38 KB, application/x-gzip)
2013-05-27 10:53 UTC, Dafna Ron
no flags Details
logs from failure of LSM (2.06 MB, application/x-gzip)
2013-05-27 10:55 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2013-05-27 10:53:55 UTC
Created attachment 753565 [details]
logs

Description of problem:

I created a failure in LSM for a vm based on a template. 
after the failure I deleted the vm and deleted the template. 
the template was reported as removed but when we try to import the same template to the target domain we fail because the volume already exists. 
looking at the logs we can see that when we deleted the template we failed to delete the volume on the target domain because the volume is shared. 

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

sf17.1

How reproducible:

100%

Steps to Reproduce:
1. in iscsi storage with multiple domains import a template
2. copy the template to all domains
3. create a vm from the template (as thin copy) and run the vm n the hsm
4. live storage migrate the vm disk
5. when engine logs 'FINISH, CreateSnapshotVDSCommand' block connectivity to the storage from the hsm host
6. when the host becomes non-operational restore the connectivity to the storage from the hsm 
7. after all is restored, remove the vm and the template
8. try to import the template back to the setup

Actual results:

we fail to remove the template volume from the dst domain because its marked as shared. 
we cannot import the template back to the setup because it already exists. 

Expected results:

we should be able to remove the template from all domains or at the very least report that we failed to remove the template from one of the domains so that user can contact gss. 
 
Additional info: logs

Comment 1 Dafna Ron 2013-05-27 10:55:06 UTC
Created attachment 753566 [details]
logs from failure of LSM

attaching also the logs from the LSM failure (before the delete).

Comment 2 Daniel Erez 2013-07-09 07:57:48 UTC

*** This bug has been marked as a duplicate of bug 965936 ***

Comment 3 Maor 2013-07-09 14:47:29 UTC
After BZ965936 will be resolved, The disks should reflect the real current status in the storage.
the user should see an extra illegal disk when move operation will fail.

When the user will try to delete the template which is related to the disk that has been failed on move, an appropriate CDA message should notify the user which disk in the engine is related to the volume of the template.


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