Como eu saio dessa situação com segurança?
Os detalhes são os seguintes:
Um servidor xen tem dispositivos de bloco alocados para VMs. Mas esses dispositivos também foram montados dentro do Xen.
Na verdade, 44 desses dispositivos de bloco foram montados assim. Para piorar, cada dispositivo físico é visto em 4 caminhos e cada um deles é montado em um ponto de montagem separado. Em outras palavras, os dispositivos são na verdade montados 5 vezes cada um.
O sistema operacional convidado da VM vê o caminho por meio de um pseudo-dispositivo do PowerPath (alocado como um dispositivo phy: block ao domU)
Alguns dos dispositivos são formatados como ext2 e reiserfs.
Não há necessidade de me explicar os riscos de corrupção do sistema de arquivos envolvidos aqui.
Eu temo que até mesmo desmontar os sistemas de arquivos possa causar danos, e sentir que neste momento está puxando a energia do host, é a opção mais segura .
Observe que os aplicativos, principalmente bancos de dados Oracle, em todas as VMs ainda estão em execução e em uso.
Descobri isso ao investigar o alto uso da CPU no dom0. Existe um processo "find" impossível de matar, com cwd - > / media / disk-12 que é montado em / dev / sdf1, que pertence a / dev / emcpowerr
Antes que alguém pergunte, a única vez que vi processos não podem ser eliminados e continuar a usar CPU e RAM (diferentemente de um processo defunto / zumbi), quando há E / Ss pendentes confirmadas, por exemplo, sincronização retornada mas não fisicamente no disco ainda. Mais comumente isso ocorre na fita I / O.
Sugestões!
P.S. Eu teria esperado dispositivos para ser "reservado" uma vez montado, para evitar esse tipo de coisa? Ou isso não é possível no Linux?
EDIT: Em primeiro lugar, estou convencido de que o KDE dentro do hipervisor) é o culpado. Parece que o KDE está montando os dispositivos que ele pode fazer para criar ícones na área de trabalho. No entanto, o mesmo não acontece em outros servidores Xen, mas todos os outros servidores estão executando uma versão muito mais antiga do SLES e do KDE ... O V4 parece ser o mais ofensivo, com o 3.4 se comportando melhor).
Além disso, duas VMs não críticas foram suspensas. Depois de desligá-los, eles não seriam inicializados novamente devido à corrupção do sistema de arquivos. A VM principal / de produção ainda está em execução e o banco de dados continua funcionando, mas é claro que esta é uma bomba-relógio. O cliente está tentando reconstruir o ambiente em outra VM em outro servidor, mas está preso em problemas ao configurar alguns dos componentes, portanto, estamos aguardando ...
De qualquer forma, sinto que nenhuma das respostas até agora foi mais do que "a melhor prática é sempre encerrada graciosamente" E espero conseguir algo mais concreto ... De qualquer forma, sinto que essa situação pode justificar algum pensamento mais cuidadoso. O desligamento fará com que o IO excelente, em particular as atualizações de metadados do sistema de arquivos do hipervisor, sejam sincronizados e causem corrupção do sistema de arquivos potencialmente grande?
Se os discos estão sendo gravados de um único ponto de montagem, nenhum dano está sendo feito. Faça um desligamento limpo, (faça backup do estado suspenso se quiser) conserte as montagens. Não execute nada além dos aplicativos necessários no Dom0. Se, OTOH, partições estão sendo escritas a partir de vários caminhos, isso é ruim e piorar a cada segundo. Puxe o plugue.
Eu não tenho nenhuma razão concreta, mas meu sentimento me diz que o seguinte pode ser a melhor abordagem:
Alternativa para 11: Inicie a VM e monte os sistemas de arquivos sem um fsck completo.
O raciocínio é que não quero que o hipervisor Xen tenha mais nenhuma chance absolutamente necessária para causar danos nos sistemas de arquivos domU.
Eu não sou especialista em Xen e não tinha experiência com isso ainda. Mas minha abordagem se eu estivesse no seu lugar seria: primeiro eu sei que posso perder dados (talvez até todos); segundo eu tentaria criar snapshots e depois suspender as VMs, restaurando-as em um ambiente seguro e diferente.
Eu não quero lhe dar falsas esperanças, mas acho que você terá sorte se puder recuperar alguma coisa.
Aviso : seguir estes conselhos pode fazer com que perca todos dados. Isto é com você para ver se vale a pena o risco ou não.
Com muita sorte, seus aplicativos ainda estão funcionando porque os dados que eles estão usando estão todos em memória volátil. Você deve tentar aproveitar essa situação (tente avaliar se isso pode acontecer em uma base por aplicativo) e exporte os dados ativos para um compartilhamento de rede se os aplicativos oferecerem esse recurso. Se algum dado estiver no disco, essa função de exportação pode ser "bloqueada" muito parecida com a instrução find ou travar (e travar o aplicativo ou sistema operacional) por causa dos dados do disco alterados / corrompidos.
Em seguida, você pode tentar fazer um instantâneo ao vivo, as instruções no artigo a seguir: Criando instantâneos no Xen . Eu iria para o instantâneo byte-by-byte, embora pudesse ficar preso muito parecido com o seu comando find ... No entanto, eu não daria muita esperança.
Antes de fazer o comando anterior, você deve ler este documento da Citrix, que ajuda a compreendendo instantâneos em Xen (PDF) .
Desejo-lhe boa sorte.
Tags disk xen filesystems unmounting