Felsöka etablering av virtuella datorer med cloud-init

Gäller för: Virtuella ✔️ Linux-datorer – ✔️ flexibla skalningsuppsättningar

Om du har skapat generaliserade anpassade avbildningar med hjälp av cloud-init för att etablera, men har upptäckt att den virtuella datorn inte har skapat korrekt, måste du felsöka dina anpassade avbildningar.

Några exempel på problem med etablering:

  • Den virtuella datorn fastnar vid skapande i 40 minuter och skapandet av den virtuella datorn markeras som misslyckad
  • CustomData bearbetas inte
  • Den tillfälliga disken kan inte monteras
  • Användare skapas inte, eller så finns det problem med användaråtkomst
  • Nätverk har inte ställts in korrekt
  • Växla fil- eller partitionsfel

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

Steg 1: Testa distributionen utan customData

Cloud-init kan acceptera customData, som skickas till den när den virtuella datorn skapas. Först bör du se till att detta inte orsakar några problem med distributioner. Försök att etablera den virtuella datorn utan att skicka in någon konfiguration. Om du upptäcker att den virtuella datorn inte kan etableras fortsätter du med stegen nedan. Om du upptäcker att konfigurationen som du använder inte tillämpas går du till steg 4.

Steg 2: Granska bildkraven

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

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

För De 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 skapas från din egen hanterade 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 fungerar customData korrekt med en Azure Marketplace bild finns det förmodligen ett problem med den hanterade avbildningen.

Steg 3: Samla in granskningsloggar & för virtuella datorer

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 distributionen av den virtuella datorn markeras som misslyckad, OSProvisioningTimedOut innan den slutligen markeras med ett fel.

När den virtuella datorn körs behöver du loggarna från den virtuella datorn för att förstå varför etableringen 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 felande virtuella datorn i körningstillstånd för att samla in loggar. Om du vill samla in loggarna använder du någon av följande metoder:

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

Starta den inledande felsökningen genom att börja med cloud-init-loggarna och förstå var felet inträffade. Använd sedan de andra loggarna för att göra en djupdykning och ge ytterligare insikter.

  • /var/log/cloud-init.log
  • /var/log/cloud-init-output.log
  • Seriella/startloggar

I alla loggar börjar du söka efter "Misslyckades", "VARNING", "VARNA", "fel", "fel", "FEL". Vi rekommenderar att du anger konfiguration för att ignorera fallkänsliga sökningar.

Tips

Om du felsöker en anpassad avbildning bör du överväga att lägga till en användare under avbildningen. Om etableringen inte kan konfigurera administratörsanvändaren kan du fortfarande logga in på operativsystemet.

Analysera loggarna

Här finns mer information om vad du kan söka efter i varje cloud-init-logg.

/var/log/cloud-init.log

Som standard skrivs alla cloud-init-händelser med prioritet för felsökning eller högre till /var/log/cloud-init.log. Detta ger utförliga loggar för varje händelse som inträffade under cloud-init-initiering.

Till exempel:

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 har hittat ett fel eller en varning kan du läsa bakåt i cloud-init-loggen för att förstå vad cloud-init försökte göra innan felet eller varningen inträffade. I många fall kommer cloud-init att ha kört OS-kommandon eller utfört etableringsåtgärder före felet, vilket kan ge insikter om varför fel uppstod i loggarna. I följande exempel visas att cloud-init försökte montera en enhet precis innan den träffar ett fel.

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 att köra kommandot som cloud-init försökte köra igen.

Loggning för /var/log/cloud-init.log kan också konfigureras 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 och stdout under stderr stegen i cloud-init. Detta omfattar vanligtvis information om routningstabeller, nätverksinformation, verifieringsinformation för SSH-värdnyckeln stdoutstderr och för varje steg i cloud-init, tillsammans med tidsstämpeln för varje steg. Om du vill stderr kan stdout loggning konfigureras om från /etc/cloud/cloud.cfg.d/05_logging.cfg.

Seriella/startloggar

Cloud-init har flera beroenden. Dessa dokumenteras i nödvändiga förutsättningar för avbildningar i Azure, till exempel nätverk, lagring, möjlighet att montera en ISO och montera och formatera den tillfälliga disken. Alla dessa kan orsaka 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 inte kunde etableras måste du förstå vilka cloud-init-steg och när moduler körs. Mer information finns i Simhopp på djupet i cloud-init .

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

Inte alla fel i cloud-init resulterar i ett allvarligt etableringsfel. Om du till runcmd exempel använder modulen i en cloud-init-konfiguration kommer en slutkod som inte är noll från det kommando som den kör att orsaka att VM-etableringen misslyckas. Det beror på att den körs efter grundläggande etableringsfunktioner som sker i de första tre stegen i cloud-init. Om du vill felsöka varför konfigurationen inte har tillämpat kan du granska loggarna i steg 3 och cloud-init-modulerna manuellt. Till exempel:

  • runcmd – Körs skripten utan fel? Kör konfigurationen manuellt från terminalen för att säkerställa att den körs som förväntat.
  • Installera paket – har den virtuella datorn åtkomst till paketdatabaser?
  • Du bör också kontrollera datakonfigurationen customData som angavs för den virtuella datorn. Den finns i /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Nästa steg

Om du fortfarande inte kan isolera varför cloud-init inte har kört konfigurationen måste du titta närmare på vad som händer i varje cloud-init-steg och när moduler körs. Mer information finns i Diving deeper into cloud-init configuration (Mer information finns i Mer information om cloud-init-konfiguration ).