Olá pessoal. Isso pode parecer para alguém uma história instrutiva de como você não deve fazê-lo e por que algum trabalho técnico importante à uma da manhã (em um sistema em que você entende pouco) pode levar a um enorme colapso e tempo de inatividade por dois dias.
Uma breve nota é a história de um administrador de sistemas amador que está apenas começando a mergulhar no mundo da virtualização. A história de como os instantâneos não ajudaram, mas interferiram e fizeram uma reversão do sistema por um mês. Depois, com o tempo de inatividade em dois dias, retirei todos os arquivos de lá e devolvi o sistema.
Antecedentes
Após dois anos trabalhando em sistemas nix , e em particular no servidor ubuntu (16.04 LTS), decidi tentar a virtualização. Um amigo aconselhou o ESXi como uma solução gratuita para servidores pequenos (meu caso: 1 processador + apenas 8 GB de RAM). O processo de mudança foi complicado pelo fato de você primeiro ter que aumentar a estação de trabalho vmware com o conversor vmware no computador Windows, transferir o sistema pronto para lá, depois elevá-lo no servidor esxi e depois que o familiar conversor transferir o sistema para esxi. Esta é uma jornada tão longa e dolorosa. O principal erro durante a transferência, que eu fiz e que ainda está aparecendo em mim, é que usei um disco fino. Ou seja, estando em um servidor ubuntu limpo com um disco formatado em exfat-4, eu tinha algo em torno de 223,8 GB de espaço no ssd. Movendo-me para esxi e formatando o disco em um formato incompreensível para qualquer coisa, perdi apenas 300 MB, mas foi por causa deles que não consegui criar um disco espesso, que eu (mais tarde, acabou) precisava tanto.
Iniciar
Eu costumava quebrar a lenha com um servidor ubuntu (quando eu apenas a “estudava”), revertendo e reinstalando o sistema uma vez por mês ou dois. Agora estou quebrando lenha com o ESXi. Eu acho que não há necessidade de descrever o problema dos discos finos (em resumo, depois de expandir seu espaço, eles não o "estreitam" na direção oposta. Eles também podem ir além da quantidade física de memória no disco). Primeiramente, usei swap na mesma unidade ssd sem configurá-la corretamente no ESXi. Ele comeu memória, escreveu alguns arquivos temporários lá e, enquanto isso, a quantidade de magras cresceu.
Em segundo lugar, por algum motivo, fiz instantâneos. Naquele momento, fui guiado pelo fato de que "bem, é conveniente, rápido e tudo isso". Ainda não suspeitava que tipo de pilha e que bomba lenta eles plantaram para mim. Em terceiro lugar, não segui a quantidade de memória que diminui rapidamente no disco.
Gravata
O primeiro sino foi a parada do carro principal em 17 de julho. Uma notificação chegou no correio sobre a queda do host. Entrando no esxi para buscá-lo (bem, de repente, algo poderia acontecer), a garota virtual me deu notícias agradáveis (infelizmente não há captura de tela). A recontagem de uma janela pop-up por freeware era algo como “Desculpe, o espaço em disco acabou. Sua máquina virtual está parada. Limpe o local e você pode continuar usando a VM. Repita Cancelar. Naquele momento, o problema foi resolvido com a remoção da segunda VM, que demorava cerca de 16 GB. Mas essa era uma solução temporária, pois todos os dias, 5 GB ainda desapareciam em algum lugar, embora o sistema não tivesse um aumento nesses arquivos.
Como resultado, na noite de 19 de julho, em uma quinta-feira fria, escrevi pela primeira vez na torradeira sobre esse problema. Não houve resposta. Eu acho que isso é devido à tag esxi impopular. Depois foi o google mal sucedido, depois - a remoção de instantâneos. Naquele momento, 5 gigabytes desapareceram, o espaço livre se tornou maior, mas não o suficiente para esquecer esse problema.
Depois, com um pouco de cérebro, comecei a estudar a hierarquia dos instantâneos. O último, 000003, ocupava 12 GB de espaço naquele momento. Nas configurações da VM, ele foi listado como o arquivo de disco ativo a partir do qual a máquina foi inicializada. Sem pensar duas vezes, excluí o arquivo de disco rígido 1 com o disco de instantâneo ativo e inseri o disco pai de toda a máquina virtual em seu lugar.
O sistema inicializou (aplausos) e com ele os arquivos para 30 de junho. Data da última modificação de todos os arquivos no disco pai. Eu suspeito que foi nesse dia que criei o primeiro instantâneo. Logicamente, não havia mais lugares. No espaço livre, ele ainda tem cerca de 5 GB e os arquivos acabaram.
Os primeiros pensamentos são lógicos: o que eu fiz, todos os arquivos evaporaram até 19 de julho. Então vi que os arquivos de instantâneo não foram excluídos. No entanto, quando tentei carregá-los como disco principal, o ESXi jurou no disco pai alterado, que não deveria ser "O disco virtual pai foi modificado desde que o filho foi criado". Meu erro eterno nos próximos dois dias.
Googling
O tempo estava chegando às duas da manhã e eu abandonei todas as tentativas vãs de obter pelo menos algumas informações desses infelizes arquivos de instantâneos * -0000? - .Vmdk.
A manhã de sexta-feira começou com um google ativo, realmente ativo, como "como obter arquivos do vmdk". Artigos, leitor Linux (programa Windows) e tudo o que surgia com muita frequência. Transferi esses 223 gigabytes do servidor para o laptop Windows no canal 100Mbit, o que foi muito doloroso. Eu tentei montar um disco ssd do formato vmware em um sistema linux, enrolei as ferramentas vmware nele, ela jurou incompatibilidade de versões (a última suportada era 5, mas eu tinha 6,5). Tentativas de abrir janelas e java também eram inúteis.
E mesmo depois de acessar (usando o programa leitor do Linux no Windows) o arquivo * -flat.vmdk, recebi os arquivos somente até 30 de junho. Todas as outras tentativas de montar arquivos de captura instantânea não renderam nada, o programa foi amaldiçoado em um disco inválido e se recusou a continuar trabalhando.
Saída encontrada
Sexta-feira acabou, eu estava exausta e também chateada por os arquivos não poderem ser devolvidos. Mas o sábado começou com sucesso. Nos erros do google (o motivo pelo qual não o fiz imediatamente é desconhecido) "O disco virtual pai foi modificado desde que o filho foi criado" na primeira linha do Google deu um link para a página de vmware. Um monte de personagens assustadores, linhas vermelhas e tudo o que foi imediatamente assustado. Abri o link e o deixei na esperança de encontrar algo mais compreensível.
E foi encontrado. https://communities.vmware.com/thread/323730 O fórum do VmWare em idioma russo e um problema semelhante me encontraram na Internet. Provavelmente não é o mesmo que o meu, mas depois de rolar para baixo e ler os comentários, tentei fazer isso.
Em um editor de texto, conectando-me ao esxi via sftp, abri o arquivo com as configurações do disco pai. .vmdk (não -flat.vmdk) Reconheci o CID do disco e subi para * -00001.vmdk, conforme descrito pela pessoa com o apelido apavlyuchenko no fórum.
No primeiro instantâneo, os campos CID e parentCID devem indicar o CID do disco pai. E então no arquivo .vmx nos campos
scsi0: 1.present = "false"
scsi0: 1.fileName = " .vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"
altere o parâmetro FALSE para TRUE e .vmdk para -00001.vmdk.
E, de fato, depois disso, o carro ligou e não jurou o erro. E eis que eis! Os arquivos apareceram antes de criar um segundo instantâneo!
No fórum, um amigo descreveu uma maneira de recuperar arquivos de apenas um instantâneo. Mas meu caso é difícil (aparentemente, por causa da minha doença, chamada "cutucar tudo com as mãos em uma máquina que funciona"). E eu não tinha um instantâneo, mas três. O que é lógico, era necessário continuar alterando os arquivos.
Então, minhas ações.
Abra o disco pai. Descubra o CID dele. Em seguida, copie o CID do disco pai na linha parentCID do disco -00001.vmdk (primeiro instantâneo). Aqui, examinamos o CID desse instantâneo e o copiamos na linha parentCID da unidade -00002.vmdk (segundo instantâneo). Lá, examinamos o CID desse instantâneo e o copiamos na linha parentCID da unidade -00003.vmdk (terceiro instantâneo); depois, subimos para .vmx e indicamos o nome do arquivo de instantâneo na linha fileName (no meu caso * -0003.vmdk)
O resultado é o seguinte.
* .vmdk
CID = 387edddf
parentCID = ffffffff
* -00001.vmdk
CID = 0284jf712 (tirei todos os CIDs do negrito)
parentCID = 387edddf
* -00002.vmdk
CID = 732fhhtud
parentCID = 0284jf712
* -00003.vmdk
CID = 3747jfj4ff
parentCID = 732fhhtud
.vmx
scsi0: 1.present = "true"
scsi0: 1.fileName = " -00003.vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"
Eu ligo a VM, vejo que os dados são restaurados. Parece deixar ir. Copio tudo para outro servidor, paro a máquina (ela já está gritando sobre problemas no disco e outros problemas críticos), retorno as configurações * .vmx e copio os arquivos de volta para a máquina em funcionamento. Viva.
Conclusão
Essa história me ensinou várias verdades de ouro que antes não podiam ser entendidas.
Em primeiro lugar, faça backup de tudo sempre e em qualquer lugar e não em disco dentro da máquina virtual, como fiz antes. É necessário ter uma, ou mesmo duas unidades de backup, para que não haja um período de inatividade de dois dias. (os arquivos foram embora? Revertemos, copiamos os arquivos do backup e o mais simples - não 48 horas, mas 2 horas da força) Em segundo lugar, não faço nada com a cabeça pesada à uma da manhã (se eu fosse para a cama, viria com a cabeça limpa na sexta-feira) para outra saída, mas não quebrou a lenha na segunda hora da noite) Em terceiro lugar, não faça alterações importantes nas máquinas em funcionamento. Desça da segunda máquina virtual, faça um instantâneo lá, faça da unidade principal a principal e veja o que acontece depois disso - foi assim que foi feito. E em quarto lugar, faça ainda mais backups. Não apenas VM, mas esxi em si como um todo.
Recursos de PS que finalmente me ajudaram:
O mesmo fórum com apavlyuchenko incrível (não estamos familiarizados, se isso)
Página na base de conhecimento do vmvara com uma descrição do meu problema e maneiras de resolvê-lo
A foto que eu usei
se alguém estiver interessado, nos comentários posso deixar os recursos cujos artigos não me ajudaram
Pss
Infelizmente, o problema do desaparecimento do local ainda é relevante. Se você tem pensamentos ou deseja me ajudar a lidar com isso, comente. Podemos conversar sobre isso lá. Ou se você conhece outra maneira de recuperar arquivos de discos de instantâneos e também deseja compartilhá-los, então eu estarei interessado em lê-los. Obrigada