Resolver problemas de aprovisionamento de VMs com o cloud-init

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos de escala flexível

Se você criar imagens personalizadas generalizadas e usar cloud-init para provisionamento, a VM pode não ser compilada corretamente. Nesse caso, analise a imagem para identificar o problema.

Alguns exemplos de problemas com o provisionamento:

• A API do Provedor de Recursos de Computação retorna um erro e o cloud-init relata a falha resultante.
• A VM fica presa na 'criação' por 40 minutos e a criação da VM é marcada como falha.
• Os dados personalizados ou os dados do utilizador não são processados.
• O disco efémero não consegue ser montado (para configurações de VMs que incluem discos de recursos SCSI).
• Os usuários não são criados ou há problemas de acesso do usuário.
• A rede não está configurada corretamente.
• Falhas de arquivo ou partição de troca.

Este artigo orienta você sobre como solucionar problemas de inicialização na nuvem. Para obter detalhes mais detalhados, consulte Cloud-init deep dive.

Solução de problemas de falhas relatadas pelo cloud-init e registradas como erro

O Cloud-init emite erros estruturados ao relatar falhas ao Azure durante o provisionamento. Essas mensagens de erro incluem um motivo e dados de suporte (como carimbo de data/hora, identificador de VM, URL de documentação, etc.) para ajudar a investigar a falha.

Para obter ajuda com a ativação e verificação do diagnóstico de inicialização, consulte Diagnóstico de inicialização.

Se algum desses problemas persistir em tentativas subsequentes de provisionamento, é devido a uma configuração incorreta na imagem. Se houver motivos para acreditar que há um problema de inicialização na nuvem, denuncie-o ao rastreador de problemas do GitHub na nuvem.

Solução de problemas de outras falhas não relatadas pelo cloud-init

Dependendo da falha, considere estas etapas.

Etapa 1: Testar a implantação sem customData

O Cloud-init pode aceitar customData que é passado para ele, quando a VM é criada. Primeiro, você deve garantir que essa configuração não esteja causando problemas com implantações. Tente provisionar a VM sem passar por nenhuma configuração. Se a VM falhar no provisionamento, siga as etapas de solução de problemas recomendadas. Se a configuração não for aplicada, consulte a etapa 4.

Etapa 2: Revisar os requisitos de imagem

A principal causa da falha de provisionamento de VM é que a imagem do sistema operacional não satisfaz os pré-requisitos para execução no Azure. Verifique se suas imagens estão preparadas corretamente antes de tentar provisioná-las no Azure.

Os artigos a seguir ilustram as etapas para preparar várias distribuições linux com suporte no Azure:

• Distribuições baseadas em CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES e openSUSE
• Ubuntu
• Outros: Distribuições Não Aprovadas pelo Azure

Para as imagens de inicialização na nuvem do Azure com suporte, as distribuições Linux já têm todos os pacotes e configurações necessários para provisionar corretamente a imagem no Azure. Se você achar que sua VM não está conseguindo criar a partir de sua própria imagem selecionada, tente uma imagem do Azure Marketplace com suporte que já esteja configurada para inicialização na nuvem, com seu opcional customData. Se o customData funciona corretamente com uma imagem do Azure Marketplace, provavelmente há um problema com sua imagem selecionada.

Etapa 3: Coletar e revisar logs de VM

Quando a VM não consegue provisionar, o Azure mostra o status 'criando', por 20 minutos, e depois reinicializa a VM e aguarda mais 20 minutos antes de finalmente marcar a implantação da VM como falha, antes de finalmente marcá-la com um OSProvisioningTimedOut erro.

Enquanto a VM está em execução, você precisa dos logs da VM para entender por que o provisionamento falhou. Para entender por que o provisionamento de VM falhou, não pare a VM. Mantenha a VM em execução. Você precisa manter a VM com falha em um estado de execução para coletar logs. Para coletar os logs, use um dos seguintes métodos:

• Habilite o Diagnóstico de Inicialização antes de criar a VM e, em seguida, visualize-os durante a inicialização.

• Consola de Série

• Execute o AZ VM Repair para conectar e montar o disco do sistema operacional (lvm, no lvm), o que permitirá coletar e examinar esses logs:

  /rescue/var/log/waagent*
  /rescue/var/log/syslog*
  /rescue/var/log/rsyslog*
  /rescue/var/log/messages*
  /rescue/var/log/kern*
  /rescue/var/log/dmesg*
  /rescue/var/log/boot*
  /rescue/ /var/log/cloud-init.log
  /rescue//var/log/cloud-init-output.log
  

