Azure-naar-Azure-VM-replicatiefouten oplossen

Artikel
03/07/2024

In dit artikel wordt beschreven hoe u veelvoorkomende fouten in Azure Site Recovery kunt oplossen tijdens replicatie en herstel van virtuele Azure-machines (VM's ) van de ene regio naar de andere. Zie de ondersteuningsmatrix voor het repliceren van Virtuele Azure-machines voor meer informatie over ondersteunde configuraties.

Problemen met azure-resourcequota (foutcode 150097)

Zorg ervoor dat uw abonnement is ingeschakeld voor het maken van Azure-VM's in de doelregio die u wilt gebruiken als noodherstelregio (DR). Uw abonnement heeft voldoende quotum nodig om VM's van de benodigde grootten te maken. Standaard kiest Site Recovery een doel-VM-grootte die gelijk is aan de grootte van de bron-VM. Als de overeenkomende grootte niet beschikbaar is, kiest Site Recovery automatisch de dichtstbijzijnde beschikbare grootte.

Als er geen grootte is die ondersteuning biedt voor de configuratie van de bron-VM, wordt het volgende bericht weergegeven:

Replication couldn't be enabled for the virtual machine <VmName>.

Mogelijke oorzaken

Uw abonnements-id is niet ingeschakeld voor het maken van VM's in de doelregiolocatie.
Uw abonnements-id is niet ingeschakeld of heeft onvoldoende quotum om specifieke VM-grootten te maken in de doelregiolocatie.
Er is geen geschikte doel-VM-grootte gevonden die overeenkomt met het aantal netwerkinterfacekaarten (NIC) van de bron-VM (2), voor de abonnements-id in de doelregiolocatie.

Het probleem oplossen

Neem contact op met de factureringsondersteuning van Azure om uw abonnement in staat te stellen VM's te maken van de vereiste grootten op de doellocatie. Voer vervolgens de mislukte bewerking opnieuw uit.

Als de doellocatie een capaciteitsbeperking heeft, schakelt u replicatie naar die locatie uit. Schakel vervolgens replicatie in naar een andere locatie waar uw abonnement voldoende quotum heeft om VM's met de vereiste grootten te maken.

Vertrouwde basiscertificaten (foutcode 151066)

Als niet alle meest recente vertrouwde basiscertificaten aanwezig zijn op de virtuele machine, kan uw taak om replicatie voor Site Recovery in te schakelen mislukken. Verificatie en autorisatie van Site Recovery-service-aanroepen van de VIRTUELE machine mislukken zonder deze certificaten.

Als de inschakeling van de replicatietaak mislukt, wordt het volgende bericht weergegeven:

Site Recovery configuration failed.

Mogelijke oorzaak

De vertrouwde basiscertificaten die vereist zijn voor autorisatie en verificatie, zijn niet aanwezig op de virtuele machine.

Het probleem oplossen

Windows

Installeer voor een VIRTUELE machine waarop het Windows-besturingssysteem wordt uitgevoerd de meest recente Windows-updates, zodat alle vertrouwde basiscertificaten aanwezig zijn op de VIRTUELE machine. Volg het gebruikelijke proces voor Windows-updatebeheer of certificaatupdatebeheer in uw organisatie om de meest recente basiscertificaten en de bijgewerkte certificaatintrekkingslijst op de VM's op te halen.

Als u zich in een niet-verbonden omgeving bevindt, volgt u het standaardproces voor Windows-updates in uw organisatie om de certificaten op te halen.
Als de vereiste certificaten niet aanwezig zijn op de virtuele machine, mislukken de aanroepen naar de Site Recovery-service om veiligheidsredenen.

Als u wilt controleren of het probleem is opgelost, gaat u naar login.microsoftonline.com een browser in uw VIRTUELE machine.

Zie Vertrouwde basiscertificaten en niet-toegestane certificaten configureren voor meer informatie.

Linux

Volg de richtlijnen van de distributeur van uw Linux-besturingssysteemversie om de meest recente vertrouwde basiscertificaten en de meest recente certificaatintrekkingslijst op de VIRTUELE machine op te halen.

Omdat SUSE Linux symbolische koppelingen of symlinks gebruikt om een certificaatlijst te onderhouden, voert u de volgende stappen uit:

Meld u aan als hoofdgebruiker. Het hash-symbool (#) is de standaardopdrachtprompt.
Voer deze opdracht uit om de map te wijzigen:

cd /etc/ssl/certs
Controleer of het Symantec-basis-CA-certificaat aanwezig is:

ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
- Als het Symantec-basis-CA-certificaat niet wordt gevonden, voert u de volgende opdracht uit om het bestand te downloaden. Controleer op eventuele fouten en volg de aanbevolen acties voor netwerkfouten.
  
  wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Controleer of het Baltimore-basis-CA-certificaat aanwezig is:

ls Baltimore_CyberTrust_Root.pem
- Als het Baltimore-basis-CA-certificaat niet wordt gevonden, voert u deze opdracht uit om het certificaat te downloaden:
  
  wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem
Controleer of het DigiCert_Global_Root_CA certificaat aanwezig is:

ls DigiCert_Global_Root_CA.pem
- Als de DigiCert_Global_Root_CA niet wordt gevonden, voert u de volgende opdrachten uit om het certificaat te downloaden:
```
wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt

openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
```
Als u de hashes van het certificaatonderwerp voor de zojuist gedownloade certificaten wilt bijwerken, voert u het rehash-script uit:

c_rehash

Voer de volgende opdrachten uit om te controleren of de onderwerp-hashes als symlinks zijn gemaakt voor de certificaten:

ls -l | grep Baltimore

lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem

-rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem

ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5

-rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

ls -l | grep DigiCert_Global_Root

lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem

-rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem

Maak een kopie van het bestand VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem met bestandsnaam b204d74a.0:

cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0
Maak een kopie van het bestand Baltimore_CyberTrust_Root.pem met bestandsnaam 653b494a.0:

cp Baltimore_CyberTrust_Root.pem 653b494a.0
Maak een kopie van het bestand DigiCert_Global_Root_CA.pem met bestandsnaam 3513523f.0:

cp DigiCert_Global_Root_CA.pem 3513523f.0

Controleer of de bestanden aanwezig zijn:

ls -l 653b494a.0 b204d74a.0 3513523f.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0

-rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0

-rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0

Uitgaande URL's of IP-bereiken (foutcode 151037 of 151072)

Replicatie van Site Recovery werkt alleen als uitgaande connectiviteit met specifieke URL's vereist is vanaf de VIRTUELE machine. Als uw VM zich achter een firewall bevindt of NSG-regels (netwerkbeveiligingsgroep) gebruikt om uitgaande connectiviteit te beheren, kunt u een van deze problemen ondervinden. Hoewel we uitgaande toegang via URL's blijven ondersteunen, wordt het gebruik van een acceptatielijst met IP-bereiken niet meer ondersteund.

Mogelijke oorzaken

Er kan geen verbinding worden gemaakt met Site Recovery-eindpunten vanwege een DNS-omzettingsfout (Domain Name System).
Dit probleem komt vaker voor tijdens het opnieuw beveiligen wanneer u een failover van de virtuele machine hebt uitgevoerd, maar de DNS-server niet bereikbaar is vanuit de regio herstel na noodgevallen .

Het probleem oplossen

Als u aangepaste DNS gebruikt, moet u ervoor zorgen dat de DNS-server toegankelijk is vanuit de regio voor herstel na noodgevallen.

Controleren of de VIRTUELE machine gebruikmaakt van een aangepaste DNS-instelling:

Open virtuele machines en selecteer de virtuele machine.
Navigeer naar de VM-instellingen en selecteer Netwerken.
Selecteer in Virtueel netwerk/subnet de koppeling om de resourcepagina van het virtuele netwerk te openen.
Ga naar Instellingen en selecteer DNS-servers.

Probeer toegang te krijgen tot de DNS-server vanaf de virtuele machine. Als de DNS-server niet toegankelijk is, maakt u deze toegankelijk door een failover van de DNS-server uit te voeren of door de siteregel tussen het DR-netwerk en DNS te maken.

Notitie

Als u privé-eindpunten gebruikt, moet u ervoor zorgen dat de VIRTUELE machines de privé-DNS-records kunnen oplossen.

com-error.

Probleem 2: Site Recovery-configuratie is mislukt (151196)

Mogelijke oorzaak

Er kan geen verbinding worden gemaakt met Microsoft 365-verificatie- en identiteits-IP4-eindpunten.

Het probleem oplossen

Azure Site Recovery vereist toegang tot IP-bereiken van Microsoft 365 voor verificatie. Als u NSG-regels (NSG) (Azure Network Security Group) gebruikt om de uitgaande netwerkconnectiviteit op de VM te beheren, moet u ervoor zorgen dat u de NSG-regel op basis van de Microsoft Entra-servicetag gebruikt om toegang tot Microsoft Entra ID toe te staan. We bieden geen ondersteuning meer voor NSG-regels op basis van IP-adressen.

Probleem 3: Site Recovery-configuratie is mislukt (151197)

Mogelijke oorzaak

Er kan geen verbinding worden gemaakt met Azure Site Recovery-service-eindpunten.

Het probleem oplossen

Als u NSG-regels (Azure Network Security Group) gebruikt om de uitgaande netwerkconnectiviteit op de VM te beheren, moet u ervoor zorgen dat u servicetags gebruikt. We bieden geen ondersteuning meer voor het gebruik van een acceptatielijst met IP-adressen via NSG's voor Azure Site Recovery.

Probleem 4: replicatie mislukt wanneer netwerkverkeer gebruikmaakt van een on-premises proxyserver (151072)

Mogelijke oorzaak

De aangepaste proxyinstellingen zijn ongeldig en de Mobility-service agent heeft de proxy-instellingen niet automatisch gedetecteerd vanuit Internet Explorer.

Het probleem oplossen

De Mobility-service-agent detecteert de proxy-instellingen van Internet Explorer in Windows en /etc/environment linux.
Als u liever alleen proxy instelt voor de Mobility-service, kunt u de proxygegevens opgeven in ProxyInfo.conf op:
- Linux: /usr/local/InMage/config/
- Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config
ProxyInfo.conf moet de proxy-instellingen hebben in de volgende INI-indeling.
```
[proxy]
Address=http://1.2.3.4
Port=567
```

Notitie

De Mobility-service-agent ondersteunt alleen niet-geverifieerde proxy's.

Meer informatie

Als u de vereiste URL's of de vereiste IP-bereiken wilt opgeven, volgt u de richtlijnen in Over netwerken in Azure naar Azure-replicatie.

De schijf is niet gevonden in de VIRTUELE machine (foutcode 150039)

Er moet een nieuwe schijf worden geïnitialiseerd die aan de virtuele machine is gekoppeld. Als de schijf niet wordt gevonden, wordt het volgende bericht weergegeven:

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Mogelijke oorzaken

Er is een nieuwe gegevensschijf gekoppeld aan de virtuele machine, maar deze is niet geïnitialiseerd.
De gegevensschijf in de virtuele machine rapporteert niet correct de LUN-waarde (Logical Unit Number) waarop de schijf is gekoppeld aan de virtuele machine.

Het probleem oplossen

Zorg ervoor dat de gegevensschijven zijn geïnitialiseerd en voer de bewerking opnieuw uit.

Windows: Een nieuwe schijf koppelen en initialiseren.
Linux: Initialiseer een nieuwe gegevensschijf in Linux.

Neem contact op met de ondersteuning als het probleem zich blijft voordoen.

Er zijn meerdere schijven beschikbaar voor beveiliging (foutcode 153039)

Mogelijke oorzaken

Een of meer schijven zijn onlangs toegevoegd aan de virtuele machine na de beveiliging.
Een of meer schijven zijn geïnitialiseerd na de beveiliging van de virtuele machine.

Het probleem oplossen

Als u de replicatiestatus van de VIRTUELE machine weer in orde wilt maken, kunt u ervoor kiezen om de schijven te beveiligen of de waarschuwing te sluiten.

De schijven beveiligen

Ga naar Gerepliceerde items>VM-naamschijven.>
Selecteer de niet-beveiligde schijf en selecteer replicatie inschakelen:

De waarschuwing sluiten

Ga naar De naam van de VM met gerepliceerde items>.
Selecteer de waarschuwing in de sectie Overzicht en selecteer vervolgens OK.

VM verwijderd uit kluis voltooid met informatie (foutcode 150225)

Wanneer Site Recovery de virtuele machine beveiligt, worden er koppelingen gemaakt op de virtuele bronmachine. Wanneer u de beveiliging verwijdert of replicatie uitschakelt, verwijdert Site Recovery deze koppelingen als onderdeel van de opschoontaak. Als de virtuele machine een resourcevergrendeling heeft, wordt de opschoontaak voltooid met de informatie. De informatie geeft aan dat de virtuele machine is verwijderd uit de Recovery Services-kluis, maar dat sommige verouderde koppelingen niet kunnen worden opgeschoond op de bronmachine.

U kunt deze waarschuwing negeren als u deze virtuele machine nooit meer wilt beveiligen. Maar als u deze virtuele machine later moet beveiligen, volgt u de stappen in deze sectie om de koppelingen op te schonen.

Waarschuwing

Als u het opschonen niet uitvoert:

Wanneer u replicatie inschakelt via de Recovery Services-kluis, wordt de virtuele machine niet weergegeven.
Als u de virtuele machine probeert te beveiligen met behulp van herstel na noodgeval van virtuele machine>>, mislukt de bewerking met het bericht Replicatie niet vanwege de bestaande verouderde resourcekoppelingen op de VIRTUELE machine.

Het probleem oplossen

Notitie

Site Recovery verwijdert de virtuele bronmachine niet of beïnvloedt deze op geen enkele manier terwijl u deze stappen uitvoert.

Verwijder de vergrendeling van de VM of VM-resourcegroep. In de volgende installatiekopieën moet de resourcevergrendeling op de benoemde MoveDemo VM bijvoorbeeld worden verwijderd:
Download het script om een verouderde Site Recovery-configuratie te verwijderen.
Voer het script Opschonen-verlopen-asr-config-Azure-VM.ps1 uit. Geef de abonnements-id, vm-resourcegroep en vm-naam op als parameters.
Als u wordt gevraagd om Azure-referenties, geeft u deze op. Controleer vervolgens of het script zonder fouten wordt uitgevoerd.

Replicatie is niet ingeschakeld op vm's met verouderde resources (foutcode 150226)

Mogelijke oorzaken

De virtuele machine heeft een verouderde configuratie van eerdere Site Recovery-beveiliging.

Een verlopen configuratie kan optreden op een Azure-VM als u replicatie voor de Azure-VM hebt ingeschakeld met behulp van Site Recovery en vervolgens:

U hebt replicatie uitgeschakeld, maar de bron-VM had een resourcevergrendeling.
U hebt de Site Recovery-kluis verwijderd zonder de replicatie expliciet uit te schakelen op de virtuele machine.
U hebt de resourcegroep met de Site Recovery-kluis verwijderd zonder de replicatie expliciet uit te schakelen op de virtuele machine.

Het probleem oplossen

Notitie

Site Recovery verwijdert de virtuele bronmachine niet of beïnvloedt deze op geen enkele manier terwijl u deze stappen uitvoert.

Verwijder de vergrendeling van de VM of VM-resourcegroep. In de volgende installatiekopieën moet de resourcevergrendeling op de benoemde MoveDemo VM bijvoorbeeld worden verwijderd:
Download het script om een verouderde Site Recovery-configuratie te verwijderen.
Voer het script Opschonen-verlopen-asr-config-Azure-VM.ps1 uit. Geef de abonnements-id, vm-resourcegroep en vm-naam op als parameters.
Als u wordt gevraagd om Azure-referenties, geeft u deze op. Controleer vervolgens of het script zonder fouten wordt uitgevoerd.

Kan vm of resourcegroep niet selecteren in replicatietaak inschakelen

Probleem 1: de resourcegroep en de bron-VM bevinden zich op verschillende locaties

Site Recovery vereist momenteel dat de resourcegroep van de bronregio en virtuele machines zich op dezelfde locatie bevinden. Als dat niet zo is, kunt u de virtuele machine of resourcegroep niet vinden wanneer u probeert beveiliging toe te passen.

Als tijdelijke oplossing kunt u replicatie van de VIRTUELE machine inschakelen in plaats van de Recovery Services-kluis. Ga naar Herstel na noodgevallen van bron-VM-eigenschappen>> en schakel de replicatie in.

Probleem 2: De resourcegroep maakt geen deel uit van het geselecteerde abonnement

Mogelijk kunt u de resourcegroep niet vinden op het moment van beveiliging als de resourcegroep geen deel uitmaakt van het geselecteerde abonnement. Zorg ervoor dat de resourcegroep deel uitmaakt van het abonnement dat u gebruikt.

Probleem 3: Verouderde configuratie

Mogelijk ziet u niet de VM die u wilt inschakelen voor replicatie als er een verouderde Site Recovery-configuratie bestaat op de Azure-VM. Deze voorwaarde kan optreden als u replicatie voor de Azure-VM hebt ingeschakeld met behulp van Site Recovery en vervolgens:

U hebt de Site Recovery-kluis verwijderd zonder de replicatie expliciet uit te schakelen op de virtuele machine.
U hebt de resourcegroep met de Site Recovery-kluis verwijderd zonder de replicatie expliciet uit te schakelen op de virtuele machine.
U hebt replicatie uitgeschakeld, maar de bron-VM had een resourcevergrendeling.

Het probleem oplossen

Notitie

Zorg ervoor dat u de AzureRM.Resources module bijwerkt voordat u het script gebruikt dat in deze sectie wordt genoemd. Site Recovery verwijdert de virtuele bronmachine niet of beïnvloedt deze op geen enkele manier terwijl u deze stappen uitvoert.

Verwijder de vergrendeling, indien van toepassing, uit de VM- of VM-resourcegroep. In de volgende installatiekopieën moet de resourcevergrendeling op de benoemde MoveDemo VM bijvoorbeeld worden verwijderd:
Download het script om een verouderde Site Recovery-configuratie te verwijderen.
Voer het script Opschonen-verlopen-asr-config-Azure-VM.ps1 uit. Geef de abonnements-id, vm-resourcegroep en vm-naam op als parameters.
Als u wordt gevraagd om Azure-referenties, geeft u deze op. Controleer vervolgens of het script zonder fouten wordt uitgevoerd.

Kan geen VM selecteren voor beveiliging

Mogelijke oorzaak

Op de virtuele machine is een extensie geïnstalleerd met een mislukte of niet-reagerende status

Het probleem oplossen

Ga naar Instellingenextensies> voor virtuele machines>en controleer op extensies met de status Mislukt. Verwijder een mislukte extensie en probeer het vervolgens opnieuw om de virtuele machine te beveiligen.

De inrichtingsstatus van de VM is niet geldig (foutcode 150019)

Als u replicatie op de virtuele machine wilt inschakelen, moet de inrichtingsstatus zijn voltooid. Voer de volgende stappen uit om de inrichtingsstatus te controleren:

Selecteer resourceverkenner in Alle services in Azure Portal.
Vouw de lijst Met abonnementen uit en selecteer uw abonnement.
Vouw de lijst ResourceGroups uit en selecteer de resourcegroep van de virtuele machine.
Vouw de lijst Met resources uit en selecteer uw VIRTUELE machine.
Controleer het veld provisioningState in de exemplaarweergave aan de rechterkant.

Het probleem oplossen

Als de provisioningState is mislukt, neemt u contact op met de ondersteuning met details om problemen op te lossen.
Als de provisioningState wordt bijgewerkt, wordt er mogelijk een andere extensie geïmplementeerd. Controleer of er lopende bewerkingen op de virtuele machine zijn, wacht totdat deze zijn voltooid en voer de mislukte Site Recovery-taak opnieuw uit om replicatie in te schakelen.

Kan doel-VM niet selecteren

Probleem 1: VM is gekoppeld aan een netwerk dat al is toegewezen aan een doelnetwerk

Als de bron-VM deel uitmaakt van een virtueel netwerk en een andere virtuele machine van hetzelfde virtuele netwerk al is toegewezen aan een netwerk in de doelresourcegroep, is de vervolgkeuzelijst voor netwerkselectie standaard niet beschikbaar (wordt grijs weergegeven).

De lijst met netwerkselecties is niet beschikbaar.

Probleem 2: U hebt de virtuele machine eerder beveiligd en vervolgens de replicatie uitgeschakeld

Als u replicatie van een virtuele machine uitschakelt, wordt de netwerktoewijzing niet verwijderd. De toewijzing moet worden verwijderd uit de Recovery Services-kluis waar de VIRTUELE machine is beveiligd. Selecteer de Recovery Services-kluis en ga naar Site Recovery-infrastructuur>beheren>voor netwerktoewijzing van virtuele Azure-machines.>

Netwerktoewijzing verwijderen.

Het doelnetwerk dat is geconfigureerd tijdens de installatie van noodherstel, kan worden gewijzigd na de eerste installatie en nadat de virtuele machine is beveiligd. Als u netwerktoewijzing wilt wijzigen, selecteert u de netwerknaam:

Netwerktoewijzing wijzigen.

COM+ of VSS (foutcode 151025)

Wanneer de FOUT COM+ of Volume Shadow Copy Service (VSS) optreedt, wordt het volgende bericht weergegeven:

Site Recovery extension failed to install.

Mogelijke oorzaken

De COM+ System Application-service is uitgeschakeld.
De Volume Shadow Copy-service is uitgeschakeld.

Het probleem oplossen

Stel de COM+ System Application and Volume Shadow Copy Service in op de automatische of handmatige opstartmodus.

Open de Services-console in Windows.
Zorg ervoor dat de COM+-systeemtoepassing en volumeschaduwkopieservice niet zijn ingesteld op Uitgeschakeld als opstarttype.

Niet-ondersteunde grootte van beheerde schijven (foutcode 150172)

Wanneer deze fout optreedt, wordt het volgende bericht weergegeven:

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Mogelijke oorzaak

De schijf is kleiner dan de ondersteunde grootte van 1024 MB.

Het probleem oplossen

Zorg ervoor dat de schijfgrootte binnen het ondersteunde groottebereik valt en voer de bewerking opnieuw uit.

Beveiliging is niet ingeschakeld wanneer GRUB apparaatnaam gebruikt (foutcode 151126)

Mogelijke oorzaken

De Linux Grand Unified Bootloader -configuratiebestanden (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg of /etc/default/grub) kunnen de werkelijke apparaatnamen opgeven in plaats van UUID-waarden (Universally Unique Identifier) voor de root en resume parameters. Site Recovery vereist UUID's omdat apparaatnamen kunnen worden gewijzigd. Bij het opnieuw opstarten kan een VIRTUELE machine mogelijk niet dezelfde naam hebben bij een failover, wat tot problemen leidt.

De volgende voorbeelden zijn regels van GRUB-bestanden waarin apparaatnamen worden weergegeven in plaats van de vereiste UUID's:

Bestand /boot/grub2/grub.cfg:

linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts
Bestand: /boot/grub/menu.lst

kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Het probleem oplossen

Vervang elke apparaatnaam door de bijbehorende UUID:

Zoek de UUID van het apparaat door de opdracht blkid <device name>uit te voeren. Voorbeeld:

blkid /dev/sda1
/dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
blkid /dev/sda2
/dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"

Vervang de naam van het apparaat door de UUID, in de indelingen root=UUID=<UUID> en resume=UUID=<UUID>. Na vervanging ziet de lijn van /boot/grub/menu.lst er bijvoorbeeld uit als de volgende regel:

kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314
Probeer de beveiliging opnieuw uit te voeren.

Beveiliging is mislukt omdat GRUB-apparaat niet bestaat (foutcode 151124)

Mogelijke oorzaak

De GRUB-configuratiebestanden (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg of /etc/default/grub) kunnen de parameters rd.lvm.lv of rd_LVM_LVbevatten. Met deze parameters worden de LVM-apparaten (Logical Volume Manager) geïdentificeerd die tijdens het opstarten moeten worden gedetecteerd. Als deze LVM-apparaten niet bestaan, wordt het beveiligde systeem zelf niet opgestart en blijft het opstartproces hangen. Hetzelfde probleem wordt ook weergegeven met de failover-VM. Hier volgen enkele voorbeelden:

Bestand: /boot/grub2/grub.cfg op RHEL7:

linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8
Bestand: /etc/default/grub op RHEL7:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet
Bestand: /boot/grub/menu.lst op RHEL6:

kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

In elk voorbeeld moet GRUB twee LVM-apparaten detecteren met de namen root en swap van de volumegroep rootvg.

Het probleem oplossen

Als het LVM-apparaat niet bestaat, maakt u het of verwijdert u de bijbehorende parameters uit de GRUB-configuratiebestanden. Probeer vervolgens opnieuw om beveiliging in te schakelen.

Mobility-service update voltooid met waarschuwingen (foutcode 151083)

De Site Recovery-Mobility-service heeft veel onderdelen, waarvan een het filterstuurprogramma wordt genoemd. Het filterstuurprogramma wordt alleen in het systeemgeheugen geladen tijdens het opnieuw opstarten van het systeem. Wanneer een Mobility-service update filterstuurprogrammawijzigingen bevat, wordt de machine bijgewerkt, maar wordt er nog steeds een waarschuwing weergegeven dat sommige oplossingen opnieuw moeten worden opgestart. De waarschuwing wordt weergegeven omdat de fixes van het filterstuurprogramma alleen van kracht kunnen worden wanneer het nieuwe filterstuurprogramma wordt geladen, wat alleen gebeurt tijdens het opnieuw opstarten.

Notitie

Dit is slechts een waarschuwing. De bestaande replicatie blijft werken, zelfs nadat de nieuwe agent is bijgewerkt. U kunt ervoor kiezen om opnieuw op te starten wanneer u de voordelen van het nieuwe filterstuurprogramma wilt, maar het oude filterstuurprogramma blijft werken als u niet opnieuw opstart.

Afgezien van het filterstuurprogramma worden de voordelen van eventuele andere verbeteringen en oplossingen in de Mobility-service update van kracht zonder opnieuw opstarten.

Beveiliging niet ingeschakeld als de beheerde replicaschijf bestaat

Deze fout treedt op wanneer de beheerde replicaschijf al bestaat, zonder verwachte tags, in de doelresourcegroep.

Mogelijke oorzaak

Dit probleem kan optreden als de virtuele machine eerder is beveiligd en wanneer replicatie is uitgeschakeld, de replicaschijf niet is verwijderd.

Het probleem oplossen

Verwijder de replicaschijf die is geïdentificeerd in het foutbericht en voer de mislukte beveiligingstaak opnieuw uit.

Beveiliging inschakelen is mislukt omdat het installatieprogramma de hoofdschijf niet kan vinden (foutcode 151137)

Deze fout treedt op voor Linux-machines waarop de besturingssysteemschijf is versleuteld met behulp van Azure Disk Encryption (ADE). Dit is alleen een geldig probleem in agentversie 9.35.

Mogelijke oorzaken

Het installatieprogramma kan de hoofdschijf die als host fungeert voor het hoofdbestandssysteem niet vinden.

Het probleem oplossen

Voer de volgende stappen uit om dit probleem op te lossen.

Zoek de agent-bits onder de map /var/lib/waagent op RHEL-machines met behulp van de onderstaande opdracht:

# find /var/lib/ -name Micro\*.gz

Verwachte uitvoer:

/var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz
Maak een nieuwe map en wijzig de map in deze nieuwe map.
Pak het agentbestand uit dat u in de eerste stap hier hebt gevonden, met behulp van de onderstaande opdracht:

tar -xf <Tar Ball File>
Open het bestand prereq_check_installer.json en verwijder de volgende regels. Sla het bestand daarna op.
```
   {
      "CheckName": "SystemDiskAvailable",
      "CheckType": "MobilityService"
   },
```
Roep het installatieprogramma aan met behulp van de opdracht:

./install -d /usr/local/ASR -r MS -q -v Azure
Als het installatieprogramma slaagt, probeert u de replicatietaak opnieuw in te schakelen.

Problemen met tijdwijzigingen op gerepliceerde servers oplossen en afhandelen

Deze fout treedt op wanneer de tijd van de bronmachine naar voren gaat en vervolgens weer in korte tijd wordt verplaatst om de wijziging te corrigeren. U ziet de wijziging mogelijk niet omdat de tijd zeer snel wordt gecorrigeerd.

Oplossing: Wacht totdat de systeemtijd de scheve toekomstige tijd overschrijdt om dit probleem op te lossen. Een andere optie is om replicatie opnieuw uit te schakelen en in te schakelen, wat alleen haalbaar is voor het doorsturen van replicatie (gegevens die worden gerepliceerd van primaire naar secundaire regio) en is niet van toepassing op omgekeerde replicatie (gegevens die worden gerepliceerd van secundaire naar primaire regio).

Volgende stappen

Virtuele Azure-machines repliceren naar een andere Azure-regio.

Delen via

Azure-naar-Azure-VM-replicatiefouten oplossen

Problemen met azure-resourcequota (foutcode 150097)

Mogelijke oorzaken

Het probleem oplossen

Vertrouwde basiscertificaten (foutcode 151066)

Mogelijke oorzaak

Het probleem oplossen

Windows

Linux

Uitgaande URL's of IP-bereiken (foutcode 151037 of 151072)

Mogelijke oorzaken

Het probleem oplossen

Probleem 2: Site Recovery-configuratie is mislukt (151196)

Mogelijke oorzaak

Het probleem oplossen

Probleem 3: Site Recovery-configuratie is mislukt (151197)

Mogelijke oorzaak

Het probleem oplossen

Probleem 4: replicatie mislukt wanneer netwerkverkeer gebruikmaakt van een on-premises proxyserver (151072)

Mogelijke oorzaak

Het probleem oplossen

Meer informatie

De schijf is niet gevonden in de VIRTUELE machine (foutcode 150039)

Mogelijke oorzaken

Het probleem oplossen

Er zijn meerdere schijven beschikbaar voor beveiliging (foutcode 153039)

Mogelijke oorzaken

Het probleem oplossen

De schijven beveiligen

De waarschuwing sluiten

VM verwijderd uit kluis voltooid met informatie (foutcode 150225)

Het probleem oplossen

Replicatie is niet ingeschakeld op vm's met verouderde resources (foutcode 150226)

Mogelijke oorzaken

Het probleem oplossen

Kan vm of resourcegroep niet selecteren in replicatietaak inschakelen

Probleem 1: de resourcegroep en de bron-VM bevinden zich op verschillende locaties

Probleem 2: De resourcegroep maakt geen deel uit van het geselecteerde abonnement

Probleem 3: Verouderde configuratie

Het probleem oplossen

Kan geen VM selecteren voor beveiliging

Mogelijke oorzaak

Het probleem oplossen

De inrichtingsstatus van de VM is niet geldig (foutcode 150019)

Het probleem oplossen

Kan doel-VM niet selecteren

Probleem 1: VM is gekoppeld aan een netwerk dat al is toegewezen aan een doelnetwerk

Probleem 2: U hebt de virtuele machine eerder beveiligd en vervolgens de replicatie uitgeschakeld

COM+ of VSS (foutcode 151025)

Mogelijke oorzaken

Het probleem oplossen

Niet-ondersteunde grootte van beheerde schijven (foutcode 150172)

Mogelijke oorzaak

Het probleem oplossen

Beveiliging is niet ingeschakeld wanneer GRUB apparaatnaam gebruikt (foutcode 151126)

Mogelijke oorzaken

Het probleem oplossen

Beveiliging is mislukt omdat GRUB-apparaat niet bestaat (foutcode 151124)

Mogelijke oorzaak

Het probleem oplossen

Mobility-service update voltooid met waarschuwingen (foutcode 151083)

Beveiliging niet ingeschakeld als de beheerde replicaschijf bestaat

Mogelijke oorzaak

Het probleem oplossen

Beveiliging inschakelen is mislukt omdat het installatieprogramma de hoofdschijf niet kan vinden (foutcode 151137)

Mogelijke oorzaken

Het probleem oplossen

Problemen met tijdwijzigingen op gerepliceerde servers oplossen en afhandelen

Volgende stappen

Feedback

Aanvullende resources