Bug 857325

Summary:	the LVs based on iSCSI LUN are inactive after reboot
Product:	Red Hat Enterprise Linux 7	Reporter:	Xiaowei Li <xiaoli>
Component:	lvm2	Assignee:	LVM and device-mapper development team <lvm-team>
lvm2 sub component:	Default / Unclassified	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED CURRENTRELEASE	Docs Contact:
Severity:	high
Priority:	high	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, prockai, qcai, thornber, zkabelac
Version:	7.0	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-17 05:50:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Xiaowei Li 2012-09-14 06:28:15 UTC

Description of problem:
There is no daemon ( such as multipathd for multipath ) to monitor the block device for LVM.
So We have to active the VG manually if re-connect(logout & login) the iscsi Lun.

It's hard to use LVM on iscsi due to this issues.
The LVs on iscsi LUNs are not activated after OS reboot or iscsi connection failback. 


Version-Release number of selected component (if applicable):
lvm2-2.02.97-1.el7.x86_64
kernel-3.5.0-0.24.el7.x86_64

How reproducible:


Steps to Reproduce:
1. create VG & LV on the iscsi mpath disks.
LVM->mpath->iscsi
# iscsiadm -m discovery -t st -p server
# iscsiadm -m node -p server -l
# multipath
# pvcreate /dev/mapper/mpathc
# vgcreate iscsivg /dev/mapper/mpathc
# lvcreate -l10 -n iscsivg/lv
2. reboot
  
Actual results:
after reboot, the LVs based on iscsi disks are not active.
# lvs iscsivg
  LV   VG      Attr     LSize  Pool Origin Data%  Move Log Copy%  Convert
  lv   iscsivg -wi----- 40.00m   

Expected results:
should active the LVs after reboot.

Additional info:

Comment 1 Peter Rajnoha 2012-09-14 08:36:59 UTC

(In reply to comment #0)
> Description of problem:
> There is no daemon ( such as multipathd for multipath ) to monitor the block
> device for LVM.

Actually, there is - lvmetad (the LVM metadata caching daemon). When this daemon is used, we can easily activate volumes anytime based on device appearance - the activation of LVM volumes is event-based while using lvmetad.

This daemon is relatively new and we're still working on making it more robust with the intention to make it enabled by default in 6.4/6.5 and definitely for 7.0.

See also:

  - design doc: http://git.fedorahosted.org/cgit/lvm2.git/tree/doc/lvmetad_design.txt

  - the "activation/auto_activation_volume_list" in lvm.conf: http://git.fedorahosted.org/cgit/lvm2.git/tree/doc/example.conf.in#n567

There's also related bug #474833.

Without lvmetad, we'd need extra vgchange -ay call *after* iscsi is initialized (see also https://bugzilla.redhat.com/show_bug.cgi?id=474833#c12). So I think using lvmetad is much better way to go here.

Stay tuned with the updates for the RHEL7 builds, more patches/enhancements will surely follow to support lvmetad and this event-based mechanism better.

Comment 5 Peter Rajnoha 2012-12-14 08:33:48 UTC

Could you please try using lvmetad by enabling it with global/use_lvmetad=1 lvm.conf setting and see if resolves your activation problem (but for now, cluster and lvmetad is not supported yet, so this works only for local activation at the moment).

The volumes should be autoactivated as soon as the VG is complete (it has all PVs in place). You can control which volumes to autoactivate using the activation/auto_activation_volume_list in lvm.conf.

Comment 6 Xiaowei Li 2012-12-17 05:50:29 UTC

(In reply to comment #5)
> Could you please try using lvmetad by enabling it with global/use_lvmetad=1
> lvm.conf setting and see if resolves your activation problem (but for now,
> cluster and lvmetad is not supported yet, so this works only for local
> activation at the moment).
> 
> The volumes should be autoactivated as soon as the VG is complete (it has
> all PVs in place). You can control which volumes to autoactivate using the
> activation/auto_activation_volume_list in lvm.conf.

tested with lvm2-2.02.98-4.el7.x86_64. Yes, lvmetad can resolve this issue. So close this bug.