Situação horrível - sistemas de arquivos montados simultaneamente por várias instâncias independentes do SO

Como saio dessa situação com segurança?

Os detalhes são os seguintes:

Um servidor xen possui dispositivos de bloco alocados para VMs. Mas esses dispositivos também foram montados dentro do Xen.

De fato, 44 ​​desses dispositivos de bloco foram montados assim. Para piorar a situação, cada dispositivo físico é visto em quatro caminhos e cada um deles é montado em um ponto de montagem separado. Em outras palavras, os dispositivos são realmente montados 5 vezes cada.

O SO convidado da VM vê o caminho por meio de um pseudo dispositivo do PowerPath (alocado como um dispositivo phy: block para o domU)

Alguns dos dispositivos estão formatados como ext2 e reiserfs.

Não há necessidade de me explicar os riscos de corrupção do sistema de arquivos envolvidos aqui.

Receio que apenas a desmontagem dos sistemas de arquivos possa causar corrupção e sinto que , neste momento, retirar a energia do host é a opção mais segura .

Observe que os aplicativos, bancos de dados Oracle em sua maioria, 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 inquestionável de "localização", com cwd -> / media / disk-12 montado em / dev / sdf1, que pertence a / dev / emcpowerr

Antes que alguém pergunte, a única vez em que vi processos não podem ser eliminados e continuar a usar CPU e RAM (diferente de um processo extinto / zumbi) é quando há E / S confirmadas, por exemplo, sincronização retornada, mas ainda não fisicamente em disco . Mais comumente, isso ocorre na E / S da fita.

Sugestões !?

PS Eu esperava que os dispositivos fossem "reservados" depois de montados, 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 hypervisor) é o culpado. Parece que o KDE está montando os dispositivos possíveis no log para criar ícones na área de trabalho. No entanto, o mesmo não está acontecendo em outros servidores Xen, mas todos os outros servidores estão executando uma versão muito mais antiga do SLES e do KDE ... V4 parece ser o mais ofensivo, com 3,4 se comportando melhor).

Além disso, duas VMs não críticas foram suspensas. Depois de desligá-los, eles não inicializariam novamente devido à corrupção do sistema de arquivos. A VM principal / de produção ainda está em execução e o banco de dados ainda está funcionando, mas claramente essa é uma bomba-relógio. O cliente está tentando recriar o ambiente em outra VM em outro servidor, mas está preso a problemas de configuração de alguns componentes, por isso estamos aguardando ...

De qualquer forma, sinto que nenhuma das respostas até agora foi mais do que "as melhores práticas são sempre encerradas com graciosidade" E espero conseguir algo mais concreto ... De qualquer forma, sinto que essa situação pode exigir mais cuidado. pensando. O desligamento fará com que as E / S pendentes, em particular as atualizações de metadados do sistema de arquivos do hipervisor, sejam sincronizadas e causem uma corrupção potencialmente importante no sistema de arquivos?

Se os discos estiverem sendo gravados a partir de um único ponto de montagem, nenhum dano será causado. Faça um desligamento limpo (faça backup do estado suspenso, se desejar), conserte as montagens. Não execute nada além dos aplicativos necessários no Dom0. Se, OTOH, as partições estão sendo gravadas a partir de vários caminhos, isso é ruim e piora a cada segundo. Puxe o plugue.

Não tenho uma razão concreta, mas meu pressentimento me diz que o seguinte pode ser a melhor abordagem:

1. Encerre aplicativos.
2. Copie todos os dados da VM através da rede para um local de backup.
3. Desmonte os sistemas de arquivos de dentro da VM.
4. Desligue a VM. (Existe apenas uma VM em execução neste host agora).
5. Certifique-se de que nenhum domUs esteja configurado para iniciar automaticamente.
6. Retire a energia do host para impedir que o hypervisor execute ações de "fechamento", sincronização de E / S pendentes etc.
7. Inicialize a VM, esperando que o próprio hipervisor sobreviva ao arranque.
8. Se falhar, recrie o ambiente. (Os discos de inicialização das VMs são baseados em arquivo, mas os pontos de montagem de dados residem no disco externo alocado como dispositivos de bloco)
9. Verifique se o hypervisor está montando algum sistema de arquivos pertencente às domUs. Desmonte-os antes que qualquer domUs seja iniciado)
10. Desative a montagem automática do KDE.
11. Inicie a VM e force uma verificação completa do FS.

Alternativa para 11: Inicie a VM e monte os sistemas de arquivos sem um fsck completo.

O raciocínio é que eu não quero que o hipervisor Xen tenha mais chances que sejam absolutamente necessárias para causar corrupção nos sistemas de arquivos domU.

Não sou especialista em Xen e ainda não tinha experiência com ele. Mas minha abordagem se eu estivesse no seu lugar seria: primeiro eu sei que posso perder dados (talvez até todos); segundo, tentaria criar instantâneos e suspender as VMs, restaurando-as em um ambiente diferente seguro.
Não quero lhe dar falsas esperanças, mas acho que você terá sorte se conseguir recuperar alguma coisa.

Aviso : seguir esses conselhos pode fazer com que você perca todos os dados. Depende de você ver se vale a pena o risco ou não.

Com muita sorte, seus aplicativos ainda estão funcionando porque os dados que estão usando estão todos na memória volátil. Você deve tentar tirar proveito dessa situação (tentar avaliar se esse poderia ser o caso por aplicativos) e exportar os dados ativos para um compartilhamento de rede, se os aplicativos oferecerem esse recurso. Se houver dados no disco, essa função de exportação poderá ser "bloqueada", como o seufind declaração ou falha (e travar o aplicativo ou o SO) devido aos dados alterados / corrompidos do disco.

Em seguida, você pode tentar fazer uma captura instantânea ao vivo, seguindo as instruções no artigo a seguir: Criando capturas instantâneas no Xen . Eu usaria o instantâneo byte a byte, embora ele possa ficar preso muito parecido com o seufind comando ... No entanto, eu não daria tanta esperança.

Antes de executar o comando anterior, você deve ler este documento da Citrix, que ajuda a entender os snapshots no Xen (PDF) .

Te desejo boa sorte.