Att göra externa snapshots med virsh är relativt enkelt även om man måste göra en del manuellt arbete. Att vi måste göra en del manuellt beror på att virsh för tillfället inte har fullt stöd för externa snapshots. Interna snapshots fungerar (med filformatet qcow2) utan problem direkt i virsh. Men eftersom jag har många virtuella maskiner i raw-format använder jag istället externa snapshots.

Jag tycker dessutom personligen bättre om externa snapshots av den anledningen att de är just externa. Jag kan kopiera, flytta, radera och göra backup av mina snapshots, helt utan att blanda in originalfilen. En annan positiv sak med externa snapshots är att de går att genomföra live medan den virtuella maskinen körs.

Skapa en snapshot

När jag ska uppdatera systemet i en virtuell maskin till nyare utgåvor brukar jag göra som följer (fall i fall något går snett):

1. Jag gör en extern snapshot av den virtuella maskinen i fråga innan jag påbörjar arbetet med uppdateringar etc:

   virsh snapshot-create-as --domain server57 before-upgrade \
   --diskspec sda,file=/data/vm-backups/server57-snapshot-before-upgrade.qcow2 \
   --disk-only --atomic --no-metadata
   

   • --domain server57 specificerar den virtuella maskinen vi vill göra snapshoten på.

   • before-upgrade är bara ett internt namn på snapshoten.

   • --diskspec sda,file=/data/vm-backups/server57-snapshot-before-upgrade.qcow2 är den kompletta sökvägen där jag vill att snapshot-filen ska lagras.

   • --disk-only innebär att snapshoten enbart kommer att avse själva disken, inte den virtuella maskinens status i sig.

   • --atomic ser till att vi antingen får en helt fungerande snapshot, eller ingen snapshot alls. Det vill säga vi minskar risken att få en trasig snapshot. Antingen fungerar det till 100% eller så fungerar det inte alls.

     ANNONS FÖR VÅRA EGNA BÖCKER

   • --no-metadata innebär att snapshoten inte registreras i virsh/KVM/QEMU. Detta gör jag för att jag kommer att radera snapshoten manuellt vid ett senare tillfälle. Utan --no-metadata hade snapshoten då legat kvar i virsh’s lista över snapshots. Om jag tar många snapshots hade listan då snabbt blivit lång, och totalt onödig eftersom filerna är borttagna.

2. Jag kontrollerar så att den aktuella backing-enheten (hårddisk-filen) är min nya snapshot, så att jag inte av misstag kör på originaldisken.

    virsh domblklist server57
   

3. Jag genomför uppdatering eller vad det nu är som jag ska göra som är riskabelt.

Slå ihop snapshoten ifall allt gick vägen

Om allt har gått vägen så gör jag en block commit vilket innebär att man slår ihop data i snapshoten med originaldisken.

virsh blockcommit server57 sda --active --verbose --pivot

• sda är för SCSI & SATA backends. Använder du istället VirtIO ska du använda vda här.

• --active anger att commiten sker live.

• --verbose visar information om förloppet och om något skulle gå snett.

• --pivot gör så att systemet återgår till originaldisken efter att commiten är klar.

Nu är jag tillbaks på originaldisken igen, och alla ändraring som skedde medan vi använde snapshoten har blivit commitade till originaldisken. Nu kan jag manuellt radera snapshoten, den fyller inte längre någon funktion. Eftersom jag angav --no-metadata så kommer den inte ligga kvar i listan över snapshots om jag kör virsh snapshot-list server57

Ta bort snapshoten om något inte gick vägen

Om något däremot inte gick vägen, och jag behöver återgå till originaldisken så ändrar jag bara tillbaks till den. Jag börjar med att stänga av den virtuella maskinen. Därefter editerar XML-filen med kommandot:

virsh edit server57

Det jag behöver ändra i filen är sökvägen till orginaldisken och typ av disk, exempelvis raw om det är detta som originaldisk är.

Starta upp maskinen igen med:

virsh start server57

Nu är jag tillbaks till hur saker och ting var innan jag påbörjade uppdatering eller de ändringar som inte fungerade som tänkt. Mycket smidigt!