Hello Ritesh.
Thanks for your answer.
Tried serveral things to make it work, but only a filter in lvm.conf did work.
(the pv's were created under multipath, and also did several vgcfgbackup, the
pv's did not have any /dev/sd?? written in their sectors)
The filter that I put is:
filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", "r|/sd[b-z].*|",
"a|.*|" ]
I had to put sd[b-z].* because the system in installed in lvm too, so I had to
exclude that device. Maybe there is a better filter, but I do not know how to
write it.
The server uses a RAID controller for internal disks and hba for the external
disks
Right now, it seems stable between reboots, I hope that the raid controller
will always setup before the hba, otherwise the filter won't work.
I think that this info can be of help to other users, could you put a
README.debian including this filter? (or modify the lvm.conf to add the note)
Like:
To setup LVM over multipath, and allow other LVM over a non multpathed device,
if you encounter that the pv-devices are not under
multipath control, try this filter line in lvm.conf, update-initrd and reboot.
to check it that it works ok.
filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|",
"r|/sd[b-z].*|", "a|.*|" ]
sd[b-z].* makes all /dev/sd* be skipped but /dev/sda.
Adjust for your hardware configuration.
With this info the bug can be closed.
Regards.
--
Carlos Barros.
On mié, 2021-12-15 at 20:00 +0530, Ritesh Raj Sarraf wrote:
Hello Carlos,
On Tue, 2021-12-14 at 19:04 +0100, Carlos Barros wrote:
A server was setup with some disks configured in multipath.
The root filesystem is on LVM on internal disk, not configured for
multipath.
Then build another lvm configuration on those devices
(/dev/mapper/...)
Now, every time it starts, lvm takes the /dev/sd.. before multipath
sets /dev/mapper/... up.
This combination of the setup, where you have Multipath + LVM, is a
known working config.
There are some special tweaks needed though. I don't recollect the
exact specifics but basically there might be 2 things.
1. You need to ensure that you run pvcreate on top of the multipathed
devices and NOT on the bare SCSI devices.
2. THere's also a filter in /etc/lvm/ where you define the list of SCSI
devices that should be blacklisted from LVM.
Also, the booting proccess delays for 2+ minutes, mostly because of
systemd-udev-settle.service:
root@panblando:~# systemd-analyze blame
2min 22ms systemd-udev-settle.service
1min 105ms NetworkManager-wait-online.service
9.983s smartmontools.service
4.415s dev-mapper-dl380g8\x2d\x2dvg\x2droot.device
But this service is called from multipath:
[Unit]
Description=Device-Mapper Multipath Device Controller
Wants=systemd-udev-trigger.service systemd-udev-
settle.service
Before=iscsi.service iscsid.service lvm2-activation-
early.service
Before=local-fs-pre.target blk-availability.service
After=multipathd.socket systemd-udev-trigger.service systemd-
udev-settle.service
DefaultDependencies=no
Conflicts=shutdown.target
ConditionKernelCommandLine=!nompath
ConditionKernelCommandLine=!multipath=off
According to systemd-udev-settle.service(8) it is not recommended, as
that service can fail (in fact,
in the server it fails as systemd says)
I don't recollect the specifics but iirc that service is required for a
reason. Remember that, typically, multipath-tools is used in
combination with SAN devices which are remote.
I think that the problem is related to multipath, because it did not
setup the devices before lvm,
and maybe the problem is inside the initrd.
Please explore the suggestions I mentioned above. I am fairly sure that
it may just be a case of proper blacklisting.
Then I did install multipath-tools-boot but the problem is the same.
The only way is to avoid mounting the filesystems in the LVM (or
umounting them) vgchange -an VG
and do the multipath and mount it, all by hand
Yes. THis is expected behavior. mutliapth can only acquire the device
when it is free.
INFORMACIÓN BÁSICA SOBRE PROTECCIÓN DE DATOS CONFORME EL NUEVO REGLAMENTO
EUROPEO (RGPD)
RESPONSABLE: Grupo Econocom en España (Econocom SA, Econocom Servicios S.A.,
Econocom Products & Solutions S.A.U.) sitas en Cardenal Marcelo Spínola, 4,
28016 Madrid
FINALIDAD PRINCIPAL: Mantener relaciones profesionales y/o comerciales con la
empresa en la que usted trabaja o de la que es representante.
LEGITIMACIÓN: Consentimiento del interesado.
DESTINATARIOS: No se cederán datos a terceros, salvo autorización expresa u
obligación legal.
DERECHOS: Acceder, rectificar y suprimir los datos, portabilidad de los datos,
limitación u oposición a su tratamiento, transparencia y derecho a no ser
objeto de decisiones automatizadas.
INFORMACIÓN ADICIONAL: Puede consultar la información adicional y detallada
sobre nuestra política de
privacidad<https://www.econocom.es/aviso-legal-politica-de-privacidad-y-proteccion-de-datos#overlay-context=aviso-legal>
DELEGADO DE PROTECCIÓN DE DATOS (DPD): Miguel Angel Muñoz +34 93 470 30 00
dpo_econocom...@econocom.com<mailto:dpo_econocom...@econocom.com>
CONFIDENCIALIDAD: Si Ud. no es el destinatario y recibe este mail por error,
rogamos se ponga en contacto con nosotros y borre de inmediato el mail por
error recibido con todos sus documentos adjuntos sin leerlos ni hacer ningún
uso de los datos que en ellos figuren, ateniéndose a las consecuencias que de
un uso indebido de dichos datos puedan derivarse.
BASIC INFORMATION ON DATA PROTECTION ACCORDING TO THE NEW EUROPEAN REGULATION
(GDPR)
CONTROLLER: Grupo Econocom in Spain. (Econocom SA, Econocom Servicios S.A.,
Econocom Products & Solutions S.A.U.) registered at Cardenal Marcelo Spínola,
4, 28016 Madrid
PURPOSE: Maintain professional and / or commercial relationship with the
company which you represent or work for
LEGITIMATION: Data subject consent.
RECIPIENTS: data will not be transferred to third parties, unless explicit
consent or legal obligation.
RIGHTS: Right to Access, right to rectification and erasure, data portability,
right to restriction of processing, right to object and not been subject to a
decision based solely on automated processing, and to be informed in a clearly
and transparent way of how their personal data are processing.
ADDITIONAL INFORMATION: you can consult the additional and detailed information
about our privacy
policy<https://www.econocom.es/aviso-legal-politica-de-privacidad-y-proteccion-de-datos#overlay-context=aviso-legal>
DATA PROTECTION OFFICER (DPO): Miguel Angel Muñoz +34 93 470 30 00
dpo_econocom...@econocom.com<mailto:dpo_econocom...@econocom.com>
CONFIDENTIALITY: If you received this email in error, please immediately
contact us and destroy the material in its entirety, whether in electronic or
hard copy format. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited, on
his/her own responsibility.
