Problemen met het inrichten van VM's oplossen met cloud-init

Waarschuwing

In dit artikel wordt verwezen naar CentOS, een Linux-distributie met de status End Of Support (EOS). Houd rekening met uw gebruik en plan dienovereenkomstig. Voor meer informatie, zie de CentOS End Of Life guidance.

Van toepassing op: ✔️ Flexibele schaalsets voor Linux-VM's ✔️

Als u gegeneraliseerde aangepaste installatiekopieën maakt en cloud-init gebruikt voor het inrichten, wordt de VM mogelijk niet correct gebouwd. In dat geval onderzoekt u de image om het probleem te vinden.

Enkele voorbeelden van problemen met het inrichten:

• De API van de compute-resourceprovider retourneert een fout en cloud-init rapporteert de resulterende fout.
• De VM blijft 40 minuten hangen bij 'maken' en het maken van de VIRTUELE machine is gemarkeerd als mislukt.
• Aangepaste gegevens of gebruikersgegevens worden niet verwerkt.
• De tijdelijke schijf kan niet worden gekoppeld (voor VM-sku's die worden geleverd met SCSI-resourceschijven).
• Gebruikers worden niet gemaakt of er zijn problemen met gebruikerstoegang.
• Netwerken zijn niet juist ingesteld.
• Bestands- of partitiefouten wisselen.

In dit artikel wordt uitgelegd hoe u problemen met cloud-init oplost. Zie cloud-init voor meer gedetailleerde informatie.

Fouten oplossen die zijn gerapporteerd door cloud-init en geregistreerd als fout

Cloud-init verzendt gestructureerde fouten bij het rapporteren van fouten naar Azure tijdens het provisioneren. Deze foutberichten bevatten een reden en ondersteunende gegevens (zoals tijdstempel, VM-id, documentatie-URL, enzovoort) om de fout te onderzoeken.

Reden	Beschrijving	Handeling
kan DHCP-interface niet vinden	Er is geen netwerkinterface gevonden.	Virtuele machine verwijderen en opnieuw maken. Als het probleem zich blijft voordoen, controleer dan of netwerkstuurprogramma's of de Azure-specifieke kernel zijn geïnstalleerd en bekijk de diagnostische gegevens over opstarten om te bevestigen dat eth0 wordt weergegeven.
kan DHCP-lease niet verkrijgen	Dhcp-service reageert niet vanwege een tijdelijk platformprobleem.	Virtuele machine verwijderen en opnieuw maken.
kan de primaire DHCP-interface niet vinden	De primaire DHCP-interface is niet gevonden.	Controleer diagnostische gegevens over opstarten om ervoor te zorgen dat de primaire netwerkinterface een naam eth0 heeft en de naam ervan niet wordt gewijzigd.
verbindingstime-out bij het opvragen van IMDS	Verbindingen met IMDS kunnen time-outs ondervinden vanwege een tijdelijk platformprobleem, een NSG of een firewallconfiguratie van het besturingssysteem.	Virtuele machine verwijderen en opnieuw maken. Als het probleem zich blijft voordoen, controleert u of de NSG- of besturingssysteemfirewall de toegang tot IMDS niet verhindert.
time-out bij het opvragen van IMDS	Verbindingen met IMDS kunnen een time-out hebben vanwege het tijdelijk platformprobleem of de configuratie van de besturingssysteem-firewall.	Virtuele machine verwijderen en opnieuw maken. Als het probleem zich blijft voordoen, controleert u of de firewall van het besturingssysteem geen toegang tot IMDS verhindert.
onverwachte parsering van metagegevens ovf-env.xml	Incorrecte VM-metagegevens in ovf-env.xml.	Verzend het probleem naar de cloud-init-tracker met behulp van de opgegeven koppeling.
fout bij het wachten op afsluiten van de host	Fout tijdens het afhandelen van het afsluiten van de host.	Verzend het probleem naar de cloud-init-tracker met behulp van de opgegeven koppeling.
Azure-proxy-agent is niet gevonden	Het azure-proxy-agent binaire bestand ontbreekt.	Zorg ervoor dat de Azure-proxyagent in de image is geïnstalleerd. Raadpleeg de handleiding voor het oplossen van problemen met MSP voor meer informatie.
Fout in status van Azure-proxy-agent	Proxyagent heeft een statusfout gerapporteerd.	Controleer de logboeken van de proxyagent en werk indien nodig bij. Raadpleeg de handleiding voor het oplossen van problemen met MSP voor meer informatie.
niet-afgehandelde uitzondering	Er is een onverwachte fout opgetreden in cloud-init.	Verzend het probleem naar de cloud-init-tracker met behulp van de opgegeven koppeling.

Zie Diagnostische gegevens over opstarten voor hulp bij het inschakelen en controleren van diagnostische gegevens over opstarten.

Als een van deze problemen zich blijft voordoen bij latere pogingen tot voorziening, is dit het gevolg van een onjuiste configuratie in het imagebestand. Als er reden is om te geloven dat er een cloud-init-probleem is, meldt u dit aan de cloud-init GitHub-probleemtracker.

Problemen oplossen met andere fouten die niet zijn gerapporteerd door cloud-init

Afhankelijk van de fout, overweeg deze stappen.

Stap 1: De implementatie testen zonder customData

Cloud-init kan customData ontvangen dat wordt doorgegeven wanneer de virtuele machine wordt aangemaakt. Eerst moet u ervoor zorgen dat deze configuratie geen problemen met implementaties veroorzaakt. Probeer de VIRTUELE machine in te richten zonder configuratie door te geven. Als de VM niet kan worden geleverd, volgt u de aanbevolen stappen voor probleemoplossing. Als de configuratie niet is toegepast, raadpleegt u stap 4.

Stap 2: Vereisten voor installatiekopieën controleren

De primaire oorzaak van een VM-inrichtingsfout is dat de installatiekopie van het besturingssysteem niet voldoet aan de vereisten voor uitvoering in Azure. Zorg ervoor dat uw installatiekopieën goed zijn voorbereid voordat u ze in Azure inricht.

In de volgende artikelen ziet u de stappen voor het voorbereiden van verschillende Linux-distributies die worden ondersteund in Azure:

• CentOS-distributies
• Debian Linux-
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES en OpenSUSE
• Ubuntu
• Overig: niet-goedgekeurde distributies

Voor de ondersteunde Azure-cloud-init-installatiekopieën beschikken de Linux-distributies al over alle vereiste pakketten en configuraties om de installatiekopieën correct in te richten in Azure. Als u merkt dat uw virtuele machine niet kan worden gemaakt op basis van uw eigen gecureerde installatiekopieën, probeert u een ondersteunde Azure Marketplace-installatiekopieën die al zijn geconfigureerd voor cloud-init, met uw optionele customDatainstallatiekopieën. Als de customData correct werkt met een Azure Marketplace-image, is er waarschijnlijk een probleem met uw samengestelde image.

Stap 3: VM-logboeken verzamelen en controleren

Wanneer de VM niet kan worden ingericht, geeft Azure gedurende 20 minuten de status 'maken' weer. Vervolgens wordt de virtuele machine opnieuw opgestart en wacht men nog eens 20 minuten voordat de implementatie van de virtuele machine als mislukt wordt gemarkeerd en uiteindelijk met een OSProvisioningTimedOut fout wordt aangegeven.

Terwijl de VM wordt uitgevoerd, hebt u de logboeken van de VM nodig om te begrijpen waarom het inrichten is mislukt. Als u wilt weten waarom het inrichten van VM's is mislukt, stopt u de VM niet. Houd de VM actief. U moet de mislukte VM in een actieve status houden om logboeken te kunnen verzamelen. Gebruik een van de volgende methoden om de logboeken te verzamelen:

• Schakel Diagnostische gegevens over opstarten in voordat u de virtuele machine maakt en bekijk deze vervolgens tijdens het opstarten.

• Seriële console

• Voer AZ VM Repair uit om de besturingssysteemschijf (lvm, geen lvm) te koppelen en te koppelen, zodat u deze logboeken kunt verzamelen en onderzoeken:

  /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

Wanneer u een fout of waarschuwing vindt, leest u achteruit in het cloud-init-logboek om te begrijpen wat cloud-init heeft geprobeerd voordat de fout of waarschuwing werd bereikt. In veel gevallen voert cloud-init os-opdrachten uit of voert de inrichtingsstappen uit voordat de fout optreedt. Deze acties kunnen helpen verklaren waarom de fout wordt weergegeven in de logboeken. In het volgende voorbeeld ziet u dat cloud-init heeft geprobeerd een apparaat te koppelen vlak voordat het probleem is opgetreden.

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)

