Felsöka replikeringsproblem vid agentlös migrering av virtuella VMware-datorer

I den här artikeln beskrivs några vanliga problem och specifika fel som kan uppstå när du replikerar lokala virtuella VMware-datorer med hjälp av Azure Migrate: Agentlös servermigreringsmetod.

När du replikerar en virtuell VMware-dator med den agentlösa replikeringsmetoden replikeras data från den virtuella datorn's-diskar (vmdks) till hanterade replikdiskar i din Azure-prenumeration. När replikeringen startar för en virtuell dator sker en inledande replikeringscykel där fullständiga kopior av diskarna replikeras. När den inledande replikeringen är klar schemaläggs inkrementella replikeringscykler regelbundet för att överföra ändringar som har inträffat sedan den föregående replikeringscykeln.

Ibland kan replikeringscykler misslyckas för en virtuell dator. De här felen kan inträffa på grund av allt från problem i lokal nätverkskonfiguration till problem på Azure Migrate Cloud Service-serveruppsättningen. I den här artikeln kommer vi att:

  • Visar hur du kan övervaka replikeringsstatus och lösa fel.
  • Lista några av de vanligaste replikeringsfelen och föreslå ytterligare åtgärder för att åtgärda dem.

Övervaka replikeringsstatus med hjälp av Azure Portal

Använd följande steg för att övervaka replikeringsstatusen för dina virtuella datorer:

  1. Gå till sidan Servrar i Azure Migrate på Azure Portal. Bild 1
  2. Gå till sidan "Replikera datorer" genom att klicka på "Replikera servrar" på panelen Server Migration. Bild 2
  3. Du ser en lista över servrar som replikeras tillsammans med ytterligare information, till exempel status, hälsa, senaste synkroniseringstid osv. Hälsokolumnen anger den virtuella datorns aktuella replikeringshälsa. Värdet Kritisk eller Varning i hälsokolumnen anger vanligtvis att den tidigare replikeringscykeln för den virtuella datorn misslyckades. Om du vill ha mer information högerklickar du på den virtuella datorn och väljer "Felinformation". Sidan Felinformation innehåller information om felet och ytterligare information om hur du felsöker. Du ser även länken Senaste händelser som kan användas för att navigera till händelsesidan för den virtuella datorn. Bild 3
  4. Klicka på Senaste händelser om du vill se tidigare replikeringscykelfel för den virtuella datorn. På händelsesidan letar du efter den senaste händelsen av typen "Replikeringscykeln misslyckades" eller "Replikeringscykeln misslyckades för disk" för den virtuella datorn. Bild 4
  5. Klicka på händelsen för att förstå möjliga orsaker till felet och rekommenderade åtgärdssteg. Använd informationen för att felsöka och åtgärda felet. Bild 5

Vanliga replikeringsfel

I det här avsnittet beskrivs några av de vanligaste felen och hur du kan felsöka dem.

Key Vault misslyckades vid försök att replikera virtuella datorer

Fel: "Key Vault åtgärden misslyckades. Åtgärd: Konfigurera hanterat lagringskonto, Key Vault: Key-vault-name, Storage Account: storage account name failed with the error:"

Fel: "Key Vault åtgärden misslyckades. Åtgärd: Generera signaturdefinition för delad åtkomst, Key Vault: Key-vault-name, Storage Account: storage account name failed with the error:"

Key Vault

Det här felet uppstår vanligtvis eftersom principen för användaråtkomst för Key Vault inte ger den inloggade användaren de behörigheter som krävs för att konfigurera lagringskonton som ska Key Vault hanteras. Om du vill söka efter principer för användaråtkomst i nyckelvalvet går du till sidan Nyckelvalv i portalen för nyckelvalvet och väljer Åtkomstprinciper

