Difference between revisions of "stoney conductor: VM Backup"

From stoney cloud
Jump to: navigation, search
[unchecked revision][unchecked revision]
(Snapshot)
(Snapshot)
Line 24: Line 24:
 
# Save the VMs XML description
 
# Save the VMs XML description
 
#* Save the current XML description of VM <code>vm-001</code> to a file at the retain location: <syntaxhighlight lang="bash">virsh dumpxml vm-001 > /path/to/retain/vm-001.xml</syntaxhighlight>
 
#* Save the current XML description of VM <code>vm-001</code> to a file at the retain location: <syntaxhighlight lang="bash">virsh dumpxml vm-001 > /path/to/retain/vm-001.xml</syntaxhighlight>
 +
# Save the backend entry
 +
#* There is no generic command to save the backend entry (since the command depends on the backend). Important here is, that the backend entry of the VM <code>vm-001</code> is saved to the retain location: <code>/path/to/retain/vm-001.backend</code>
 
# Restore the VMs <code>vm-001</code> from its saved state (this will also start the VM): <syntaxhighlight lang="bash">virsh restore /path/to/ram-disk/vm-001.state</syntaxhighlight>
 
# Restore the VMs <code>vm-001</code> from its saved state (this will also start the VM): <syntaxhighlight lang="bash">virsh restore /path/to/ram-disk/vm-001.state</syntaxhighlight>
 
#* '''Please note:''' After this operation the VM <code>vm-001</code> is running again (continues where we stopped it), and we have a consistent backup for the VM <code>vm-001</code>:
 
#* '''Please note:''' After this operation the VM <code>vm-001</code> is running again (continues where we stopped it), and we have a consistent backup for the VM <code>vm-001</code>:
 
#** The file <code>/path/to/ram-disk/vm-001.state</code> contains the CPU and memory state of VM <code>vm-001</code> at time T<sub>1</sub>
 
#** The file <code>/path/to/ram-disk/vm-001.state</code> contains the CPU and memory state of VM <code>vm-001</code> at time T<sub>1</sub>
 
#** The file <code>/path/to/retain/vm-001.qcow2</code> contains the disk state of VM <code>vm-001</code> at time T<sub>1</sub>
 
#** The file <code>/path/to/retain/vm-001.qcow2</code> contains the disk state of VM <code>vm-001</code> at time T<sub>1</sub>
 +
#** The file <code>/path/to/retain/vm-001.xml</code> contains the XML description of VM <code>vm-001</code> at time T<sub>1</sub>
 +
#** The file <code>/path/to/retain/vm-001.backend</code> contains the backend entry of VM <code>vm-001</code> at time T<sub>1</sub>
  
 
== Merge ==
 
== Merge ==

Revision as of 15:13, 22 October 2013

Overview

This page describes how the VMs and VM-Templates are backed-up inside the stoney cloud.

Basic idea

The main idea to backup a VM or a VM-Template is, to divide the task into three subtasks:

  • Snapshot: Save the machines state (CPU, Memory and Disk)
  • Merge: Merge the Disk-Snapshot with the live-image
  • Retain: Export the snapshot files

A more detailed and technical description for these three sub-processes can be found in the following sub-chapters.

Snapshot

  1. Create a snapshot with state:
    • If the VM vm-001 is running:
      • Save the state of VM vm-001 to the file vm-001.state (This file can either be created on a RAM-Disk or directly in the retain location. This example however saves the file to a RAM-Disk):
        virsh save vm-001 /path/to/ram-disk/vm-001.state
      • After this command, the VMs CPU and memory state is represented by the file /path/to/ram-disk/vm-001.state and the VM vm-001 is shut down.
    • If the VM vm-001 is shut down:
      • Create a fake state file for the VM:
        echo "Machine is not runnung, no state file" > /path/to/ram-disk/vm-001.state
  2. Move the disk image /path/to/images/vm-001.qcow2 to the retain location:
    mv /path/to/images/vm-001.qcow2 /path/to/retain/vm-001.qcow2
    • Please note: The retain directory (/path/to/retain/) has to be on the same partition as the images directory (/path/to/images/). This will make the mv operation very fast (only renaming the inode). So the downtime (remember the VM vm-001 is shut down) is as short as possible.
  3. Create the new (empty) disk image with the old as backing store file:
    qemu-img create -f qcow2 -b /path/to/retain/vm-001.qcow2 /path/to/images/vm-001.qcow2
    • chmod 660 /path/to/images/vm-001.qcow2
  4. Set correct ownership and permission to the newly created image:
    • chown root:vm-storage /path/to/images/vm-001.qcow2
  5. Save the VMs XML description
    • Save the current XML description of VM vm-001 to a file at the retain location:
      virsh dumpxml vm-001 > /path/to/retain/vm-001.xml
  6. Save the backend entry
    • There is no generic command to save the backend entry (since the command depends on the backend). Important here is, that the backend entry of the VM vm-001 is saved to the retain location: /path/to/retain/vm-001.backend
  7. Restore the VMs vm-001 from its saved state (this will also start the VM):
    virsh restore /path/to/ram-disk/vm-001.state
    • Please note: After this operation the VM vm-001 is running again (continues where we stopped it), and we have a consistent backup for the VM vm-001:
      • The file /path/to/ram-disk/vm-001.state contains the CPU and memory state of VM vm-001 at time T1
      • The file /path/to/retain/vm-001.qcow2 contains the disk state of VM vm-001 at time T1
      • The file /path/to/retain/vm-001.xml contains the XML description of VM vm-001 at time T1
      • The file /path/to/retain/vm-001.backend contains the backend entry of VM vm-001 at time T1

Merge

  1. Merge the disk images my-vm.qcow2 and my-vm-snap.qcow2 to a single image: virsh qemu-monitor-command my-vm --hmp "block_stream drive-virtio-disk0".

Retain

  1. Move the files to the backup location:
    • Move the old disk image to the backup location and add the date as suffix to not overwrite older backups: mv my-vm-backup.qcow2 /path/to/backup/my-vm-backup.qcow2.date
    • Move the state file to the backup location and add the date as suffix to not overwrite older backups: mv my-vm.state /path/to/backup/my-vm.state.date

State of the art

Next steps