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:~ #
O sistema operacional é um SLES 11 SP3.
Pergunta:Isso pode ser um problema? Se sim, como resolver a mensagem PV duplicada? :) Os discos vêm de SAN/multipath.
Responder1
Na minha experiência pessoal, "PV duplicado" geralmente é causado pelo sistema ter acesso multipath a um SAN LUN específico, mas o LVM não foi configurado para filtrar os dispositivos de bloco para os caminhos individuais. O nome do mapeador de dispositivos até se parece com WWNN/WWPN (embora eu não tenha experiência suficiente com SLES para saber se isso poderia ser outra coisa). No entanto, não sei por que um PV seria servido por um dispositivo DM.
No RHEL eu procuraria /dev/disk/by-pathe veria se esses são os mesmos LUNs.
Isso pode ser um problema?
Se você deveria estar em uma configuração multipath, isso pode ser um problema. Por exemplo, se o dispositivo subjacente deveria ser, /dev/mapper/mpathfmas o LVM foi encontrado /dev/sdfprimeiro e decidiu ativá-lo, então seu acesso ao armazenamento não é tão redundante quanto foi especificado. Por exemplo, se o caminho /dev/sdfdesce pelo VG e todos os seus LV podem ficar inacessíveis.
Se sim, como resolver a mensagem PV duplicada?
Com o LVM, cada PV tem um "cabeçalho LVM" que informa o UUID deste PV, o nome do VG em que está e os UUIDs de todos os outros PVs no mesmo VG (que é como ele pode saber se há um faltando PV). Tudo o que esse erro significa é que ele encontrou outro PV que tinha o mesmo UUID.
Portanto, não há realmente uma causa única para isso, por isso é difícil propor uma solução com as informações que você forneceu.
Istosonscomo se você lvm.confsó precisasse do filtro configurado para ignorar os caminhos individuais (como afirmado anteriormente), mas você teria que fazer mais pesquisas para confirmar isso, já que isso é praticamente um WAG (palpite maluco).
Para um exemplo de filtro lvm:
filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]
O filtro acima ignora (“remove”) qualquer dispositivo com as palavras “bloco” ou “disco” no nome. Ele também remove qualquer dispositivo que comece com "sd" (como sdf, sdg, etc, etc) e finalmente "permite" todos os outros dispositivos (" .*").
Você provavelmente não quer ir tão longe (já que você usa /dev/sda4o VG raiz). Gostaria apenas de remover os dispositivos de bloco específicos dos caminhos individuais.
Mas, novamente, verifique. Poderia ser um milhão de outras coisas também (SAN Admin clonou um LUN e apresentou-o ao seu sistema por algum motivo, colisão aleatória improvável entre UUIDs, raios cósmicos, azar, etc.).
ATUALIZAR:
Devo também mencionar que sempre que você atualizar /etc/lvm/lvm.conf(caminho RHEL), você deverá reconstruir qualquer initramfs que tiver. Parece que você os está usando como armazenamento fora do VG raiz (o que é uma prática recomendada), mas sempre que você modificar esse arquivo, certifique-se de que o kernel veja o mesmo arquivo na inicialização e depois disso, apenas para obter resultados consistentes.