När portalen skapar nyckelvalvet läggs även en princip för användaråtkomst till som beviljar de inloggade användarbehörigheterna för att konfigurera lagringskonton som ska Key Vault hanteras. Detta kan misslyckas av två orsaker

  • Den inloggade användaren är ett fjärrhuvudnamn på kundernas Azure-klientorganisation (CSP-prenumeration – och den inloggade användaren är partneradministratören). Lösningen i det här fallet är att ta bort nyckelvalvet, logga ut från portalen och sedan logga in med ett användarkonto från kundens klientorganisation (inte ett fjärrobjekt) och sedan försöka igen. CSP-partnern har vanligtvis ett användarkonto i kundens klientorganisation Azure Active Directory som de kan använda. Annars kan de skapa ett nytt användarkonto åt sig själva i kundens Azure Active Directory klientorganisation, logga in på portalen som den nya användaren och sedan försöka utföra replikeringsåtgärden igen. Kontot som används måste ha behörigheterna Ägare eller Deltagare +Administratör för användaråtkomst beviljat till kontot i resursgruppen (Migrera projektresursgrupp)

  • Det andra fallet där detta kan inträffa är när en användare (user1) försökte konfigurera replikeringen från början och påträffade ett fel, men nyckelvalvet redan har skapats (och principen för användaråtkomst har tilldelats till den här användaren). Vid ett senare tillfälle försöker en annan användare (user2) konfigurera replikeringen, men åtgärden Konfigurera hanterat Storage-konto eller Generera SAS-definition misslyckas eftersom det inte finns någon princip för användaråtkomst som motsvarar user2 i nyckelvalvet.

Lösning: För att lösa det här problemet skapar du en princip för användaråtkomst för användare2 i nyckelvalvet som beviljar user2-behörighet för att konfigurera hanterat lagringskonto och generera SAS-definitioner. User2 kan göra detta från Azure PowerShell med cmdletarna nedan:

$userPrincipalId = $(Get-AzureRmADUser -UserPrincipalName "user2_email_address"). Id

Set-AzureRmKeyVaultAccessPolicy -VaultName "keyvaultname" -ObjectId $userPrincipalId -PermissionsToStorage get, list, delete, set, update, regeneratekey, getsas, listsas, deletesas, setsas, recover, backup, restore, purge

DisposeArtefactsTimedOut

Fel-ID: 181008

Felmeddelande: VM: VMName. Fel: Timeout-händelsen "DisposeArtefactsTimeout" inträffade i tillståndet &'['Gateway.Service.StateMachine.SnapshotReplication.SnapshotReplicationEngine+WaitingForArtefactsGilosalPreCycle' ('WaitingForArtefactsGilosalPreCycle')]'.

Möjliga orsaker:

Komponenten som försöker replikera data till Azure fungerar inte eller svarar inte. Möjliga orsaker är:

  • Gatewaytjänsten som körs i Azure Migrate är ur funktion.
  • Gatewaytjänsten har anslutningsproblem för att Service Bus/händelsehubb/installation Storage konto.

