Felsöka artefakter på virtuella labbdatorer i Azure DevTest Labs
Den här artikeln beskriver möjliga orsaker och felsökningssteg för artefaktfel på dina virtuella Azure DevTest Labs-resurser (VM).
Artefakter är verktyg, åtgärder eller programvara som du kan installera på virtuella labbdatorer under eller efter skapandet av den virtuella datorn. Labbägare kan välja obligatoriska artefakter som ska tillämpas på alla virtuella labbdatorer när de skapas, och labbanvändare kan tillämpa artefakter på virtuella datorer som de äger. Flera möjliga problem kan orsaka att artefakter inte kan installeras och tillämpas på ett labb eller köras korrekt på en virtuell labbdator.
När en artefakt verkar sluta svara är det första steget att försöka avgöra varför processen har fastnat. Artefaktinstallationen kan blockeras under den första begäran eller misslyckas under körningen av begäran. Du kan felsöka artefaktfel från Azure Portal eller från den virtuella dator där artefaktfelet inträffar.
Felsöka i Azure Portal
Om en artefakt inte har tillämpats på den virtuella labbdatorn kan du börja med att undersöka statusen för den virtuella datorn i Azure Portal. Du kan hitta information om tillståndet för den virtuella datorn, bekräfta att den körs och kontrollera att artefakter kan tillämpas. Aktivitetsloggdata för den virtuella labbdatorn visar poster om installationsprocesser. Du kan kontrollera posterna för att hitta information om artefaktfel.
Kontrollera vm-status
Kontrollera vm-tillståndet i Azure Portal genom att följa dessa steg:
Bläddra till sidan Översikt för den virtuella datorn DevTest Labs Labs och bekräfta att datorn körs:
Välj Artefakter och öppna artefaktlistan för den virtuella labbdatorn:
Kontrollera alternativet Tillämpa artefakter och bekräfta att den virtuella labbdatorn är redo att acceptera tillämpade artefakter:
När alternativet Tillämpa artefakter är nedtonat kan du inte tillämpa artefakter på den virtuella labbdatorn och du ser ett meddelande på sidan:
Använd PowerShell-kommandot
Du kan också använda Azure PowerShell för att kontrollera om den virtuella labbdatorn kan ta emot tillämpade artefakter.
Följande GET kommando returnerar canApplyArtifacts flaggan med värdet True eller False. Om du vill köra kommandot ersätter du parametern $LabName/$VmName med ditt labbnamn och vm-namn och anger din labbresursgrupp i parametern $LabRgName .
Select-AzSubscription -SubscriptionId $SubscriptionId | Out-Null
$vm = Get-AzResource `
-Name "$LabName/$VmName" `
-ResourceGroupName $LabRgName `
-ResourceType 'microsoft.devtestlab/labs/virtualmachines' `
-ApiVersion '2018-10-15-preview' `
-ODataQuery '$expand=Properties($expand=ComputeVm)'
$vm.Properties.canApplyArtifacts
Undersöka misslyckad artefaktinformation
En artefakt kan sluta svara och visas så småningom som Misslyckad i artefaktlistan för den virtuella labbdatorn.
Undersök misslyckade artefakter genom att följa dessa steg:
Bläddra till listsidan Artefakter för den virtuella labbdatorn och välj artefakten med statusen Misslyckad :
Artefaktinformationsvyn öppnas. Informationen innehåller information om distributionsmeddelandet och tilläggsmeddelandet om artefaktfelet:
Granska aktivitetsloggar
För att installera artefakter skapar och distribuerar DevTest Labs en ARM-mall (Azure Resource Manager) som begär användning av CSE (Custom Script Extension). Ett fel på den här nivån visas i aktivitetsloggarna för prenumerationen och för resursgruppen som innehåller den virtuella labbdatorn.
Kommentar
När du visar aktivitetsloggarna kan du behöva expandera installationsprocessposterna för att se felfelsammanfattningarna.
Granska aktivitetsloggposterna efter fel som rör installation eller tillämpning av artefakten på den virtuella labbdatorn med följande steg:
Bläddra till sidan Aktivitetslogg för den virtuella labbdatorn och leta upp artefakten med statusen Misslyckad :
Välj posten för att öppna informationsfönstret och visa logginformationen:
Om du försöker tillämpa artefakten direkt på den virtuella labbdatorn letar du efter fel som rör installationsprocessen för att skapa eller uppdatera tillägget för virtuella datorer .
Om du skapar en virtuell dator och tillämpar artefakten under processen letar du efter fel som rapporterats för installationsprocessen Skapa eller uppdatera virtuell dator .
Fönstrets rubrik motsvarar postrubriken, till exempel Tillämpa artefakter på den virtuella datorn:
I informationsfönstret väljer du JSON för att granska innehållet i JSON-nyttolasten. Du kan se felet i slutet av JSON-dokumentet:
Undersöka artefaktlagringsplats och labblagringskonto
När DevTest Labs tillämpar en artefakt läser den artefaktkonfigurationen och filerna från anslutna lagringsplatser. Om en artefakt inte kan installeras eller tillämpas på den virtuella labbdatorn kan problemet vara relaterat till lagringsplatsåtkomst.
Som standard har DevTest Labs åtkomst till den offentliga artefaktlagringsplatsen DevTest Labs. Du kan också ansluta ett labb till en privat lagringsplats för att få åtkomst till anpassade artefakter. Beroende på konfigurationen kanske de virtuella labbdatorerna inte har direkt åtkomst till artefaktlagringsplatsen. DevTest Labs cachelagrar artefakterna i ett labblagringskonto som skapades när labbet först initieras.
Om en anpassad artefakt inte kan installeras kontrollerar du att den personliga åtkomsttoken (PAT) för den privata lagringsplatsen inte har upphört att gälla. Om PAT har upphört att gälla visas inte artefakten och skript som refererar till artefakter från den lagringsplatsen misslyckas.
Om åtkomsten till lagringskontot blockeras kan ett fel som liknar det här exemplet visas:
CSE Error: Failed to download all specified files. Exiting. Exception: Microsoft.WindowsAzure.Storage.StorageException: The remote server returned an error: (403) Forbidden. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.Ett scenario där du kan stöta på det här felet är när trafik blockeras från den virtuella datorn till Azure Storage-tjänsten. Felet visas i aktivitetsloggen för resursgruppen för den virtuella labbdatorn.
Identifiera problem med lagringsplatsens anslutning till Azure Storage-kontot med följande steg:
Sök efter tillagda nätverkssäkerhetsgrupper (NSG:er). Om en prenumerationsprincip läggs till för att automatiskt konfigurera nätverkssäkerhetsgrupper i alla virtuella nätverk kan det påverka det virtuella nätverk som används för att skapa dina virtuella labbdatorer.
Kontrollera alla NSG-regler:
Använd KONTROLLERA IP-flöde för att avgöra om en NSG-regel blockerar trafik till eller från en virtuell dator.
Granska gällande regler för säkerhetsgrupper för att säkerställa att det finns en inkommande Tillåt NSG-regel. Mer information finns i Använda effektiva säkerhetsregler för att felsöka trafikflödet för virtuella datorer.
Kontrollera standardlagringskontot för ditt labb.
Standardlagringskontot är det första lagringskontot som skapades när labbet skapades. Namnet börjar vanligtvis med bokstaven "a" och slutar med ett flersiffrigt tal, till exempel
a<labname>#.Bläddra till sidan Översikt för den virtuella datorn DevTest Labs Labs och välj Resursvisualiserare.
Leta upp lagringskontot som har ett namn som matchar den namngivningskonvention som beskrivs i diagrammet.
a<labname>#Välj resursen Lagringskonto för att se popup-menyn och välj sedan Visa:
På sidan Översikt över lagringskonto expanderar du avsnittet Säkerhet + nätverk på den vänstra menyn och väljer Nätverk:
På fliken Brandväggar och virtuella nätverk kontrollerar du konfigurationen för alternativet Åtkomst till offentligt nätverk:
Om Aktiverad från valda virtuella nätverk och IP-adresser har valts bekräftar du listan över tillåtna IP-adresser som visar labbets virtuella nätverk som kan användas för att skapa virtuella labbdatorer:
Annars bekräftar du att Aktiverad från alla nätverk har valts:
Detaljerad felsökning finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.
Felsöka på labbdatorn
Du kan ansluta till den virtuella labbdatorn där artefakten misslyckades och undersöka problemet.
Granska loggfilen för anpassat skripttillägg
Visa loggfilen för det anpassade skripttillägget (CSE) för en virtuell Windows-dator genom att följa dessa steg:
Anslut till den virtuella DevTest Labs-labbdator som körs.
Öppna ett Utforskaren fönster och gå till C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\<CSE version>\Status\. Ett exempel på CSE-version> är
1.10.12.<
Öppna och granska en STATUS-fil för att visa felet, till exempel 1.status.
Anvisningar om hur du hittar loggfilerna på en virtuell Linux-dator finns i Använda Azure Custom Script Extension Version 2 med virtuella Linux-datorer.
Kontrollera Azure Virtual Machine Agent
Se till att Azure Virtual Machine Agent (VM Agent) för den virtuella labbdatorn är installerad och klar.
När den virtuella labbdatorn först startar, eller när CSE först installeras för att hantera begäran om att tillämpa artefakter, kan den virtuella labbdatorn behöva uppgradera VM-agenten eller vänta tills VM-agenten initieras. VM-agenten kan vara beroende av tjänster som tar lång tid att initiera.
Ta reda på om VM-agenten får artefakten att sluta svara genom att följa dessa steg:
Anslut till den virtuella DevTest Labs-labbdator som körs.
Öppna ett Utforskaren fönster och gå till mappen som har loggfilerna för den virtuella labbdatorn, till exempel C:\WindowsAzure\logs.
Öppna filen WaAppAgent.log .
Leta efter poster i loggfilen som visar att VM-agenten startar, avslutar initieringen och skickar det första pulsslaget. Sök igenom poster efter tidsstämplar runt den tid då du upplevde artefaktproblemet. Följande kodfragment visar några exempelposter från loggfilen:
[00000006] [11/14/2019 05:52:13.44] [INFO] WindowsAzureGuestAgent starting. Version 2.7.41491.949 ... [00000006] [11/14/2019 05:52:31.77] [WARN] Waiting for OOBE to Complete ... ... [00000006] [11/14/2019 06:02:30.43] [WARN] Waiting for OOBE to Complete ... [00000006] [11/14/2019 06:02:33.43] [INFO] StateExecutor initialization completed. [00000020] [11/14/2019 06:02:33.43] [HEART] WindowsAzureGuestAgent Heartbeat.I det här exemplet tog vm-agenten 10 minuter och 20 sekunder att starta. Fördröjningen beror på att OOBE-tjänsten (out-of-box-experience) tog lång tid att starta. Den långa starttiden för VM-agenten gjorde att artefakten slutade svara.
Allmän information om Azure-tillägg finns i Tillägg och funktioner för virtuella Azure-datorer. Mer felsökningsidéer finns i Översikt över Azure Virtual Machine Agent.
Undersöka problem med skript
En annan orsak till att artefaktinstallationen kan misslyckas beror på hur artefaktinstallationsskriptet har skapats.
Här är några exempel på potentiella skriptproblem:
Skriptet har obligatoriska parametrar, men ett förväntat värde skickas inte under skriptkörningen. Det här scenariot kan inträffa om användaren tillåts lämna en förväntad parameter tom och ett standardvärde inte anges i artifactfile.json definitionsfilen. Därför slutar skriptet att svara eftersom det väntar på användarindata. När skriptet kräver parametervärden är det bra att definiera standardvärden och kräva att användaren anger ett värde.
Skriptet kräver användaråtgärd under skriptkörningen. Det här scenariot kan inträffa om det finns en lång fördröjning i skriptkörningen i väntan på att användaren ska vidta åtgärder. Det är en bra idé att skapa skript som kan fungera tyst utan att användaren behöver ingripa.
Kontrollera om skriptet får artefakten att sluta svara genom att följa dessa steg:
Anslut till den virtuella DevTest Labs-labbdator som körs.
Öppna ett Utforskaren fönster.
Gå till mappen Ladda ned som har installationsskriptet för artefakt för den virtuella datorn, till exempel C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\<CSE version>\Downloads\. Ett exempel på CSE-version> är
1.10.12.<För efterföljande steg kan du arbeta med skriptet i den här mappen eller kopiera skriptet till en arbetsmapp på den virtuella datorn.
Öppna ett kommandotolkfönster med administratörsbehörighet på den virtuella datorn.
Kör installationsskriptet för artefakt i kommandotolkens fönster.
Följ skriptprompterna och ange de obligatoriska parametervärdena. Om du vill undersöka om brist på användarindata eller fördröjd användaråtgärd orsakar ett problem kan du försöka återskapa det specifika beteendet.
Kontrollera om skriptet visar oväntat eller problematiskt beteende.
Korrigera skriptet på den virtuella labbdatorn efter behov och kör skriptet igen för att bekräfta att problemen är lösta.
Kontrollera artefaktstrukturen
En anpassad artefakt måste ha rätt struktur. Kontrollera att anpassade artefakter i artefaktinstallationsskriptet implementerar rätt struktur. Följande resurser innehåller information som hjälper dig att slutföra den här kontrollen:
- Information om hur du konstruerar en artefakt korrekt finns i Skapa anpassade artefakter.
- Ett exempel på en korrekt strukturerad artefakt finns i artefakten Testparametertyper .
- Mer information om hur du skriver och korrigerar artefaktskript finns i AUTHORING.
Uppdatering av begärandeskript
Du kan skicka föreslagna skriptkorrigeringar för artefakter som finns på den offentliga lagringsplatsen DevTest Labs. Mer information finns i avsnittet Bidrag i README-dokumentet .
Få support
Om du behöver mer hjälp kan du prova någon av följande supportkanaler:
Sök i Microsoft Community-webbplatsresurserna efter information om Azure DevTest Labs och få åtkomst till inlägg på Stack Overflow.
Anslut med @AzureSupport, det officiella Microsoft Azure-kontot för att förbättra kundupplevelsen. Azure Support ansluter Azure-communityn till svar, support och experter.