Under en migrering fra Hyper-V til Azure skulle replikering aktiveres for en virtuell maskin.

Målet var enkelt: få replikeringen i gang slik at maskinen senere kunne testmigreres og flyttes til Azure.

Men replikeringen feilet.

Feilen var ikke tilfeldig. Den kom hver gang. Azure rapporterte at beskyttelse ikke kunne aktiveres for den virtuelle maskinen, og Hyper-V svarte med en generisk feil:

Hyper-V failed to enable replication for virtual machine: Unspecified error (0x80004005).

Det er en type feilmelding som sier at noe er galt, men ikke hva som er galt. Den peker på stedet der prosessen stopper, men ikke nødvendigvis på årsaken.

Og i denne saken lå årsaken ikke i selve VM-en.

Den lå på Hyper-V-verten.

Første spor: agenten oppførte seg ikke som forventet

Vi startet med å forsøke å installere nødvendig agent på Hyper-V-verten. Forventningen var at dette skulle være en vanlig installasjon.

Men da installereren ble kjørt, oppførte den seg som om den skulle oppdatere en eksisterende installasjon, ikke installere agenten på nytt.

Det var første tegn på at serveren ikke var så ren som den så ut til.

Agenten var allerede fjernet fra Programs and Features. Relevante registernøkler var eksportert, og serveren var startet på nytt.

Likevel var det fortsatt spor igjen.

I Services var det fortsatt rester av en tidligere agentinstallasjon. I registry lå det også igjen konfigurasjon knyttet til tidligere backupregistrering.

Med andre ord: agenten var fjernet nok til at den så avinstallert ut fra ett sted, men ikke nok til at systemet faktisk var rent.

Det er litt som å fjerne navneskiltet fra en dør, men la låsen, nøkkelen og adgangslisten stå igjen. Fra utsiden ser rommet tomt ut. Men bygget behandler det fortsatt som i bruk.

Viktig avklaring før opprydding

Før full opprydding måtte det avklares om eksisterende backupkonfigurasjon måtte bevares.

Det var et viktig punkt. Hvis agenten hadde vært brukt aktivt for riktig backup, måtte man sikret at nødvendig konfigurasjon og passphrase var ivaretatt før man ryddet bort agenten. Uten dette kunne det blitt vanskeligere å gjenoppta eller gjenopprette backup senere.

I dette tilfellet ble det avklart at eksisterende backupoppsett ikke skulle videreføres som det var. Backupen var ikke konfigurert mot riktig datagrunnlag, og løsningen skulle derfor settes opp på nytt etter at migreringsarbeidet var ferdig.

Det gjorde beslutningen enklere. Det var ikke nødvendig å bevare et backupoppsett som uansett ikke skulle brukes videre i samme form.

Oppryddingen

Neste steg var å rydde bort rester av den tidligere agentinstallasjonen.

Det ble kjørt opprydding for å fjerne gjenværende komponenter. Etterpå ble det kontrollert at tjenesten ikke lenger var installert, og at relevante registernøkler ikke lenger lå igjen.

Dette var vendepunktet.

Før oppryddingen hadde serveren vært i en mellomtilstand. Agenten var ikke fullt installert, men heller ikke fullt fjernet. Den var borte nok til å forvirre installasjonen, men til stede nok til å påvirke systemet.

Etter oppryddingen var tilstanden tydeligere.

Da riktig agent ble installert på nytt, fullførte installasjonen uten samme problem.

Replikeringen startet

Etter at oppryddingen var gjennomført, ble den feilede jobben for å aktivere replikering startet på nytt fra Azure Portal.

Denne gangen gikk jobben gjennom.

Initial replication startet og begynte å prosessere som forventet. Når initial replication er fullført, kan man gå videre med test migration eller faktisk migrering av VM-en til Azure.

Det er verdt å merke seg hvor lite som endret seg på overflaten.

Samme Hyper-V-miljø. Samme virtuelle maskin. Samme migreringsmål.

