Solução de problemas de provisionamento de VM com cloud-init

Aplica-se a: ✔️ VMs do Linux ✔️ Conjuntos de dimensionamento flexíveis

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

Alguns exemplos de problemas com o provisionamento:

• A API do Provedor de Recursos de Computação retorna um erro e a 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.
• Dados personalizados ou dados do usuário não são processados.
• O disco efêmero falha ao montar (para skus de VM que vêm com discos de recurso SCSI).
• Os usuários não são criados ou há problemas de acesso dos usuários.
• A rede não está configurada corretamente.
• Falhas de arquivo de permuta ou de partição.

Este artigo orienta você sobre como solucionar problemas de cloud-init. Para obter mais detalhes, confira Detalhamento de cloud-ini.

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

Cloud-init emite erros estruturados ao reportar falhas para o 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 habilitação e a verificação do diagnóstico de inicialização, consulte o Diagnóstico de Inicialização.

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

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

Dependendo da falha, considere essas 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 não for provisionada, siga as etapas de solução de problemas recomendadas. Se a configuração não for aplicada, consulte a etapa 4.

Etapa 2: Examinar os requisitos de imagem

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

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

• Distribuições com base em CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES e openSUSE
• Ubuntu
• Outros: As distribuições não endossadas

Para as imagens do cloud-init do Azure com suporte, as distribuições do 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 organizada, experimente uma imagem do Azure Marketplace com suporte que já esteja configurada para cloud-init, com o customData opcional. Se o customData funcionar corretamente com uma imagem do Azure Marketplace, provavelmente haverá um problema com sua imagem coletada.

Etapa 3: Coletar e examinar os logs da VM

Quando a VM não for provisionada, o Azure mostrará o status de "criação" por 20 minutos. Em seguida, reiniciará a VM e aguardará mais 20 minutos antes de marcar a implantação como de falha, associando-a a um erro OSProvisioningTimedOut.

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 interrompa a VM. Mantenha a VM em execução. Você precisa manter a VM com falha em um estado em execução para coletar logs. Para coletar os logs, use um destes métodos:

• Habilite o diagnóstico de inicialização antes de criar a VM e, em seguida, exiba-o durante a inicialização.

• Console serial

• Execute o AZ VM Repair para anexar e montar o disco do sistema operacional (lvm, sem lvm), isso permitirá que você colete e examine 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 você encontrar um erro ou aviso, revise as entradas anteriores no log do cloud-init para entender o que o cloud-init estava tentando antes de ocorrer 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 logo 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 realizar.

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

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

Você pode obter informações do stdout e stderr durante os estágios de cloud-init. Esses dados normalmente envolvem informações da tabela de roteamento, informações de ede, informações de verificação da chave de host SSH, stdout, e stderr para cada estágio da cloud-init, juntamente com os carimbos de data/hora. Se desejar, os registros em log stderr e stdout podem ser reconfigurados de /etc/cloud/cloud.cfg.d/05_logging.cfg.

Logs de série/inicialização

O Cloud-init tem várias dependências. Essas dependências estão documentadas nos pré-requisitos necessários para imagens no Azure, como rede, armazenamento, 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 conseguir obter uma concessão DHCP, o cloud-init falhará.

Se você ainda não conseguir isolar por que o cloud-init falhou ao provisionar, precisará entender quais estágios de cloud-init e quando os módulos são executados. Para obter mais informações, confira Aprofundando-se em cloud-init.

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

Nem toda falha em cloud-init resulta em uma falha de provisionamento fatal. Por exemplo, se você estiver usando o módulo runcmd em uma configuração de cloud-init, um código de saída diferente de zero do comando fará com que o provisionamento da VM falhe. Esse comportamento ocorre porque o módulo é executado após as etapas principais de provisionamento nos três primeiros estágios de cloud-init. Para solucionar por que a configuração não se aplicou, analise os logs na Etapa 3 e revise manualmente os módulos do cloud-init. Por exemplo:

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

Próximas etapas

Se o cloud-init ignorar a configuração, analise cada estágio do cloud-init e o tempo de execução dos módulos para identificar a causa. Para obter mais informações, consulte Aprofundamento na configuração de cloud-init.