SERVER:~ # pvs
Found duplicate PV Wb0b2UTCKtpUtSki0k2NnIB24qNj4CEP: using /dev/mapper/36005076304ffc2500000000000004903 not /dev/mapper/36005076304ffc2990000000000004903
PV VG Fmt Attr PSize PFree
/dev/mapper/36005076304ffc2500000000000004903 application lvm2 a-- 50.00g 35.00g
/dev/sda4 system lvm2 a-- 133.24g 100.39g
SERVER:~ #
El sistema operativo es un SLES 11 SP3.
Pregunta:¿Podría esto ser un problema? En caso afirmativo, ¿cómo solucionar el mensaje PV duplicado? :) Los discos provienen de SAN/multipath.
Respuesta1
En mi experiencia personal, el "PV duplicado" generalmente se debe a que el sistema tiene acceso de múltiples rutas a un SAN LUN en particular, pero LVM no se ha configurado para filtrar los dispositivos de bloqueo para las rutas individuales. El nombre del asignador del dispositivo incluso parece WWNN/WWPN (aunque no tengo suficiente experiencia con SLES para saber si eso podría ser otra cosa). Sin embargo, no estoy seguro de por qué un PV se serviría desde un dispositivo DM.
En RHEL, miraría /dev/disk/by-pathy vería si estos son los mismos LUN.
¿Podría esto ser un problema?
Si se supone que estás en una configuración de rutas múltiples, podría ser un problema. Por ejemplo, si se supone que el dispositivo subyacente es /dev/mapper/mpathfpero LVM lo encontró /dev/sdfprimero y decidió activarlo, entonces su acceso al almacenamiento no es tan redundante como se esperaba. Por ejemplo, si el camino /dev/sdfdesciende por el VG y todos sus LV podrían volverse inaccesibles.
En caso afirmativo, ¿cómo solucionar el mensaje PV duplicado?
Con LVM, cada PV tiene un "encabezado LVM" que le indica el UUID de este PV, el nombre del VG en el que se encuentra y los UUID de todos los demás PV en el mismo VG (que es como puede saber si hay un PV faltante). Todo lo que significa este error es que encontró otro PV que tenía el mismo UUID.
En realidad, no existe una única causa para esto, por lo que es difícil proponer una solución con la información que usted ha proporcionado.
Élsonidoscomo si lvm.confsolo necesita configurar su filtro para ignorar las rutas individuales (como se indicó anteriormente), pero tendría que investigar más para confirmarlo, ya que es más o menos un WAG (suposición descabellada).
Para ver un ejemplo de un filtro lvm:
filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]
El filtro anterior omite ("elimina") cualquier dispositivo que tenga las palabras "bloque" o "disco" en el nombre. También elimina cualquier dispositivo que comience con "sd" (como sdf, sdg, etc, etc) y finalmente "permite" todos los demás dispositivos (" .*").
Probablemente no quieras llegar tan lejos (ya que lo usas /dev/sda4para el VG raíz). Simplemente eliminaría los dispositivos de bloqueo específicos que son para las rutas individuales.
Pero nuevamente, verifique. También podrían ser un millón de otras cosas (el administrador de SAN clonó un LUN y lo presentó a su sistema por alguna razón, una colisión aleatoria poco probable entre UUID, rayos cósmicos, mala suerte, etc.).
ACTUALIZAR:
También debo mencionar que cada vez que actualice /etc/lvm/lvm.conf(ruta RHEL) debe reconstruir cualquier initramfs que tenga. Parece que los está utilizando como almacenamiento fuera del VG raíz (lo cual es la mejor práctica), pero cada vez que modifique ese archivo debe asegurarse de que el kernel vea el mismo archivo en el arranque que después para obtener resultados consistentes.