Tenho um servidor que roda o Proxmox VE 8.2 (baseado no Debian 12), totalmente atualizado, que usa SAN multipath. Lá temos um espaço alocado, dez dispositivos de 2T cada, que são vistos 16 vezes cada (o número de caminhos) e que são mapeados em 10 dispositivos virtuais multipathed e coletados em um único grupo LVM, onde um volume lógico é esculpido. Sem problemas nesta parte.
Ele foi inicializado "on the fly" e estava funcionando bem, até que o host foi reiniciado. Depois disso, notei que sempre que alguém executa qualquer comando relacionado ao LVM ( lvs
, etc.) no shell do sistema, ele emite o aviso no formato:
WARNING: Device mismatch detected for <LV> which is accessing <list of devices like
/dev/sdak, /dev/sdaz, /dev/sdbn, ...> instead of <list of the devices
like /dev/mapper/oamdwhdg-01, /dev/mapper/oamdwhdg-02, ...>
Na realidade, estes /dev/mapper/oamdwhdg-XX
são os dispositivos multipercurso, eles foram nomeados dessa forma por razões operacionais em /etc/multipath.conf
:
multipaths {
...
multipath {
wwid 36...
alias oamdwhdg-04
}
...
}
Ou seja, por qualquer motivo, o LV é mapeado usando dispositivos de backend, em vez de usar dispositivos virtuais multicaminho.
Então atualizei o filtro em /etc/lvm/lvm.conf
, que agora se parece com isto:
global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|.*|" ]
(Eu atualizei , não adicionei, estava global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]
antes com o comentário added by pve-manager to avoid scanning ZFS zvols and Ceph rbds
. Acredito que meu filtro seja muito mais rigoroso que esse.)
/dev/sda3
é o disco local onde o PVE está instalado e contém o VG pve
que não depende do SAN, então é o único /dev/sd...
que não usa multipath e foi incluído na lista de permissões.
Testei esse filtro usando vgscan
e ele mostra que ambos os grupos podem ser encontrados.
Então eu executei update-initramfs
e reiniciei. Durante a inicialização, o servidor falhou no shell de emergência . Quando eu cheguei Ctrl+D
lá, ele, no entanto, inicializou quase normalmente: o VG multipathed é visto, mas não ativado (como se vgchange -an oamdwhdg
ainda não tivesse sido executado). Mas então eu o ativei manualmente perfeitamente normalmente com o comando dito e ele funcionou perfeitamente.
Suspeito que isso seja porque o multipath não foi inicializado corretamente antes do LVM no initramfs, então ele tentou configurar mapeamentos usando dispositivos /dev/sdXX. Mas por que ele falhou no shell de emergência quando adicionei o filtro, eu não entendo.
Duas perguntas (muito relacionadas) aqui: por que o shell de emergência, também conhecido como o que está errado, e como fazê-lo funcionar conforme o esperado?
Acabou sendo um problema muito bobo. Não preciso de filtros personalizados. Eu precisava ter a inclusão multipath adequada no initramfs, o que
multipath-tools
sozinho não faz.Para isso, há um pacote separado
multipath-tools-boot
em sistemas baseados em Debian. Ele fez com que os módulos dm-multipath e a configuração de /etc aparecessem dentro do initramfs.Removi todas as alterações personalizadas
lvm.conf
e executei:Reinicie e pronto, tudo voltou ao estado correto.
Importante: após qualquer alteração na configuração do multipath ou adição de dispositivos ou qualquer outra alteração
/etc/multipath/wwids
,/etc/multipath.conf
é necessário reconstruir o initramfs para incluir versões atualizadas: