Bug 871047 - engine: after iso domain becomes inactive due to connectivity issues -> activating iso domain manually on new spm will re-assign spm
Summary: engine: after iso domain becomes inactive due to connectivity issues -> activ...
Keywords:
Status: CLOSED DUPLICATE of bug 854975
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 3.1.0
Assignee: Nobody's working on this, feel free to take it
QA Contact:
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-29 13:43 UTC by Dafna Ron
Modified: 2016-02-10 18:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-29 15:06:09 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (1.14 MB, application/x-gzip)
2012-10-29 13:43 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2012-10-29 13:43:12 UTC
Created attachment 635017 [details]
logs

Description of problem:

I blocked iso domain from SPM. 
after the storage became inactive I activated a second host and once it became SPM I manually activated the iso domain. 
getFloppyList fails due to permission issue and we re-assign SPM again. 

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

si22.1

How reproducible:

100%

Steps to Reproduce:
1. have one host with iscsi data domain and iso domain which has permission issues. 
2. block connectivity to the iso domain -> storage becomes inactive
3. activate a second host -> new host becomes spm
4. manually activate the iso domain in the new spm  

Actual results:

GetFloppyListVDSCommand fails and engine stops SPM and tries to re-contend the original host - since storage is inaccessible from the original spm we again move SPM back. 

Expected results:

we should not re-contend SPM if getFloppyList or getIsoList fails as long as connectStorageServer succeeded. 

Additional info: logs

Comment 1 Itamar Heim 2012-10-29 15:06:09 UTC

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


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