“Encontrado PV duplicado”

6
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:~ # 

OS é um SLES 11 SP3.

Pergunta: Isso pode ser um problema? Se sim, como resolver a mensagem PV duplicada? :) Os discos estão vindo de SAN / multipath.

    
por Bratchley 26.01.2015 / 22:01

1 resposta

6

Na minha experiência pessoal, "PV duplicado" geralmente é causado pelo sistema ter acesso de multipath a um determinado SAN LUN, mas o LVM não foi configurado para filtrar os dispositivos de bloco para os caminhos individuais. O nome do mapeador de dispositivo parece até com um WWNN / WWPN (embora eu não tenha experiência suficiente com o SLES para saber se isso poderia ser outra coisa). Não tenho certeza por que um PV seria ele mesmo servido em um dispositivo DM, embora.

No RHEL eu procuraria em /dev/disk/by-path e veria se esses são os mesmos LUNs.

Could this be a problem?

Se você deveria estar em uma configuração multipath, isso poderia ser um problema. Por exemplo, se o dispositivo subjacente deve ser /dev/mapper/mpathf , mas o LVM encontrou /dev/sdf primeiro e decidiu ativá-lo, então seu acesso ao armazenamento não é tão redundante quanto você queria. Por exemplo, se o caminho /dev/sdf desce, o VG e todos os seus LVs podem ficar inacessíveis.

If yes, how to solve the duplicate PV message?

Com o LVM, cada PV tem um "cabeçalho LVM" que informa o UUID deste PV, o nome do VG em que está, e o UUID de todos os outros PVs no mesmo VG (que é como ele pode dizer se houver um PV ausente). Todo esse erro significa que ele encontrou outro PV que tinha o mesmo UUID.

Portanto, não há uma causa única para isso, por isso é difícil propor uma solução com as informações que você forneceu.

soa como seu lvm.conf só precisa do filtro configurado para ignorar os caminhos individuais (como mencionado anteriormente), mas você teria que fazer mais pesquisas para confirmar isso, já que isso é praticamente WAG (palpite selvagem).

Para um exemplo de um 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 usa /dev/sda4 para o VG raiz). Gostaria apenas de remover os dispositivos de bloco específicos que são para os caminhos individuais.

Mas, novamente, verifique. Pode ser um milhão de outras coisas também (o SAN Admin clonou um LUN e o apresentou ao seu sistema por algum motivo, improvável colisão aleatória entre UUIDs, raios cósmicos, má sorte, etc.).

ATUALIZAÇÃO:

Eu também devo mencionar que sempre que você atualizar /etc/lvm/lvm.conf (caminho RHEL) você deve reconstruir qualquer initramfs que você tenha. Parece que você está usando isso como armazenamento fora do VG raiz (que é a melhor prática), mas sempre que modificar esse arquivo, você deve certificar-se de que o kernel veja o mesmo arquivo na inicialização, como ocorre depois, para obter resultados consistentes.

    
por 26.01.2015 / 23:05