Felsöka etablering av virtuella datorer med cloud-init

Gäller för: ✔️ Flexibla skalningsuppsättningar för virtuella Linux-datorer ✔️

Om du skapar generaliserade anpassade avbildningar och använder cloud-init för tillhandahållande kanske den virtuella maskinen inte byggs korrekt. I så fall felsöker du avbildningen för att hitta problemet.

Några exempel på problem med etablering:

• API:et för beräkningsresursprovidern returnerar ett fel och cloud-init rapporterar det resulterande felet.
• Den virtuella datorn fastnar vid att "skapa" i 40 minuter och skapandet av den virtuella datorn markeras som misslyckad.
• Anpassade data eller användardata bearbetas inte.
• Den tillfälliga disken kan inte monteras (för VM-sku:er som medföljer SCSI-resursdiskar).
• Användare skapas inte, eller så finns det problem med användaråtkomst.
• Nätverk har inte konfigurerats korrekt.
• Växla fil- eller partitionsfel.

Den här artikeln beskriver hur du felsöker cloud-init. Mer detaljerad information finns i djupdykning i cloud-init.

Felsöka fel som rapporteras av cloud-init och loggas som fel

Cloud-init genererar strukturerade fel när den rapporterar fel till Azure under distributionen. Dessa felmeddelanden innehåller en orsak och stöddata (till exempel tidsstämpel, VM-identifierare, dokumentations-URL osv.) för att undersöka felet.

Mer information om hur du aktiverar och kontrollerar startdiagnostik finns i Startdiagnostik.

Om något av dessa problem kvarstår vid efterföljande provisioneringsförsök beror det på en felaktig konfiguration i avbildningen. Om det finns anledning att tro att det finns ett problem med cloud-init rapporterar du det till GitHub-problemspåraren cloud-init.

Felsöka andra fel som inte rapporterats av cloud-init

Följ dessa steg beroende på vad som gått fel.

Steg 1: Testa distributionen utan customData

Cloud-init kan acceptera customData som skickas till den när VM skapas. Först bör du se till att den här konfigurationen inte orsakar några problem med distributioner. Försök att etablera den virtuella datorn utan att skicka någon konfiguration. Om den virtuella datorn inte kan provisioneras följer du de rekommenderade felsökningsstegen. Om konfigurationen inte tillämpas, se steg 4.

Steg 2: Granska bildkraven

Den främsta orsaken till vm-etableringsfel är att OS-avbildningen inte uppfyller kraven för att köras i Azure. Se till att dina avbildningar är korrekt förberedda innan du försöker etablera dem i Azure.

Följande artiklar illustrerar stegen för att förbereda olika Linux-distributioner som stöds i Azure:

• CentOS-baserade distributioner
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES &openSUSE
• Ubuntu
• Andra: Icke-godkända distributioner

För azure cloud-init-avbildningar som stöds har Linux-distributionerna redan alla nödvändiga paket och konfigurationer på plats för att korrekt etablera avbildningen i Azure. Om du upptäcker att den virtuella datorn inte kan skapa från din egen kurerade avbildning kan du prova en Azure Marketplace-avbildning som stöds och som redan har konfigurerats för cloud-init, med din valfria customData. Om det customData fungerar korrekt med en Azure Marketplace-avbildning finns det förmodligen problem med din anpassade avbildning.

Steg 3: Samla in och granska VM-loggar

När den virtuella datorn inte kan etableras visar Azure statusen "skapar" i 20 minuter, och startar sedan om den virtuella datorn och väntar ytterligare 20 minuter innan den slutligen markerar vm-distributionen som misslyckad, med ett OSProvisioningTimedOut fel.

När den virtuella datorn körs behöver du loggarna från den virtuella datorn för att förstå varför provisioneringen misslyckades. Stoppa inte den virtuella datorn för att förstå varför etableringen av virtuella datorer misslyckades. Håll den virtuella datorn igång. Du måste behålla den misslyckade virtuella datorn i gång för att kunna samla in loggar. Om du vill samla in loggarna använder du någon av följande metoder:

• Aktivera Startdiagnostik innan du skapar den virtuella datorn och visa dem sedan under starten.

• Seriekonsol

• Kör AZ VM Repair för att ansluta och montera OS-disken (lvm, ingen lvm), vilket gör att du kan samla in och undersöka dessa loggar:

  /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

När du hittar ett fel eller en varning läser du bakåt i cloud-init-loggen för att förstå vilket cloud-init som försökte innan felet eller varningen inträffade. I många fall kör cloud-init OS-kommandon eller utför etableringssteg innan felet inträffar. Dessa åtgärder kan hjälpa dig att förklara varför felet visas i loggarna. I följande exempel visas att cloud-init försökte montera en enhet precis innan problemet uppstod.

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)

Om du har åtkomst till seriekonsolen kan du försöka köra kommandot som cloud-init försökte köra igen.

Loggningen för /var/log/cloud-init.log kan också konfigureras om i /etc/cloud/cloud.cfg.d/05_logging.cfg. Mer information om cloud-init-loggning finns i dokumentationen för cloud-init.

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

Du kan hämta information från stdout och stderr under stegen i cloud-init. Dessa data omfattar normalt routningstabellsinformation, nätverksinformation, ssh-värdnyckelverifikationsinformation stdout, och stderr varje steg av cloud-init, samt tidsstämplar. Om du vill stderrstdout kan loggning konfigureras om från /etc/cloud/cloud.cfg.d/05_logging.cfg.

Serie- och startloggar

Cloud-init har flera beroenden. Dessa beroenden dokumenteras i de nödvändiga kraven för avbildningar i Azure, till exempel nätverk, lagring, möjligheten att montera en ISO och att montera och formatera den tillfälliga disken. Något av dessa beroenden kan utlösa fel och orsaka att cloud-init misslyckas. Om den virtuella datorn till exempel inte kan få ett DHCP-lån misslyckas cloud-init.

Om du fortfarande inte kan isolera varför cloud-init misslyckades att tillhandahålla måste du förstå vilka steg i cloud-init som finns och när modulerna körs. Mer information finns i Dykning djupare in i cloud-init.

Steg 4: Undersöka varför konfigurationen inte tillämpas

Alla fel i cloud-init resulterar inte i ett allvarligt etableringsfel. Om du till exempel använder modulen runcmd i en cloud-init-konfiguration, gör en utgångskod som inte är noll från kommandot att provisioneringen av den virtuella maskinen misslyckas. Det här beteendet beror på att modulen körs efter de grundläggande etableringsstegen i de tre första stegen i cloud-init. Om du vill felsöka varför konfigurationen inte tillämpades läser du loggarna i steg 3 och cloud-init-modulerna manuellt. Till exempel:

• runcmd – körs skripten utan fel? För att säkerställa att de körs som förväntat kör du konfigurationen manuellt från terminalen.
• Installerar paket – har den virtuella datorn åtkomst till paketlagringsplatser?
• Kontrollera konfigurationen customData som har angetts för den virtuella datorn. Den här filen finns i /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Nästa steg

Om cloud-init hoppar över konfigurationen, undersök varje cloud-init-steg och tidpunkten för modulutförandet för att kunna identifiera orsaken. Mer information finns i Dykning djupare i cloud-init-konfiguration.