Bug 1000894

Created attachment 790262 [details]
File: backtrace

Created attachment 790263 [details]
File: cgroup

Created attachment 790264 [details]
File: core_backtrace

Created attachment 790265 [details]
File: dso_list

Created attachment 790266 [details]
File: environ

Created attachment 790267 [details]
File: exploitable

Created attachment 790268 [details]
File: limits

Created attachment 790269 [details]
File: maps

Created attachment 790270 [details]
File: open_fds

Created attachment 790271 [details]
File: proc_pid_status

Created attachment 790272 [details]
File: var_log_messages

Log in to iSCSI target.  LUNs on target contain VM disks, which use LVM.

reporter:       libreport-2.1.6
backtrace_rating: 4
cmdline:        /usr/sbin/lvmetad
crash_function: dm_malloc_aux
executable:     /usr/sbin/lvmetad
kernel:         3.10.9-200.fc19.x86_64
package:        lvm2-2.02.98-12.fc19
reason:         Process /usr/sbin/lvmetad was killed by signal 11 (SIGSEGV)
runlevel:       N 5
uid:            0

(In reply to Ian Pilcher from comment #12)
> Log in to iSCSI target.  LUNs on target contain VM disks, which use LVM.
> 

Please, post the output of lvmdump -l (this will include lvmetad dump so we'll see what's cached in lvmetad daemon).

If I understand correctly, your setup is:
   on host side: iSCSI connected LUN -> LVM (then the LVs used as VM disk)
   on guest side: LVM

If that is true, please, consider using devices/global_filter to completely filter out the guest side LVM volumes so they don't interfere with host side LVM.
Anyway, even without filtering, it should not segfault, of course. That "lvmdump -l" should help us a bit - please, attach it to this report. Thanks.

Created attachment 797372 [details]
Output of lvmdump -l

(In reply to Peter Rajnoha from comment #13)
> Please, post the output of lvmdump -l (this will include lvmetad dump so
> we'll see what's cached in lvmetad daemon).

Done.

> If I understand correctly, your setup is:
>    on host side: iSCSI connected LUN -> LVM (then the LVs used as VM disk)
>    on guest side: LVM

That is correct.

> If that is true, please, consider using devices/global_filter to completely
> filter out the guest side LVM volumes so they don't interfere with host side
> LVM.

That was actually my first thought.  Unfortunately, I can't come up with a filter with will ignore /dev/sdc (for example) when it's an iSCSI LUN but still use it when it's a USB drive.  (Yes, I've been known to use LVM on external drives.)

(In reply to Ian Pilcher from comment #14)
> Created attachment 797372 [details]
> Output of lvmdump -l
> 
> (In reply to Peter Rajnoha from comment #13)
> > Please, post the output of lvmdump -l (this will include lvmetad dump so
> > we'll see what's cached in lvmetad daemon).
> 
> Done.

Thanks, I'll have a look...

> 
> > If that is true, please, consider using devices/global_filter to completely
> > filter out the guest side LVM volumes so they don't interfere with host side
> > LVM.
> 
> That was actually my first thought.  Unfortunately, I can't come up with a
> filter with will ignore /dev/sdc (for example) when it's an iSCSI LUN but
> still use it when it's a USB drive.  (Yes, I've been known to use LVM on
> external drives.)

The best is to accept only known PVs and reject any other - maybe try to use a match against /dev/disk/by-* entries - these include some constant name schemes or IDs that do not change upon reboot/connection (e.g. vendor, model names or WWN in case of iSCSI).

If you're using lvmetad (global/use_lvmetad=1 in lvm.conf), be sure to use devices/global_filter instead of devices/filter setting.

Upstream fix in b5aad86710be57833879ac0e8609021828949682.

*** Bug 1003278 has been marked as a duplicate of this bug. ***

(In reply to Petr Rockai from comment #16)
> Upstream fix in b5aad86710be57833879ac0e8609021828949682.

Any chance of a build with this fix included?

(In reply to Ian Pilcher from comment #18)
> (In reply to Petr Rockai from comment #16)
> > Upstream fix in b5aad86710be57833879ac0e8609021828949682.
> 
> Any chance of a build with this fix included?

There are more patches queued for F19. I'd need to find some time to backport them, but I hope this Friday or during next week definitely.

*** Bug 997656 has been marked as a duplicate of this bug. ***

lvm2-2.02.98-13.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lvm2-2.02.98-13.fc19

Package lvm2-2.02.98-13.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-13.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20436/lvm2-2.02.98-13.fc19
then log in and leave karma (feedback).

lvm2-2.02.98-13.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.