Migrar uma VM do Server 2008 R2 do atlantic.net para a AWS

Você deve usar o AWS Application Migration Service . Sim, você usa algo chamado "serviço de migração de aplicativos" para migrar servidores, imagine. Depois de entrar nessa área do console, ele o guiará pelo processo, mas você basicamente instala um agente em seu servidor de origem, ele replica na AWS, você interrompe o servidor antigo e inicia o novo servidor.

Se o seu sistema operacional for muito antigo e não tiver suporte da AWS, você deverá copiar seus dados e reinstalar seus aplicativos, em vez de fazer soluções alternativas sem suporte.

Eu realmente fui capaz de fazer isso e me sinto extremamente realizado agora.

Uma coisa que a maioria das pessoas não percebe é como é fácil mover o Windows de um hardware para outro. A abordagem é simplesmente fazer uma cópia bruta do disco, conectá-lo à nova máquina e inicializar.

Para aqueles que pensam que configurar um sistema Windows do zero é mais fácil, não é, especialmente se você depende de um software com mais de 10 anos e não tem os discos de instalação: é definitivamente mais fácil apenas trocar um disco do sistema por um novo hardware!

Com a migração para a AWS, é um pouco mais complicado sem um console. Mas isto pode ser feito.

Visão geral

1. Instale os drivers da AWS na máquina antiga que não é da AWS e ative o log de inicialização.
2. Obtenha o cygwin se você ainda não o fez, isso é ter o dd que pode acessar o disco bruto, gzip e ssh também foram usados.
3. Reduza o volume do sistema (unidade C:) o máximo que puder.
4. Se você tiver espaço suficiente no disco após a redução, crie uma partição do sistema de arquivos no outro disco ou prepare-se para clonar a partição bruta do sistema na nova, se puder desligar o sistema e ter acesso ao disco, ainda mais fácil. Mas na nuvem atlântica você não pode fazer isso.
5. Faça uma cópia dd bruta do disco do sistema para o outro espaço, desde o início do disco até logo após a partição do sistema e os últimos blocos do disco físico, escrever a cópia grande através do gzip economiza 40% de espaço , isso é útil para a próxima etapa.
6. Copie esses dois arquivos de dados brutos para algum espaço temporário idealmente conectado a um servidor UNIX (FreeBSD, Linux, qualquer que seja) na AWS. Eu usei scp ou um pipe através do ssh. Esta é a etapa mais demorada, levei 10 horas a uma velocidade de transferência de 1,6 MB/s. É por isso que é tão importante reduzir o volume do sistema.
7. Pegue um disco AWS EC2 EBS do tamanho do original (no meu caso 160 GB e acabou sendo exatamente o mesmo número de blocos que o meu original, muito bom.)
8. Anexe esse novo disco ao sistema UNIX em execução.
9. Agora zcat | dd o arquivo de dados brutos principal para esse novo disco e grave esses últimos blocos também.
10. Desanexe esse novo disco do sistema UNIX.
11. Inicie uma instância do Windows do EC2, inicie e conecte-se. Eu usei t2.micro (nível gratuito) que é a arquitetura de trabalho (t3.micro não funcionou).
12. Anexe esse novo disco ao novo sistema Windows.
13. Na ferramenta de particionamento, você pode ver o novo disco como "Offline", clique com o botão direito do mouse e coloque Online
14. Você pode ver essa partição sobressalente no espaço reduzido, esse conteúdo não foi copiado, apenas exclua essa partição. No clone do disco do sistema, clique em Propriedades e faça um Scan/check do sistema de arquivos (que foi desligado sujo na clonagem).
15. Faça um desligamento limpo do sistema Windows
16. No console do EC2, quando o sistema for interrompido, desconecte os dois discos e anexe o disco clonado como /dev/sda1 (disco de inicialização).
17. Agora inicie a instância.
18. Assim que passar do status Pendente para Iniciado, obtenha a captura de tela da instância, você a verá agitando e, esperançosamente, não fique preso, mas mostre a tela "Pressione ALT + CTL + DEL". Assim, o sistema inicializou.
19. Se você ainda não conseguir acessar o sistema com a Área de Trabalho Remota, aguarde um pouco e, em seguida, no console do EC2, emita uma instância de parada normal. Não há necessidade de ser impaciente e forçar a parada. Apenas espere um minuto e ele deve parar. Em seguida, reinicie novamente.
20. Agora, quando a captura de tela da instância for para a tela "Pressione ALT + CTL + DEL", tente a Área de Trabalho Remota novamente, agora deve funcionar.

Detalhes

Para o ponto 1. Instalar drivers da AWS na máquina antiga, não AWS, não é trivial. No meu caso eu tinha um servidor Windows 2008 super antigo que nem rodava os scripts install.ps1 que vem com grande parte dos drivers da AWS.

Este documento aqui: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html foi o melhor guia sobre o que fazer.

1. Instalar drivers PV da AWS
2. Instalar o driver AWS ENA
3. Instalar drivers AWS NVMe
4. Instale o EC2Config e o EC2Launch

