Eu tenho várias VMs Linux no VMware + SAN.
Ocorreu um problema na SAN (caminho com falha) para que, por algum tempo, houvesse erros de E / S nas unidades de VMs do Linux. Quando o failover do caminho foi feito, era tarde demais: cada máquina Linux considerava a maioria de suas unidades como não "confiáveis", configurando-as como dispositivos somente leitura . As unidades do sistema de arquivos raiz também foram afetadas.
mount -o rw,remount / sem sucesso, echo running > /sys/block/sda/device/state sem sucesso, /sys para encontrar uma solução sem sucesso. blockdev --setrw /dev/sda Eu tive que reiniciar todas as minhas VMs Linux. As VMs do Windows estavam bem ...
O problema é descrito aqui . A VMware sugere aumentar o tempo limite do scsi do Linux para evitar que esse problema aconteça.
No entanto, quando o problema ocorrer eventualmente, existe uma maneira de recuperar as unidades para o modo de leitura / gravação? (quando a SAN voltar ao normal)
Tivemos esse problema aqui algumas vezes, geralmente devido à queda da rede por um longo período. O problema não é que o sistema de arquivos é somente leitura, mas que o próprio dispositivo de disco está marcado como somente leitura. Nenhuma opção aqui além de reinicializar. Aumentar o tempo limite do scsi funcionará para falhas transitórias, como um failover de caminho. Não funciona bem com uma interrupção de rede de 15 minutos.
Do homem de mount :
errors={continue|remount-ro|panic}
Define the behavior when an error is encountered. (Either
ignore errors and just mark the filesystem erroneous and con‐
tinue, or remount the filesystem read-only, or panic and halt
the system.) The default is set in the filesystem superblock,
and can be changed using tune2fs(8).
Portanto, você deve montar sua VM com a opção continue em vez de remount-ro .
mount -o errors=continue
mount -o remount
Isso aconteceu em um sistema RHEL ao reinicializar / reconfigurar a SAN conectada. O que funcionou para mim foi desativar o grupo de volume e o LVM e reativá-lo.
vgchange -a n /vg_group_name e lvchange -a n /lvm_group_name
Então você deve reativá-los.
vgchange -a y /vg_group_name e lvchange -a y /lvm_group_name
Em seguida, tente remontar tudo com mount -a .
Após executar os casos de teste usando uma VM de teste em execução em um datastore NFS que eu desabilitei intencionalmente, não encontrei nada que funcionasse. O comando blockdev não funcionou, e os comandos vg / lv se recusam a trabalhar em um sistema root / montado.
Neste ponto, a melhor opção parece ser definir errors=panic em / etc / fstab para que a VM simplesmente falhe.