0

So I'm asking this question solely so I can post my own solution. I ran into a situation where my disks looked like this:

LVM
DRBD-RESOURCE
UNDERLYING-BLOCK-DEVICE

Using Drbd 9, I was running into a problem where LVM was finding the lvm signatures on the underlying block device and was causing me to have a really bad day. Filters absolutely did not work in the lvm conf. I tried the filters from the documentation as well as my own and any forum post I could find. I even limited the device type to drbd and that just made nothing work. Even if I ran pvscan, vgscan, lvmconfig. Did not matter, Did not work.

rlewkowicz
  • 1
  • 1
  • Please post your lvm.conf file, or at least the filter and global_filter directives. – shodanshok Feb 28 '17 at 16:11
  • I copy and pasted the ones from https://www.drbd.org/en/doc/users-guide-90/s-lvm-drbd-as-pv as well as just about any forum post I could find. I tried them as global, not global, both global and not global at the same time. The second I would attach that underlying block device, They would get mapped. – rlewkowicz Feb 28 '17 at 21:43

2 Answers2

1

Filters should work as advertised in the documentation found here: https://www.drbd.org/en/doc/users-guide-84/s-lvm-drbd-as-pv

For completeness, those steps are to add a filter, disable writing of LVM metadata cache, and wipe any cache that's been created.

In /etc/lvm.conf:

...
filter = [ "a|drbd.*|", "r|.*|" ]
...
write_cache_state = 0
...

Then also delete any cache:

# rm /etc/lvm/cache/.cache

With CentOS 7, in addition to the steps outlined above, you'll either need to stop and disable the lvm2-lvmetad.service, or set use_lvmetad = 0 in lvm.conf, as well. The latter requires a reboot.

Matt Kereczman
  • 1,899
  • 9
  • 12
  • Also, there are obviously many ways to configure your filters depending on your setup. If you have LVM elsewhere, you should try explicitly rejecting $UNDERLYING-BLOCK-DEVICE and accepting everything else. – Matt Kereczman Feb 28 '17 at 19:14
  • Ya know, I was running into one last issue and stopping lvm2-lvmetad.service fixed it. After promoting the failover to primary and vgscanning it didn't find anything. For me there wasn't a cache file being written too. I used that filter option too (and many others) and it just did not work. I'm sticking with my scan path cause it's working for me and I'm bumping up against deadlines. So how did you know that btw? I read as much of anything I could find and just never rolled across that. – rlewkowicz Feb 28 '17 at 21:07
  • @rlewkowicz I am a Cluster Engineer at LINBIT, the company behind DRBD. When I'm not busy with customers' clusters, I try to help out the community. I will look into patching the documentation on our end with a note for CentOS/RHEL 7 users. – Matt Kereczman Mar 01 '17 at 00:14
0

My solution was to use the resource in the scan directive in the lvm.conf under "devices":

/dev/drbd/by-res/[YOUR RESOURCE NAME]

Now obviously you couldn't use lvm with anything else, but this was ok for me and the only thing that worked.

@Matt Kereczman Pointed out:

With CentOS 7, in addition to the steps outlined above, you'll either need to stop and disable the lvm2-lvmetad.service, or set use_lvmetad = 0 in lvm.conf, as well. The latter requires a reboot.

This seems to have resolved one last issue I was facing. You may find his answer useful, I'm sticking with my scan path because it's working for me.

rlewkowicz
  • 1
  • 1