Identifiera den exakta orsaken till DisposeArtefactsTimedOut och motsvarande lösning:

  1. Kontrollera att Azure Migrate-installationen är igång.

  2. Kontrollera om gatewaytjänsten körs på enheten:

    1. Logga in på Azure Migrate med hjälp av fjärrskrivbordet och gör följande.

    2. Öppna Microsoft-tjänster MMC-snapin-modulen (kör > services.msc) och kontrollera om "Microsoft Azure Gateway Service" körs. Om tjänsten har stoppats eller inte körs startar du tjänsten. Du kan också öppna kommandotolken eller PowerShell och göra: "Net Start asrgwy"

  3. Kontrollera anslutningsproblem mellan Azure Migrate installation och Storage konto:

    Kör följande kommando när du har laddat ned azcopy i Azure Migrate installationen:

    azcopycopycopy https://[account].blob.core.windows.net/[container]? Sas

    Steg för att köra prestandatestet:

    1. Ladda ned azcopy

    2. Leta efter enheten Storage konto i resursgruppen. Kontot Storage har ett namn som liknar migrategwsa * * * * * * * * * * . Det här är värdet för parametern [account] i kommandot ovan.

    3. Sök efter ditt lagringskonto i Azure Portal. Kontrollera att den prenumeration som du använder för att söka är samma prenumeration (målprenumeration) som lagringskontot skapas i. Gå till Containrar i avsnittet Blob Service. Klicka på +Container och skapa en Container. Låt Offentlig åtkomstnivå vara kvar på det valda standardvärdet.

    4. Gå till Signatur för delad åtkomst under Inställningar. Välj Container i "Tillåten resurstyp". Klicka på Generera SAS och anslutningssträng. Kopiera SAS-värdet.

    5. Kör kommandot ovan i kommandotolken genom att ersätta konto, container, SAS med de värden som hämtas i steg 2, 3 respektive 4.

    Du kan också ladda Azure Storage Utforska vidare till installationen och försöka ladda upp 10 blobar på ~64 MB till lagringskontona. Om det inte finns något problem bör uppladdningen lyckas.

    Lösning: Om det här testet misslyckas'är ett nätverksproblem. Engagera ditt lokala nätverksteam för att kontrollera anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

  4. Kontrollera anslutningsproblem mellan Azure Migrate och Service Bus:

    Det här testet kontrollerar Azure Migrate enheten kan kommunicera med Azure Migrate Cloud Service-backend. Installationen kommunicerar med tjänstens backend-enhet via Service Bus och Händelsehubb-meddelandeköer. Om du vill verifiera anslutningen från enheten till Service Bus laddar du ned Service Bus Explorer, försöker ansluta till installationen och Service Bus skicka meddelande/ta emot meddelande. Om det inte finns något problem bör detta lyckas.

    Steg för att köra testet:

    1. Kopiera anslutningssträngen från Service Bus som skapades i Project
    2. Öppna Service Bus Explorer
    3. Gå till Arkiv och Anslut
    4. Klistra in anslutningssträngen och klicka på Anslut
    5. Detta öppnar Service Bus namnrymden
    6. Välj Snapshot Manager i ämnet. Högerklicka på Snapshot Manager, välj "Ta emot meddelanden" > "peek" och klicka på OK
    7. Om anslutningen lyckas visas [x] meddelanden som tagits emot i konsolens utdata. Om anslutningen inte lyckas visas ett meddelande om att anslutningen misslyckades

    Lösning: Om det här testet misslyckas uppstår ett nätverksproblem. Engagera ditt lokala nätverksteam för att kontrollera anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

  5. Anslutningsproblem mellan Azure Migrate och Azure Key Vault:

    Det här testet söker efter anslutningsproblem mellan Azure Migrate och Azure Key Vault. Den Key Vault används för att hantera Storage kontoåtkomst som används för replikering.

    Steg för att kontrollera anslutningen:

    1. Hämta Key Vault URI från listan över resurser i resursgruppen som motsvarar Azure Migrate Project.

    2. Öppna PowerShell i Azure Migrate och kör följande kommando:

    test-netconnection Key Vault URI -P 443

    Det här kommandot försöker upprätta en TCP-anslutning och returnerar utdata.

    • I utdata kontrollerar du fältet "TcpTestSucceeded". Om värdet är "True" (Sant) finns det inget anslutningsproblem mellan Azure Migrate Appliance och Azure Key Vault. Om värdet är "False" uppstår ett anslutningsproblem.

    Lösning: Om det här testet misslyckas finns det ett anslutningsproblem mellan Azure Migrate och Azure Key Vault. Engagera ditt lokala nätverksteam för att kontrollera anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

DiskUploadTimedOut

Fel-ID: 1011

Felmeddelande: Uppladdning av data för disk DiskPath, DiskId för den virtuella datorn VMName; VMId slutförde inte inom förväntad tid.

Det här felet indikerar vanligtvis antingen att Azure Migrate-installationen som utför replikeringen inte kan ansluta till Azure Cloud Services eller att replikeringen går långsamt vilket gör att replikeringscykeln får en time out.

Möjliga orsaker är:

  • Enheten Azure Migrate är ur funktion.
  • Replikeringsgatewaytjänsten på installationen körs inte.
  • Replikeringsgatewaytjänsten har anslutningsproblem till någon av följande Azure-tjänstkomponenter som används för replikering: Service Bus/Event Hub/Azure Cache Storage Account/Azure Key Vault.
  • Gatewaytjänsten begränsas på vCenter-nivå vid försök att läsa disken.

