[linux-lvm] Cannot create PV on /dev/dm-NN (/dev/dm-N works)
Hi, I'm unable to create PVs on Multipath-Volumes that are available at /dev/dm-NN where N~[0-9] but I can create them on single digit devices like /dev/dm-9: # pvcreate /dev/dm-6 Physical volume "/dev/dm-6" successfully created. # pvcreate /dev/dm-16 Device /dev/dm-16 not found (or ignored by filtering). My Version of LVM is 2.02.168 from Debian 9. The filter ist set to a permissive value: filter = [ "a|.*|" ] global_filter = [ "a|.*|" ] Any ideas why two or more digits in the device path can cause it to be filtered by pvcreate? Cheers, -- Michael Fladischer Fladi.at ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Cannot create PV on /dev/dm-NN (/dev/dm-N works)
Dne 27.3.2018 v 12:38 Michael Fladischer napsal(a): Hi, I'm unable to create PVs on Multipath-Volumes that are available at /dev/dm-NN where N~[0-9] but I can create them on single digit devices like /dev/dm-9: # pvcreate /dev/dm-6 Physical volume "/dev/dm-6" successfully created. # pvcreate /dev/dm-16 Device /dev/dm-16 not found (or ignored by filtering). My Version of LVM is 2.02.168 from Debian 9. The filter ist set to a permissive value: filter = [ "a|.*|" ] global_filter = [ "a|.*|" ] Any ideas why two or more digits in the device path can cause it to be filtered by pvcreate? Hi lvm2 is detecting multipath 'component' devices - those are not allowed to be used for pvcreate. You can use 'pvcreate -vvv' to get more information - there will be printed the reason why devices are rejected Eventually if you can't figure this out yourself - provide this trace in attachment. Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Cannot create PV on /dev/dm-NN (/dev/dm-N works)
I suggest you should never directly be touching the /dev/dm* devices via that name. Always touch the actual named device (/dev/mpath, /dev/vgname/lv A given dm device can be a number of other devices (lv,s, mpath, mpath components, encrypted device, md raid, and probably some others). >From just the dm* name you really don't know which kind of device it is, and there is a lot of risk of confusion and/or data loss. I have debugged situations were someone went in and partitioned all of their /dev/dm* devices and some of those devices were actually the LV's and others were they created PV's on other LV's. Without a few commands you cannot easily know what the dm* device is, so access it via the more sensibly named device. On Wed, Mar 28, 2018 at 3:27 AM, Zdenek Kabelac wrote: > Dne 27.3.2018 v 12:38 Michael Fladischer napsal(a): >> >> Hi, >> >> I'm unable to create PVs on Multipath-Volumes that are available at >> /dev/dm-NN where N~[0-9] but I can create them on single digit devices >> like /dev/dm-9: >> >> # pvcreate /dev/dm-6 >>Physical volume "/dev/dm-6" successfully created. >> >> # pvcreate /dev/dm-16 >>Device /dev/dm-16 not found (or ignored by filtering). >> >> My Version of LVM is 2.02.168 from Debian 9. >> The filter ist set to a permissive value: >>filter = [ "a|.*|" ] >>global_filter = [ "a|.*|" ] >> >> Any ideas why two or more digits in the device path can cause it to be >> filtered by pvcreate? >> > > > > Hi > > > lvm2 is detecting multipath 'component' devices - those are not allowed to > be used for pvcreate. > > You can use 'pvcreate -vvv' to get more information - there will be printed > the reason why devices are rejected > > Eventually if you can't figure this out yourself - provide this trace in > attachment. > > > Regards > > Zdenek > > > ___ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Can't work normally after attaching disk volumes originally in a VG on another machine
Zdenek Kabelac schreef op 28-03-2018 0:17: Hi This is why users do open BZ if they would like to see some enhancement. Normally cache is integral part of a volume - so it's partially missing - whole volume is considered to be garbage. But in 'writethrough' mode there could be likely possible better recovery. Of course this case needs usability without --force. So please open RFE BZ for this case. It goes into the mess I usually get myself into; if you "dd copy" the disk containing the origin volume before uncaching it, and then go to some live session where you only have the new backup copy, but you want to clean up its LVM, then you now must fix the VGs in isolation of the cache; I suppose this is just the wrong order of doing things, but as part of a backup you don't really want to uncache first, as that requires more work to get it back to normal after. So you end up in a situation where the new origin copy has a reference to the cache disk --- all of this assumes writethrough mode --- and you need to clear that reference. However, you cannot, or should not, attach the cache disk again; it might get effected, and you don't want that, you want it to remain in its pristine state. Therefore, you are now left with the task of removing the cache from the VG, because you cannot actually run vgimportclone while the cache disk is missing. The obvious solution is to *also* clone the cache disk and then run operations on the combined set, but this might not be possible. Therefore, all that was left was: vgreduce --remove-missing --force cd /etc/lvm/archive cp /etc/lvm/backup/ cd /etc/lvm/backup vi " remove cache PV, and change origin to regular linear volume, and add " the visible tag vgcfgrestore # presto, origin is restored as regular volume without the cache vgimportclone -i # now have distinct volume group, VG UUID and PV UUID So the problem is making dd backups of origin, perhaps dd backups should be avoided, but for some purposes (such as system migration) file copies are just more work in general, and can complicate things as well, for instance if there are NTFS partitions or whatnot. And disk images can be nice to have, in any case. This was the use case basically. ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Cannot create PV on /dev/dm-NN (/dev/dm-N works)
On Wed, 2018-03-28 at 10:27 +0200, Zdenek Kabelac wrote: > lvm2 is detecting multipath 'component' devices - those are not > allowed to be > used for pvcreate. > > You can use 'pvcreate -vvv' to get more information - there will be > printed > the reason why devices are rejected Thanks, I figured it out. As it happens those devices with two digits had a GPT on them. Once I erased the primary copy at the beginning of the devices, I was able to use pvcreate on them. Cheers, -- Michael Fladischer Fladi.at signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/