Bug 700372

Summary: [vdsm][iscsi]PhysDevInitializationError: Failed to initialize physical device
Product: Red Hat Enterprise Linux 6 Reporter: Evgeniy German <egerman>
Component: vdsmAssignee: Dan Kenigsberg <danken>
Status: CLOSED DUPLICATE QA Contact: yeylon <yeylon>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.1CC: abaron, bazulay, iheim, srevivo, ykaul
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-03 15:06:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
vdsm log none

Description Evgeniy German 2011-04-28 08:59:11 UTC
Created attachment 495457 [details]
vdsm log

Description of problem:
During creation of iscsi data storage domain ,the operation fails with error:
raise se.PhysDevInitializationError(device)

Version-Release number of selected component (if applicable):
RHEVM: ic-114
vdsm:  4.9-58.el6.x86_64
lvm2:   2.02.83-3.el6.x86_64

Setup:
One ISCSI Data Storage Domain
Two hosts (rhel6_u1)


How reproducible:
1)Add storage data domain via RHEVM with first host
2)Remove storage domain via RHEVM with second host
3)Repeat few times  
  
Actual results:
  File "/usr/share/vdsm/storage/task.py", line 862, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/storage/hsm.py", line 859, in public_createVG
    lvm.createVG(vgname, devices, blockSD.STORAGE_UNREADY_DOMAIN_TAG)
  File "/usr/share/vdsm/storage/lvm.py", line 736, in createVG
    _initpv(pvs[0], withmetadata=True)
  File "/usr/share/vdsm/storage/lvm.py", line 648, in _initpv
    raise se.PhysDevInitializationError(device)

Comment 7 Dan Kenigsberg 2011-04-28 22:18:09 UTC
CreateVG fails since the LUN it tries to use is already used by something else

Thread-3751::DEBUG::2011-04-28 11:46:20,728::lvm::352::Storage.Misc.excCmd::(cmd) '/usr/bin/sudo -n /sbin/lvm pvcreate --config " devices { preferred_names = [\\"^/dev/mapper/\\"] ignore_suspended_devices=1 write_cache_state=0 filter = [ \\"a%/dev/mapper/360a98000572d45366b4a6175704e3557%\\", \\"r%.*%\\" ] }  global {  locking_type=1  prioritise_write_locks=1  wait_for_locks=1 }  backup {  retain_min = 50  retain_days = 0 } " --metadatasize 128m /dev/mapper/360a98000572d45366b4a6175704e3557' (cwd None)
Thread-3751::DEBUG::2011-04-28 11:46:20,857::lvm::352::Storage.Misc.excCmd::(cmd) FAILED: <err> = "  Can't open /dev/mapper/360a98000572d45366b4a6175704e3557 exclusively.  Mounted filesystem?\n"; <rc> = 5

would you reproduce the case and research what uses that LUN (pvs, lvs, vgs)?
It seems like the LUN is taken by a former storage domain that was never formatted. Does issuing a manual `vgscan` make that vg disappear?

Comment 8 Dan Kenigsberg 2011-05-03 15:06:39 UTC

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