VM Snapshots:
Snapshots take the disk, memory and
device state of a VM at a specific moment in time. VM snapshots can preserve a
VM's state before a potentially dangerous operation, so you can always go back
to it if needed. Snapshots are identified with a unique name and can be taken
with the VM running (live snapshots), although it is highly recommended that
they be taken when a VM is suspended or shutdown (with no disk I/O), to
guarantee a clean snapshot.
Disk Format: Raw vs. Qcow2
Before we go through some examples,
let‟s talk about VM disk formats, since libvirt snapshots can only be performed
on certain type of disk formats. There are several types of VM disk formats,
but the most common are raw and qcow2 (copy-on-write). Raw disks are presented
as-is to the VM without any disk layering and do not support snapshots, whereas
qcow2 disks support a range of special features including snapshots,
compression and encryption.
Raw disks have better I/O performance
than qcow2 because the VM disk space is pre-allocated before the VM is created,
as opposed to qcow2, where VM disk space is thinly provisioned and allocated
on-the-go as the VM requires it. If you create a VM with a raw disk of 10 GB,
you‟ll see that the disk image size for the VM will be exactly 10 GB, whereas
for a VM with a qcow2 disk the actual file size will be a fraction of 10 GB
(say 2-3 GB) and it will grow as you occupy disk space inside the VM.
Snapshots can be considered a “backup”
of a VM‟s disk, although no actual bits are copied or backed up. The system
simply remembers the state of a VM and takes advantage of the copy-on-write
capabilities of qcow2. So snapshots are simply a record of where bits stood at
a given point in time, not an actual copy of the bits.
It is easy to convert from a raw VM image (which doesn‟t support
libvirt snapshots) to qcow2 format. In this example, we convert an image file
of size 10 GB for a VM called vm2.
1.
Shut down the VM:
#
virsh shutdown db1
2. Let‟s take a
look at the image file format:
#
cd /var/lib/libvirt/images/
#
qemu-img info db1.img
image:
db1.img
file
format: raw
virtual
size: 40G (42949672960 bytes)
disk
size: 4.9G
3. The
conversion process actually makes a qcow2 copy of the raw image and leaves the
raw image intact. The command is:
#
qemu-img convert -f raw db1.img -O qcow2 db1.qcow2
- The new image file extension is irrelevant;
we use “qcow2” to help us identify the different image format.
- The conversion process will take a few
minutes, depending on the size of the image file.
4. Let‟s take a
look at the new image file format:
#
qemu-img info db1.qcow2
image:
db1.qcow2
file
format: qcow2
virtual
size: 40G (42949672960 bytes)
disk
size: 4.7G
cluster_size:
65536
-
Notice that the virtual size remains
unchanged, it is still 10 GB.
-
The disk size (as the OS sees it) will
be less than 10 GB. In our case, it is 3.2 GB. If you run the „ls –l‟ command
on the file, its reported size will match the “disk size” reported here. As you
add files inside the VM disk, this file size will increase, up to a maximum of
10 GB.
5. Now we need
to modify the VM‟s XML definition file to use the new image file that will now
be used:
#
virsh edit db1
Look
in the <devices> section and search for the old image format entry
(“raw”) and the image file name (“vm2.img”). They should be next to each other:
<driver name='qemu' type='raw' cache='none'/>
<source file='/vm-images/db1.img'/>
Change
to:
driver
name='qemu' type='qcow2' cache='none'/>
source file='/vm-images/db1.qcow2'/>
Save file and exit.
6.
That‟s it, start the VM, which will now use the qcow2 image file. As mentioned
before, the raw image is left alone, you can save it for later use or delete
altogether.
Creating Snapshots:
In this example, we create a disk
snapshot for a VM named „vm1‟:
1. Verify that the VM disk format is „qcow2‟ and not „raw‟. You can use
either of two methods:
a. The „file‟ command:
#cd /var/lib/libvirt/images/
# file
db1.img
/vm-images/vm1.img: Qemu Image, Format:
Qcow, Version: 2
b. The „qemu-img‟ command:
# qemu-img info db1.img
image: db1.img
file format: raw
virtual size: 40G (42949672960 bytes)
disk size: 4.9G
2.
For reference, print list of existing snapshots:
# virsh
snapshot-list db1
Name Creation Time State
As can be seen, there are no existing snapshots for vm1.
3.
Shut down the VM, even though snapshots can be taken on a live VM, it is highly
recommended it be shut down to avoid any disk I/O and ensure a clean snapshot.
# virsh shutdown
db1
4.
Take snapshot:
# virsh
snapshot-create db1
Domain snapshot 1371645660 created
5. Let‟s take a look:
# virsh snapshot-list db1
Name Creation Time State
6. We have now created a
disk snapshot that we can always revert back to if we eventually corrupt our
file system and need to go back to a clean state.
7. We can keep creating more
snapshots as needed. After taking 3 more snapshots, we now have a total of 4
snapshots:
# virsh snapshot-list db1
Name
Creation Time State
------------------------------------------------------------
1371645660 2013-06-19 18:11:00 +0530 shutoff
The first and fourth snapshots were taken while the VM was shut
down.
- The second and third snapshots were taken while the VM was
running.
- Snapshots on stopped VMs will be a lot faster than on running
VMs.
- You can take as many snapshots as the VM‟s image file will fit.
As mentioned before a snapshot is not a copy of an image, so for example taking
a snapshot of a disk that is 3 GB in size does not mean it will take up an
additional 3 GB
Restoring
from Snapshots:
In this example, we are going to revert back to a snapshot image
we took in the previous section. We wish to go back to the 3rd snapshot (taken
at 13:30:35) with name 1334856635. In order to revert back to a snapshot, you
MUST shutdown the VM or the snapshot revert command will fail:
# virsh shutdown db1
# virsh
snapshot-revert db1 1371645660
If you are reverting back to a snapshot taken while the VM was
shut down, then you will have to start the VM. If you are reverting back to a
snapshot taken while the VM is was running, then the VM will already be running
after you revert back to it.
Deleting Snapshots:
Deleting snapshots is very straight-forward. Once you are sure
that you no longer need a snapshot, it is good practice to remove it. From our
previous example, let‟s remove the second snapshot:
# virsh
snapshot-list db1
# virsh
snapshot-delete vm1 1334856609
Name
Creation Time State
------------------------------------------------------------
1371645660 2013-06-19 18:11:00 +0530 shutoff
Domain snapshot 1371645660 deleted
Cloning
VMs:
If you want several VMs with the same OS and same configuration, I
recommend cloning existing VMs rather
than installing the OS on each one, which can quickly become a time-consuming
& tedious task.
In this example, we clone vm1 to create a new VM clone called
vm1-clone:
1.
Suspend the VM to be cloned. This is a requirement since it ensures that all
data and network I/O on the VM is
stopped.
# virsh suspend
db1
2.
Run the virt-clone command:
# virt-clone --connect qemu:///system --original
db1 --name db2 --file
db2.img
OR(example)
#virt-clone
--connect qemu:///system --original vm1
--name vm1-clone --file /vm-images/vm1-clone.img
This operation will take 2-3 minutes, depending on the size of the
VM.
3. When done, you can resume the original VM:
# virsh
resume db1
4.
The cloned VM is placed in shutdown mode. To start it:
# virsh start db2
The cloned VM is an exact copy of the original VM, all VM
properties (VCPUs, memory, disk space) and disk contents will be the same. The virt-clone
command takes care to generate a new MAC address for the VM clone and updates
the proper network controller configuration file (i.e.
/etc/sysconfig/network-scripts/ifcfg-em1), thus avoiding duplicate MAC
addresses.
For
more information, refer to the virt-clone man page.
No comments:
Post a Comment