Bug 1158822 - [hosted-engine] [iSCSI support] StoragePoolWrongMaster error on deployment while SD exists on the LUN
Summary: [hosted-engine] [iSCSI support] StoragePoolWrongMaster error on deployment wh...
Status: CLOSED DUPLICATE of bug 1155637
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 3.5.0
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Sandro Bonazzola
QA Contact: meital avital
Whiteboard: storage
Depends On:
TreeView+ depends on / blocked
Reported: 2014-10-30 10:13 UTC by Elad
Modified: 2016-02-10 18:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-10-30 10:25:11 UTC
oVirt Team: Storage
Target Upstream Version:

Attachments (Terms of Use)
vdsm and setup logs (47.23 KB, application/x-gzip)
2014-10-30 10:13 UTC, Elad
no flags Details

Description Elad 2014-10-30 10:13:47 UTC
Created attachment 952050 [details]
vdsm and setup logs

Description of problem:
I tried to deploy hosted-engine using iSCSI on a LUN while has already a storage domain from an old setup on it. Deployment failed with a wrong master error. 

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

How reproducible:

Steps to Reproduce:
1. Deploy hosted engine using iSCSI using a 'dirty' LUN (a LUN which already has a storage domain located on it

Actual results:
Setup fails with the following:

[ ERROR ] Failed to execute stage 'Misc configuration': Wrong Master domain or its version: 'SD=a727ba52-c7f5-4810-8368-7f30acbe3d31, pool=00000002-0002-0002-0002-00000000015d'
[ INFO  ] Stage: Clean up
[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20141030120113.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

In vdsm.log:

Thread-22::ERROR::2014-10-30 12:01:13,593::task::866::Storage.TaskManager.Task::(_setError) Task=`29d0dc66-192f-4f87-9193-7687cb67a2e8`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 873, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 45, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 1013, in connectStoragePool
    spUUID, hostID, msdUUID, masterVersion, domainsMap)
  File "/usr/share/vdsm/storage/hsm.py", line 1084, in _connectStoragePool
    res = pool.connect(hostID, msdUUID, masterVersion)
  File "/usr/share/vdsm/storage/sp.py", line 638, in connect
    self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion)
  File "/usr/share/vdsm/storage/sp.py", line 1164, in __rebuild
    self.setMasterDomain(msdUUID, masterVersion)
  File "/usr/share/vdsm/storage/sp.py", line 1380, in setMasterDomain
    raise se.StoragePoolWrongMaster(self.spUUID, msdUUID)
StoragePoolWrongMaster: Wrong Master domain or its version: 'SD=a727ba52-c7f5-4810-8368-7f30acbe3d31, pool=00000002-0002-0002-0002-00000000015d'

Expected results:
Deployment should succeed while the LUN has a storage domain located on it. vdsm should do the remove mapping procedure like it's being done on a regular RHEVM env. while trying to use a dirty LUN to create/extand a storage domain.

Additional info: vdsm and setup logs

Comment 1 Sandro Bonazzola 2014-10-30 10:25:11 UTC
Thanks Elad for reporting, looks like the same issue Jiri had in bug #1155637.
Closing as duplicate.

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

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