Identifiera rotorsaken och lösa problemet:

  1. Kontrollera att Azure Migrate-installationen är igång.

  2. Kontrollera om gatewaytjänsten körs på enheten:

    1. Logga in på Azure Migrate med hjälp av fjärrskrivbord och gör följande.

    2. Öppna mmc-snapin-modulen Microsoft-tjänster (kör > services.msc) och kontrollera om "Microsoft Azure Gateway Service" körs. Om tjänsten har stoppats eller inte körs startar du tjänsten. Du kan också öppna kommandotolken eller PowerShell och göra: "Net Start asrgwy".

  3. Sök efter anslutningsproblem mellan Azure Migrate och cachelagring Storage skontot:

    Kör följande kommando när du har laddat ned azcopy i Azure Migrate installationen:

    azcopycopycopy https://[account].blob.core.windows.net/[container]? Sas

    Steg för att köra prestandatestet:

    1. Ladda ned azcopy

    2. Leta efter Storage i resursgruppen. Kontot Storage har ett namn som liknar migratelsa * * * * * * * * * * . Det här är värdet för parametern [account] i kommandot ovan.

    3. Sök efter ditt lagringskonto i Azure Portal. Kontrollera att den prenumeration som du använder för att söka är samma prenumeration (målprenumeration) som lagringskontot skapas i. Gå till Containrar i avsnittet Blob Service. Klicka på +Container och skapa en Container. Låt Offentlig åtkomstnivå vara kvar på det valda standardvärdet.

    4. Gå till Signatur för delad åtkomst under Inställningar. Välj Container i "Tillåten resurstyp". Klicka på Generera SAS och anslutningssträng. Kopiera SAS-värdet.

    5. Kör kommandot ovan i kommandotolken genom att ersätta konto, container, SAS med de värden som hämtas i steg 2, 3 respektive 4.

    Du kan också ladda ned Azure Storage Utforska vidare till installationen och försöka ladda upp 10 blobar på ~64 MB till lagringskontona. Om det inte finns något problem bör uppladdningen lyckas.

    Lösning: Om det här testet misslyckas'ett nätverksproblem. Engagera ditt lokala nätverksteam för att kontrollera anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

  4. Anslutningsproblem mellan Azure Migrate och Azure Service Bus:

    Det här testet kontrollerar om Azure Migrate kan kommunicera med Azure Migrate Cloud Service-backend. Installationen kommunicerar med tjänstens backend via Service Bus och Event Hub-meddelandeköer. Om du vill verifiera anslutningen från enheten till Service Bus laddar du ned Service Bus Explorer, försöker ansluta till enheten och Service Bus skicka meddelande/ta emot meddelande. Om det inte finns något problem bör detta lyckas.

    Steg för att köra testet:

    1. Kopiera anslutningssträngen från Service Bus som skapades i resursgruppen som motsvarar Azure Migrate Project

    2. Öppna Service Bus Explorer

    3. Gå till > Anslut

    4. Klistra in anslutningssträngen som du kopierade i steg 1 och klicka Anslut

    5. Detta öppnar Service Bus namnområdet.

    6. Välj Snapshot Manager i ämnet i namnområdet. Högerklicka på Snapshot Manager, välj "Ta emot meddelanden" > "granska" och klicka på OK.

    Om anslutningen lyckas visas [x] meddelanden som tagits emot i konsolens utdata. Om anslutningen inte lyckas visas ett meddelande om att anslutningen misslyckades.

    Lösning: Om det här testet misslyckas finns det ett anslutningsproblem mellan Azure Migrate och Service Bus. Engagera ditt lokala nätverksteam för att kontrollera dessa anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

  5. Anslutningsproblem mellan Azure Migrate och Azure Key Vault:

    Det här testet söker efter anslutningsproblem mellan Azure Migrate och Azure Key Vault. Den Key Vault används för att hantera Storage kontoåtkomst som används för replikering.

    Steg för att kontrollera anslutningen:

    1. Hämta Key Vault URI från listan över resurser i resursgruppen som motsvarar Azure Migrate Project.

    2. Öppna PowerShell i Azure Migrate och kör följande kommando:

    test-netconnection Key Vault URI -P 443

    Det här kommandot försöker upprätta en TCP-anslutning och returnerar utdata.

    1. I utdata kontrollerar du fältet "TcpTestSucceeded". Om värdet är "True" (Sant) finns det inget anslutningsproblem mellan Azure Migrate Appliance och Azure Key Vault. Om värdet är "False" uppstår ett anslutningsproblem.

    Lösning: Om det här testet misslyckas finns det ett anslutningsproblem mellan Azure Migrate och Azure Key Vault. Engagera ditt lokala nätverksteam för att kontrollera anslutningsproblem. Normalt kan det finnas vissa brandväggsinställningar som orsakar felen.