Men én viktig ting var annerledes: Hyper-V-verten var ikke lenger i en konfliktfylt tilstand med rester av feil agent- eller backupkonfigurasjon.

Den egentlige årsaken

Den viktigste læringen fra saken var ikke bare at en agent måtte ryddes opp.

Den viktigste læringen var at backup og migrering/ASR ikke skal blandes på samme Hyper-V-vert på denne måten.

Backupagenter og komponenter brukt for Azure Site Recovery eller migrering har overlappende roller på vertsnivå. De jobber tett på Hyper-V, endringssporing, replikering og beskyttelse av virtuelle maskiner.

Fra et driftsståsted kan det virke logisk å ha begge deler på samme server. Backup handler om å beskytte data. Migrering handler også om å flytte og beskytte data underveis. På papiret ser de ut som to deler av samme sikkerhetsarbeid.

Men teknisk er de ikke bare to uavhengige verktøy som står ved siden av hverandre.

De griper inn i samme lag.

Det blir som å ha to personer som begge tror de har ansvaret for samme ratt. Begge kan ha gode intensjoner. Begge kan gjøre en viktig jobb hver for seg. Men hvis begge skal styre samtidig, får du ikke bedre kontroll. Du får konflikt.

I denne saken var konklusjonen tydelig: backupagent og ASR-/migreringskomponenter skal ikke kjøres sammen på samme Hyper-V-vert dersom kombinasjonen ikke er støttet. Det kan føre til feil når replikering skal aktiveres.

Hvorfor feilen var vanskelig å lese

Feilen som ble vist var generisk. Den beskrev at replikering ikke kunne aktiveres, og at Hyper-V returnerte en uspesifisert feil.

Slike feilmeldinger kan fort sende feilsøkingen i feil retning. Man begynner gjerne med VM-en, nettverk, tilgang, disk, tjenestestatus eller portaljobben.

Det er naturlig, fordi det er der feilen vises.

Men feilen var ikke nødvendigvis der problemet startet.

I denne saken var VM-en mer som passasjeren som ikke får gå om bord i flyet. Problemet var ikke passasjeren. Problemet var at kontrollsystemet ved gaten hadde to motstridende instrukser.

Det samme gjaldt her. VM-en kunne ikke replikeres fordi verten ikke var i en støttet og ryddig tilstand for migreringsjobben.

Hva vi tok med oss videre

Det første læringspunktet er at «avinstallert» ikke alltid betyr «fjernet». En agent kan være borte fra Programs and Features, men fortsatt ligge igjen som tjeneste, registry-konfigurasjon eller tidligere registreringsinformasjon.

Det andre læringspunktet er at Hyper-V-verten må behandles som en aktiv del av migreringen. Den er ikke bare en plattform VM-en kjører på. Det som er installert på verten, kan direkte påvirke om replikering fungerer.

Det tredje læringspunktet er at backup og migrering ikke bør blandes ukritisk på samme Hyper-V-vert. Selv om begge handler om beskyttelse, bruker de mekanismer som kan komme i konflikt.

Det fjerde læringspunktet er at generiske feilmeldinger ofte viser symptomet, ikke årsaken. Her sa feilen at Hyper-V ikke kunne aktivere replikering. Den sa ikke tydelig at verten hadde en ikke-støttet agent- eller backuprelatert tilstand.

Avslutning

Denne saken var ikke komplisert fordi løsningen var vanskelig.

Den var komplisert fordi årsaken lå ett lag under der feilen først viste seg.

På overflaten så det ut som en replikeringsfeil for én virtuell maskin. I praksis handlet det om Hyper-V-verten og en agenttilstand som ikke var kompatibel med migreringsløpet.

Da gamle agentrester ble fjernet, riktig komponent ble installert, og backupkonflikten var ryddet bort, startet replikeringen som forventet.

Det er ofte slik med infrastrukturfeil. Det som feiler, er ikke alltid det som er feil.

I dette tilfellet var den virtuelle maskinen bare stedet hvor problemet ble synlig.

Den faktiske årsaken lå på verten.

Microsoft-referanser