migração AWS t1 para t2: Client.InstanceInitiatedShutdown na nova instância t2

Question

Eu tive um Linux t1.micro executando um pequeno site Apache / PHP / Postgresql por um par de anos agora (aqui referido como "instância original"). Funciona como um encanto.

Eu queria migrar o site para a nova (mais barata) instância t2.micro. Não consegui encontrar instruções passo a passo sobre como fazer isso, mas tomei nota de isto e isto .

Minha abordagem básica foi

1. Criar instantâneos dos dois volumes (raiz e uma unidade de dados para os dados do postgresql) usados pela instância original
2. Crie uma nova AMI do HVM a partir dos snapshots de raiz e de dados que acabou de ser tirada (ELASTIC BLOCK STORE > Snapshots > selecione o snaphot de raiz da instância original > Ações > Criar imagem), com
   • Architecture = x86_64, igual à instância original
   • Dispositivos raiz e nomes de dispositivos de volume de dados = igual à instância original
   • Tipo de virtualização = Virtualização assistida por hardware (HVM, para compatibilidade com o novo formato t2 VM)
   • ID do kernel="Usar padrão" (tentei usar o mesmo ID de kernel da instância original, mas a criação de AMI falhou dizendo que não era possível usar isso para uma AMI de HVM)
3. Crie e inicie uma nova instância com a AMI recém criada na etapa 2

Problema: ao iniciar essa nova instância, ela é encerrada imediatamente com um erro Client.InstanceInitiatedShutdown . Como posso resolver isso?

É ingênuo pensar que posso usar um instantâneo raiz que funcione em um ambiente PVM em um ambiente HVM? Existe uma maneira mais fácil de migrar de t1 para t2?

Espero não ter que reconstruir meu servidor em t2 a partir do zero e migrar dados manualmente (não usei nenhum script de construção automatizado).

Editar : acabei reconstruindo a instância t2 do zero: P

    

Answer 1

Eu estava indo do HVM para o PV e percebendo o mesmo problema. Descobri que eu (minha automação) ainda estava anexando armazenamento de bloco a / dev / sda1, o que eu precisava para minha AMI de HVM, mas precisava anexá-lo a / dev / xvda.