Jag påträffade ett fel vid försök att hämta ändrade block

Felmeddelande: "Jag påträffade ett fel vid försök att hämta ändringsblock"

Den agentlösa replikeringsmetoden använder VMwares ändrade blockspårningsteknik (CBT) för att replikera data till Azure. MED CBT kan servermigreringsverktyget endast spåra och replikera de block som har ändrats sedan den senaste replikeringscykeln. Det här felet uppstår om spårning av ändrade block för en virtuell dator som replikeras återställs eller om spårningsfilen för ändrade block är skadad.

Det här felet kan lösas på följande två sätt:

  • Om du hade valt "Reparera replikering automatiskt" genom att välja "Ja" när du utlöste replikeringen av den virtuella datorn försöker verktyget reparera den åt dig. Högerklicka på den virtuella datorn och välj "Reparera replikering".
  • Om du inte valde "Reparera replikering automatiskt" eller om steget ovan inte fungerade för dig stoppar du replikeringen för den virtuella datorn, återställer spårning av ändrade block på den virtuella datorn och konfigurerar sedan om replikeringen.

Ett sådant känt problem som kan orsaka en CBT-återställning av den virtuella datorn på VMware vSphere 5.5 beskrivs i VMware KB 1020128: Spårning av ändrade block återställs efter en storage vMotion-åtgärd i vSphere 5.x . Om du använder VMware vSphere 5.5 kontrollerar du att du har uppdateringarna som beskrivs i den här KB-artikeln.

Du kan också återställa spårning av ändrade VMware-block på en virtuell dator med hjälp av VMware PowerCLI.

Ett internt fel inträffade

Ibland kan du få ett fel som uppstår på grund av problem i VMware-miljön/API:et. Vi har identifierat följande uppsättning fel som VMware-miljörelaterade fel. De här felen har ett fast format.

Felmeddelande: Ett internt fel inträffade. [Felmeddelande]

Exempel: Felmeddelande: Ett internt fel inträffade. [En ogiltig konfiguration av ögonblicksbild har identifierats].

I följande avsnitt visas några av de vanliga VMware-felen och hur du kan åtgärda dem.

Felmeddelande: Ett internt fel inträffade. [Server nekad anslutning]

Problemet är ett känt VMware-problem som uppstår i VDDK 6.7. Du måste stoppa gatewaytjänsten som körs i Azure Migrate installationen, ladda ned en uppdatering från VMware KBoch starta om gatewaytjänsten.

Steg för att stoppa gatewaytjänsten:

  1. Tryck Windows + R, öppna services.msc. Klicka på "Microsoft Azure Gateway Service" och stoppa den.
  2. Du kan också öppna kommandotolken eller PowerShell och göra: Net Stop asrgwy. Se till att du väntar tills du får meddelandet att tjänsten inte längre körs.

Steg för att starta gatewaytjänsten:

  1. Tryck Windows + R, öppna services.msc. Högerklicka på "Microsoft Azure Gateway Service" och starta den.
  2. Du kan också öppna kommandotolken eller PowerShell och göra: Net Start asrgwy.

Felmeddelande: Ett internt fel inträffade. ['En ogiltig ögonblicksbildskonfiguration har identifierats.']

Om du har en virtuell dator med flera diskar kan du stöta på det här felet om du tar bort en disk från den virtuella datorn. Information om hur du åtgärdar det här problemet finns i stegen i den här VMware-artikeln.