Als u toegang hebt tot de seriële console, kunt u proberen de opdracht die cloud-init probeerde uit te voeren opnieuw uit te voeren.

De logboekregistratie voor /var/log/cloud-init.log kan ook opnieuw worden geconfigureerd binnen /etc/cloud/cloud.cfg.d/05_logging.cfg. Zie de cloud-init-documentatie voor meer informatie over cloud-init-logboekregistratie.

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

U kunt informatie ophalen uit de stdout en stderr tijdens de fasen van cloud-init. Deze gegevens bevatten normaal gesproken routeringstabelgegevens, netwerkinformatie, ssh-hostsleutelverificatiegegevens stdout, en stderr voor elke fase van cloud-init, samen met de tijdstempels. Indien gewenst stderr , en stdout logboekregistratie kan opnieuw worden geconfigureerd vanuit /etc/cloud/cloud.cfg.d/05_logging.cfg.

Seriële/opstartlogboeken

Cloud-init heeft meerdere afhankelijkheden. Deze afhankelijkheden worden beschreven in de vereisten voor images in Azure, zoals netwerken, opslag, de mogelijkheid om een ISO te verbinden en de tijdelijke schijf te verbinden en te formatteren. Een van deze afhankelijkheden kan fouten veroorzaken en ervoor zorgen dat cloud-init mislukt. Als de VM bijvoorbeeld geen DHCP-lease kan krijgen, mislukt cloud-init.