O driver PV era difícil, porque a versão mais recente informa que não suporta seu sistema antigo. Mas depois de algumas pesquisas descobri que a última versão suportada é 8.3.4, e então descobri que o URL para isso é: https://s3.amazonaws.com/ec2-windows-drivers-downloads/AWSPV/8.3 .4/AWSPVDriver.zip . Uma vez encontrado, o instalador .msi incluído funcionou sem problemas.

Os outros drivers funcionaram na versão mais recente. Mas executar os scripts install.ps1 para o driver ENA foi bastante fácil. Para os drivers NVMe foi difícil. Acabei lendo o roteiro com meus próprios olhos, interpretando o que ele faz e fazendo manualmente.

As instalações do EC2Config e EC2Launch foram diretas.

Agora a reinicialização do sistema, mesmo na plataforma antiga, já surgiu mostrando o background da AWS com o painel de informações do sistema AWS no canto superior direito. Não mostrando muito, mas diz que essa coisa do EC2Launch fez sua mágica.

Sobre cópias dd.

No cygwin as unidades de disco são /dev/sda, sdb, sdc, ... Você precisa dessa unidade bruta, não das partições. Primeiro você precisa obter os tamanhos exatos das partições que deseja copiar:

$ wmic partition get name,bootable,size,type
Bootable  Name                   Size          Type
TRUE      Disk #0, Partition #0  104857600     Installable File System
FALSE     Disk #0, Partition #1  104805171712  Installable File System
FALSE     Disk #0, Partition #2  66884468736   Installable File System

Esses tamanhos estão em bytes. Você adiciona a partição de inicialização e do sistema, 104857600 + 104805171712 = 104910029312 bytes. Para acelerar o dd, você quer ler em blocos maiores, digamos 10 MiB (bs = 10M). Nesse caso, você precisa dividir por 1024 duas vezes e 104910029312/1024/1024/10 = 10005.00004882.. e depois arredondar para cima:

dd if=/dev/sda bs=10M count=10006 status=progress |gzip -cv > /cygdrive/d/diskimage.gz

no final do disco, basta somar todas as partições 66884468736 + 104805171712 + 104857600 = 171794498048 bytes / 1024 = 167768064 kiB blocks:

dd if=/dev/sda bs=1024 skip=167768064 of=/dev/null status=progress
4096+0 records in
4096+0 records out
4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.057467 s, 73.0 MB/s

4 kiB é um bom tamanho pequeno. Se isso fosse muito grande, você saberia o tamanho exato do seu disco e então pegaria os últimos 4 kiB.

$ dd if=/dev/sda bs=1024 skip=167768064 of=diskimage.end status=progress
4096+0 records in
4096+0 records out
4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.0673959 s, 62.2 MB/s

Quando essas cópias forem feitas, mova o material para a AWS, em uma máquina UNIX com o novo volume EBS anexado, verifique cuidadosamente onde ele está, para não limpar seus outros discos por engano. No meu caso:

zcat diskimage.gz |dd of=/dev/nvd4 bs=10M status=progress
  104847114240 bytes (105 GB, 98 GiB) transferred 1550.052s, 68 MB/s
0+1600960 records in
10006+0 records out
104920514560 bytes transferred in 1551.084986 secs (67643305 bytes/sec)

e o fim:

dd if=diskimage.end of=/dev/nvd4 bs=1024 seek=167768064  status=progress
  2983936 bytes (2984 kB, 2914 KiB) transferred 2.002s, 1491 kB/s
4096+0 records in
4096+0 records out
4194304 bytes transferred in 2.836086 secs (1478906 bytes/sec)

Agora você está pronto para arrancar!

Quando não consegui me conectar a ele, foi porque a rede não estava sendo configurada corretamente.

2022/03/14 17:45:53Z: Windows sysprep configuration complete.
2022/03/14 17:46:03Z: Failed to find primary network interface...retrying...
2022/03/14 17:46:13Z: Failed to find primary network interface...retrying...
2022/03/14 17:46:24Z: Failed to find primary network interface...retrying...

Com o log de inicialização ativado e observando alguns logs de configuração relacionados à AWS em C:\Windows (E:\Windows ao anexar o disco a um sistema Windows em execução) classificar a visualização do diretório por hora do arquivo decrescente, pude ver que os drivers xen estavam instalado, mas o xenbus não foi encontrado e o xennet não foi instalado. Mas na segunda inicialização notei de repente que o xennet estava instalado agora. E todos os problemas desapareceram.

Parece que você está fazendo um peg quadrado/furo redondo tentando fazer isso funcionar com o Windows na AWS. Dito isso, tenho duas ideias para você.

1. Você tentou este procedimento para obter acesso ao console de inicialização? Você apenas diz "não funcionou" sem dizer o que tentou.

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/troubleshooting-sac.html

2. Você também pode executar isso na virtualização aninhada. Crie uma nova instância do EC2 executando uma versão moderna do Windows, execute HyperV ou VMware e tente inicializar sua imagem de disco. Você pelo menos poderá obter acesso ao console e montar mídia de instalação adicional, se precisar.

/Edit - você declarou várias partes do processo na descrição do problema, mas não em detalhes. Como você pré-instalou os drivers? Você usou os pacotes daqui?

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html