> [!NOTE]
> Alternatively, you can create a rescue VM manually by using the Azure portal. For more information, see [Troubleshoot a Linux VM by attaching the OS disk to a recovery VM using the Azure portal](/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-linux).
To start initial troubleshooting, begin with the serial logs and cloud-init logs to understand where the failure occurred. Then use the other logs for a  deeper dive to help provide additional insights.

* /var/log/cloud-init.log
* /var/log/cloud-init-output.log
* [Serial/boot logs](/azure/virtual-machines/boot-diagnostics#boot-diagnostics-view)

In all logs, start searching for "Failed," "WARNING," "WARN," "err," "error," and "ERROR." Setting configuration to ignore case-sensitive searches is recommended.

Alternatively, use command `cloud‑init collect‑logs` to collect all necessary logs.
Azure’s latest cloud-init versions (≥ 18.2) include the collect‑logs command, which:

Gathers essential logs: /var/log/cloud-init*.log, instance metadata, system info.

Packages everything into a timestamped .tar.gz archive.

Saves the archive locally (for example, `/tmp/cloud-init-logs-timestamp.tar.gz`).

> [!TIP]
> If you're troubleshooting a custom image, you should consider adding a user during the image. If the provisioning fails to set the admin user, you can still log in to the OS.

#### Analyzing the logs

Here are more details about what to look for in each cloud-init log.

#### /var/log/cloud-init.log

By default, all cloud-init events with a priority of debug or higher, are written to `/var/log/cloud-init.log`. This log provides verbose logs of every event that occurred during cloud-init initialization.

For example:

```console
2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

Quando encontrar um erro ou aviso, leia o registo do cloud-init de trás para frente para compreender o que o cloud-init estava a tentar fazer antes de encontrar o erro ou aviso. Em muitos casos, o cloud-init executa comandos do sistema operacional ou executa etapas de provisionamento antes que o erro ocorra. Essas ações podem ajudar a explicar por que o erro aparece nos logs. O exemplo a seguir mostra que o cloud-init tentou montar um dispositivo antes de encontrar o problema.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Se você tiver acesso ao Console serial, poderá tentar executar novamente o comando que cloud-init estava tentando executar.

O registro em log também /var/log/cloud-init.log pode ser reconfigurado em /etc/cloud/cloud.cfg.d/05_logging.cfg. Para obter mais informações sobre os registos do cloud-init, consulte a documentação do cloud-init.

/var/log/cloud-init-output.log

Você pode obter informações do stdout e durante os stderr. Esses dados normalmente envolvem informações de tabela de roteamento, informações de rede, informações stdout, de verificação de chave de host ssh e stderr para cada estágio de cloud-init, juntamente com os carimbos de data/hora. Se desejado, stderr e stdout o registro em log pode ser reconfigurado a partir de /etc/cloud/cloud.cfg.d/05_logging.cfg.

Registos de série/arranque

O Cloud-init tem várias dependências. Essas dependências são documentadas nos pré-requisitos necessários para imagens no Azure, como rede, armazenamento, a capacidade de montar um ISO e montar e formatar o disco temporário. Qualquer uma dessas dependências pode gerar erros e fazer com que o cloud-init falhe. Por exemplo, se a VM não puder obter uma concessão DHCP, o cloud-init falhará.

Se você ainda não consegue isolar por que o cloud-init falhou no provisionamento, então você precisa entender quais estágios do cloud-init e quando os módulos são executados. Para obter mais informações, consulte Mergulhando mais fundo na nuvem-init.

Etapa 4: Investigar por que a configuração não está sendo aplicada

Nem toda falha no cloud-init resulta em uma falha fatal de provisionamento. Por exemplo, se se utilizar o módulo runcmd numa configuração do cloud-init, um código de saída não zero do comando causará a falha no provisionamento da VM. Esse comportamento ocorre porque o módulo é executado após as etapas de provisionamento principal nos três primeiros estágios do cloud-init. Para solucionar problemas por que a configuração não foi aplicada, revise os logs na Etapa 3 e os módulos de inicialização na nuvem manualmente. Por exemplo:

• runcmd - os scripts são executados sem erros? Para garantir que eles sejam executados conforme o esperado, execute a configuração manualmente a partir do terminal.
• Instalando pacotes - a VM tem acesso aos repositórios de pacotes?
• Verifique a customData configuração que foi fornecida à VM. Este arquivo está localizado em /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Próximos passos

Caso o cloud-init ignore a configuração, examine cada estágio do cloud-init e a temporização da execução do módulo para identificar a causa. Para obter mais informações, consulte Aprofundando a configuração de inicialização na nuvem.