Felmeddelande: Ett internt fel inträffade. [Generera ögonblicksbild fryst]

Det här problemet uppstår när genereringen av ögonblicksbilder slutar svara. När det här problemet uppstår kan du se att åtgärden för att skapa ögonblicksbild stoppas med 95 % eller 99 %. Se denna VMware KB för att lösa det här problemet.

Felmeddelande: Ett internt fel inträffade. [Det gick inte att konsolidera diskarna på den virtuella datorn [Reasons]]

När vi konsoliderar diskar i slutet av replikeringscykeln misslyckas åtgärden. Följ anvisningarna i VMware KB genom att välja lämplig orsak för att lösa problemet.

Följande fel uppstår när åtgärder relaterade till VMware-ögonblicksbilder – skapa, ta bort eller konsolidera diskar misslyckas. Följ riktlinjerna i nästa avsnitt för att åtgärda felen:

Felmeddelande: Ett internt fel inträffade. [En annan uppgift pågår redan]

Det här problemet uppstår när det finns motstridiga uppgifter för virtuella datorer som körs i bakgrunden, eller när en aktivitet inom vCenter Server tar för lång tid. Följ den lösning som anges i följande VMware KB.

Felmeddelande: Ett internt fel inträffade. [Åtgärden tillåts inte i det aktuella tillståndet]

Det här problemet uppstår när vCenter Server hanteringsagenter slutar fungera. Lös problemet genom att gå till lösningen i följande VMware KB.

Felmeddelande: Ett internt fel inträffade. [Storleken på ögonblicksbilddisken är ogiltig]

Det här är ett känt VMware-problem där diskstorleken som anges av ögonblicksbilden blir noll. Följ den lösning som anges i VMware KB.

Felmeddelande: Ett internt fel inträffade. [Minnesallokeringen misslyckades. Slut på minne.]

Detta händer när NFC-värdbufferten är slut på minne. För att lösa det här problemet måste du flytta den virtuella datorn (compute vMotion) till en annan värd, som har kostnadsfria resurser.

Felmeddelande: Ett internt fel inträffade. [Filen är större än den maximala filstorlek som stöds (1012384)]

Detta inträffar när filstorleken är större än den största filstorleken som stöds när ögonblicksbilden skapas. Följ den lösning som anges i VMware KB

Felmeddelande: Ett internt fel inträffade. [Det går inte att ansluta till värden (1004109)]

Detta inträffar när ESXi-värdar inte kan ansluta till nätverket. Följ den lösning som anges i VMware KB.

Felmeddelande: Ett fel uppstod när ögonblicksbilden sparades: Felkod för ogiltig ändringsspårare

Det här felet uppstår när det är problem med det underliggande datalager där ögonblicksbilden lagras. Följ den lösning som anges i VMware KB.

Felmeddelande: Ett fel uppstod när en ögonblicksbild skulle tas: Det gick inte att öppna ögonblicksbildfilen.

Det här felet uppstår när storleken på ögonblicksbildfilen som skapas är större än det tillgängliga lediga utrymmet i datalagringen där den virtuella datorn finns. Följ den lösning som ges i det här dokumentet.

Replikeringscykeln misslyckades

Fel-ID: 181008

Felmeddelande: VM: "VMName". Fel: Inga disksnapshots hittades för replikering av ögonblicksbilder med ögonblicksbilds-ID: 'SnapshotID'.

Möjliga orsaker:

Möjliga orsaker är:

  1. Sökvägen till en eller flera inkluderade diskar har ändrats på grund Storage VMotion.
  2. En eller flera inkluderade diskar är inte längre anslutna till den virtuella datorn.

Rekommendation:

Följande rekommendationer ges

  1. Återställ de inkluderade diskarna till den ursprungliga sökvägen med storage vMotion och inaktivera sedan storage vmotion.
  2. Inaktivera Storage VMotion om det är aktiverat, stoppa replikeringen på den virtuella datorn och replikera den virtuella datorn igen. Kontakta supporten om problemet kvarstår.

Nästa steg

Fortsätt replikeringen av den virtuella datorn och utför testmigreringen.