(Esta resposta correta é aquela que tem pouca semelhança de superfície com esta. Fazendo a pergunta e respondendo-a com referência a essa).
Considere um ambiente de host virtual no qual uma VM recebeu 3 unidades virtio separadas, aparecendo como 3 dispositivos de bloco separados e atribuída a 3 VGs separados (grupos de volumes).
/dev/vda - vgroot /dev/vdb - vgdata /dev/vdc - vgvar Enquanto a VM está on-line, /dev/vdb desaparece. Isso pode ter ocorrido porque a VM foi movida para um novo hipervisor, mas esse volume em particular ficou preso, ou talvez o administrador do sistema insano tenha removido o volume e o tenha colocado temporariamente em outro host. No meu caso, eu estava com sorte.
Quando o volume retorna, o Kernel Linux (não todos, na verdade; mas pelo menos desde RHEL6) o atribui não à letra de unidade original, porque esse disco é tecnicamente visto como 'aberto', mas para um novo dispositivo de bloco : /dev/vdd .
Depois, todos os comandos do LVM, como vgs , report:
/dev/data/db: read failed after 0 of 4096 at 10733158400: Input/output error
/dev/data/db: read failed after 0 of 4096 at 10733215744: Input/output error
/dev/data/db: read failed after 0 of 4096 at 0: Input/output error
/dev/data/db: read failed after 0 of 4096 at 4096: Input/output error
No entanto, pvscan e vgscan detectam os volumes originais, mas ainda estão tentando ler o dispositivo de bloco antigo. Re-montagem não funciona. E, por uma questão de argumento, a reinicialização é inaceitável. O que fazer?
Esta questão foi respondida em uma discussão relacionada sobre iscsi disks aqui . Como não estou trabalhando com o scsi, mas com virtio , as pesquisas do Google não ajudaram a encontrar minha resposta. Se você encontrar esta resposta, certifique-se de que vota a resposta de Guiseppe. Em suma, é:
vgscan ; vgchange <vgname> --refresh
Tags lvm linux device-mapper virtio