Bug 967602 - vdsm: we fail to destroy vm that was paused on EIO with "Drive is not a vdsm image"
Summary: vdsm: we fail to destroy vm that was paused on EIO with "Drive is not a vdsm ...
Keywords:
Status: CLOSED DUPLICATE of bug 980054
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.2.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.3.0
Assignee: Nobody's working on this, feel free to take it
QA Contact: Dafna Ron
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-27 14:23 UTC by Dafna Ron
Modified: 2016-02-10 18:41 UTC (History)
8 users (show)

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


Attachments (Terms of Use)
logs (1.56 MB, application/x-gzip)
2013-05-27 14:23 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2013-05-27 14:23:49 UTC
Created attachment 753644 [details]
logs

Description of problem:

I live storage migrated a vm disk and blocked connectivity to the storage from the hsm only (host that the vm was running on). 
when the vm paused I tried to destroy it and failed in vdsm with Drive is not a vdsm image followed by: 

m volExtensionChunk:1024 watermarkLimit:536870912
Traceback (most recent call last):
  File "/usr/share/vdsm/clientIF.py", line 334, in teardownVolumePath
    res = self.irs.teardownImage(drive['domainID'],
  File "/usr/share/vdsm/libvirtvm.py", line 1071, in __getitem__
    raise KeyError(key)
KeyError: 'domainID'


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

sf17.1
vdsm-python-4.10.2-21.0.el6ev.x86_64

How reproducible:

100%

Steps to Reproduce:
1. in iscsi storage with two hosts and two domains create a vm from template and run it on the hsm
2. LSM the vm disk 
3. block connectivity to the storage in hsm only when engine logs "SyncImageGroupDataVDSCommand" 
4. when the vm pauses try to destroy it (power off)

Actual results:

we fail to destroy the vm with no alert in UI. 

Expected results:

we should be able to destroy the vm

Additional info: logs

Comment 1 Ayal Baron 2013-07-10 08:44:43 UTC
Fede, is this solved already?

Comment 2 Ayal Baron 2013-07-16 14:16:49 UTC

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


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