Als u nog steeds niet kunt isoleren waarom cloud-init niet kon worden ingericht, moet u weten welke cloud-init-fasen en wanneer modules worden uitgevoerd. Zie Dieper ingaan op cloud-init voor meer informatie.

Stap 4: Onderzoeken waarom de configuratie niet wordt toegepast

Niet elke fout in cloud-init resulteert in een fatale inrichtingsfout. Als u bijvoorbeeld de runcmd module in een cloud-init-configuratie gebruikt, zorgt een niet-nul-afsluitcode van de opdracht ervoor dat de VM-inrichting mislukt. Dit gedrag treedt op omdat de module wordt uitgevoerd na de belangrijkste inrichtingsstappen in de eerste drie fasen van cloud-init. Als u wilt oplossen waarom de configuratie niet is toegepast, raadpleegt u de logboeken in stap 3 en cloud-init-modules handmatig. Voorbeeld:

• runcmd - worden de scripts zonder fouten uitgevoerd? Voer de configuratie handmatig uit vanuit de terminal om ervoor te zorgen dat ze worden uitgevoerd zoals verwacht.
• Pakketten installeren: heeft de VM toegang tot pakketopslagplaatsen?
• Controleer de customData configuratie die is opgegeven voor de VIRTUELE machine. Dit bestand bevindt zich in /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Volgende stappen

Als cloud-init de configuratie overslaat, controleert u elke cloud-init-fase en de timing van de uitvoering van de module om de oorzaak te identificeren. Voor meer informatie, zie meer verdieping in cloud-init-configuratie.