CentOS travando numa VMware [RESOLVIDO]

removido
(usa Nenhuma)

Enviado em 08/10/2021 - 19:19h

Pode ser isso, heim?!

https://www.linkedin.com/pulse/linux-virtual-machine-crash-vmxnet3-nic-vmware-esxi-65-han-yong-lim/

removido
(usa Nenhuma)

Enviado em 08/10/2021 - 19:21h

https://kb.vmware.com/s/article/51958

tiagopduarte26
(usa FreeBSD)

Enviado em 08/10/2021 - 19:40h

Cara, mas a forma como cheguei no erro esta correta?
E sobre aquele outro log que mandei anteriormente, o disco realmente precisa de uma análise?

Desculpa meu jeito chato, mas nunca pensei que aprenderia tanto aqui. Quero ver se começo a participar mais.
Muito obrigado mesmo por me ajudar \o

removido
(usa Nenhuma)

Enviado em 08/10/2021 - 20:10h

Vários bad blocks, né?!

Creio que você já identificou o motivo do crash, mas seria bom forçar um fsck. Seu storage não oferece recurso nativo?

removido
(usa Nenhuma)

Enviado em 08/10/2021 - 20:13h

Você mencionou que é um Storage DELL.

Veja se te atende => https://www.dell.com/community/Systems-Management-General/Virtual-Disk-bad-blocks/td-p/4416176

Obs.: Garanta um backup integro antes de qualquer ação.

tiagopduarte26
(usa FreeBSD)

Enviado em 08/10/2021 - 21:16h

PERFEITO!!! MDS É ISSO MESMO QUE ESTA ACONTECENDO.
MUITO OBRIGADO MESMO PELA FORÇA EM \o. Também vou ver aquele tópico da Dell que você passou, pois também acreditava que a Dell teria ferramenta nativa para este tipo de processo \o.
Vou incluir essa resposta como solução. Caso o problema persista eu refaço o tópico \o

tiagopduarte26
(usa FreeBSD)

Enviado em 09/10/2021 - 20:45h

Fiz os ajustes este fim de semana, e acredita que continuou travando :(. Vale lembrar que a copia de testes esta até hoje la rodando sem o Storage.

Já rodei uma verificação de discos via ambiente gráfico e ele pede pra reparar, porem sem a linha de comando ele da um erro (em anexo).
A sintase do comando seria esta?

fsck -fy /dev/sdb

F: força uma nova verificação
Y: Confirma a tentativa de correção sem perguntar

tiagopduarte26
(usa FreeBSD)

Enviado em 14/10/2021 - 08:50h

Após pesquisa sobre o erro e tendo acesso a uma consultoria para análise do Storage, foi identificado que o erro do sistema de arquivos é meio que um "bug" e parece que a única maneira é formatar e recriar o volume.
Não há problemas físicos no storage, apenas a má sorte de termos pego um caso como esses.
Gostaria de agradecer todas as contribuições, pois aprendi muito aqui e quero poder usar cada vez mais essa fonte de conhecimento.
Não sei como fecha o tópico kkk
Obrigado a todos \o

Fabio_Farias
(usa openSUSE)

Enviado em 14/10/2021 - 09:25h

Apenas como complemento o fsck é para sistemas de arquivos Ext (ext2,3 e4). O Xfs (normalmente usado nas instalações do CentOS) tem sua própria ferramenta de reparação. Veja nesse artigo.

https://www.vivaolinux.com.br/dica/Reparando-particao-XFS

tiagopduarte26
(usa FreeBSD)

Enviado em 14/10/2021 - 09:36h

Mas meu sistema é ext4.
Vale lembrar que o erro acima ocorreu ao tentar reparar pelo ambiente gráfico (não digitei nenhum comando.

Fabio_Farias
(usa openSUSE)

Enviado em 14/10/2021 - 09:43h

Nessa imagem mostra o sistema de arquivos xfs

https://www.vivaolinux.com.br/comunidades/imagens/anexos/ScreenShot030.jpg

tiagopduarte26
(usa FreeBSD)

Enviado em 14/10/2021 - 11:05h

O S.O no caso. mas a partição com problemas é o Storage (em anexo print). Agora que você mencionou, não seria uma boa prática trabalhar com 2 sistemas de arquivos diferentes né?
Como este volume esta em raid e o espaço em disco já esta pequeno, queremos colocar discos maiores.
Já que vamos ter que recriar do 0, estou pensando depois de finalizar os backups executar o fsck -fy /dev/sdb. No caso, entrar no modo de recuperação usando um disco de boot do CentOS.
Existe chance de recuperar o disco? considerando que no modo gráfico apresentou uma falha ao reparar? Não tenho certeza se os recursos que o modo gráfico utiliza são mais restritos que o terminal, por isso minha curiosidade.