KVM LVM backup, cloning, and more

This is a follow up to my previous post in which I explained how to set up a KVM virtual machines host, so if you haven’t set up a host yet, you may want to read that post first.

In the previous post I’ve described how to set up a very simple virtualised environment based on KVM and using LVM for the storage layer. I also mentioned that I usually do part of the administration with the bundled GUI, virt-manager, while I use command line tools for those administration tasks that aren’t available in the GUI; in second part I’ll describe some of the ones I use most often.

Backing up a KVM LVM virtual machine

When I need to backup a virtual machine, I usually just make a backup of the virtual disk attached to it. Surely it makes to backup also the configuration of the virtual hardware and any other settings concerning the virtual machines, but since creating a new virtual machine with virt-manager requires only a few clicks, I usually back up just the virtual disk.

A virtual disk is not very different from any raw disk, so the simplest way of backing up one is using the dd utility. For simplicity, I am assuming here that you have followed my advice in the previous post to use LVM for the storage pool containing your virtual disks. If that’s the case, each virtual machine’s disk will be an LVM logical volume and it will be mapped as /dev/<volume group>/<virtual machine>. You can list the available logical volumes with the lvs command.

For example, since in my case I store the virtual machines in the virtual-machines volume group, I can run the following command to list the virtual disks currently available in that volume group:


As you can see, the disk for this sample virtual machine is available at /dev/virtual-machines/backup-tests.

If I want to make a backup of this raw disk as it is, I can run:


This will create a copy of the raw disk with identical size to that of the original disk. Intuitively, if represents the source disk, and of the name of the file that’ll contain the backup copy of the disk; bs instead is the block size. The optimal value for this parameter might depend on the particular configuration (both hardware and software) of your system, but in my case I found that the value 512K always yields the highest transfer rates.

To restore a virtual machine’s disk from a backup, I can just swap source and target disks:


Of course, remember to shutdown the virtual machine before restoring the disk to a previous state.

You may also want to compress your backups to save storage space:

One thing you’ll notice if you haven’t used the dd utility before is that it doesn’t show progress by default, which can be annoying if you are copying a large disk. This utility, though, does show something if you send the USR1 signal to its process while it’s copying. Therefore here’s a tip to show some sort of pseudo-realtime progress during the copy:


Update 23/5/2012: Reader David Wittman suggests a really nice tip for an easier and nicer way of showing progress during the copy using pv (pipe viewer):


You will notice that due to the piping the copy speed is reduced a little (with the same block size, in my case copy was ~10MB/sec slower), but this is indeed a much nicer way of showing progress and it also requires less typing too.

Backing up with LVM snapshots

The way I just suggested to backup a virtual disk only works well if the virtual machine isn’t currently in use, i.e. it is powered off. If changes are being made to the disk while making a backup, the backup might be invalid and a subsequent restore could either fail or restore an unusable virtual machine. This is one of the reasons why I recommend to use LVM for the storage pool: it is possible to instantly create a snapshot of a disk, on the fly, even without having to shut down the virtual machine first. The snapshot is a reliable “view” of the disk at the exact moment the snapshot was taken, so any changes made to the disk during the backup won’t affect that “view” of the disk in the given point in time.

This enables us to make reliable backups of a virtual machine’s disk even while the virtual machine is running, by simply backing up the snapshot rather than the main disk. The first step is creating the snapshot:


You can verify the presence of the snapshot for example with lvs again:


As you can see there’s a new logical volume having ha1 as the origin. LSize is different though: this doesn’t represent the actual size of the snapshot, but the max size of all the changes made to the original volume since the snapshot was created, that the snapshot can contain. The example sets this argument to 1G but even a smaller value should be enough for making backups. It it also important to note that snapshots can seriously impact on the performance of the disk sub system: this is because snapshots work with the copy on write strategy. This means that the performance of the disk layer can degrade proportionally to the number of snapshots created (you can have as many snapshots as you need for a given origin volume, provided you are aware of the performance penalty).

The performance implications should suggest that LVM snapshots should not be used as a backup strategy per se. A good approach is to temporarily create a snapshot of a volume, make a backup copy using the snapshot, and discard the snapshot upon completion of the backup. This way, if the backup is quick and there aren’t many changes being made to the original volume in the meantime, the performance penalty of the snapshot can be very small for a short time.

So, in the previous example, once I have created a snapshot I can proceed with the actual backup, by making a copy of the snapshot instead of the original volume:

Once this is completed, I can discard the (no longer needed) snapshot:


Cloning a virtual machine

virt-manager has a handy cloning functionality, so in most cases you will want to just use that. The alternative with the command line is creating a new logical volume of the same size as the original first, and then restoring the disk from backup or just copying directly from the other disk’s logical volume; eventually, this new disk would be attached to the new vm clone. For example, if restoring from a backing:


The example basically shows how I create a new virtual machine’s disk from a “template” (ubuntu-10.04-server.disk is a backup of a virtual machines with already all the tools and packages I always need on my VMs).

Note: when cloning a virtual machine with the command line method (can’t remember if this applies to VM cloned with virt-manager too), the cloned VM might have some networking issues due to the different MAC address. In particular you might see errors such as “SIOCSIFADDR: No such device“. To fix, just run:


Then reboot the virtual machine and networking should work as usual.

Mounting a virtual machine’s partitions on the host

In some cases, you may need to mount a virtual machine’s disk (or, better, the partitions in it) directly on the host. How to do this slightly differs depending on whether you are using LVM also inside the virtual machine or not, so I’ll show the steps required in each case.

If LVM is not used also within the virtual machine disk

Check which partitions are available inside the virtual machine’s disk:


Make the partitions available for mounting:


Verify that the partitions are now available for mounting:


Mount a partition (e.g. the first one is usually the boot/main partition):


Verify the partition has been correctly mounted:


You can at this point backup the content of the partitions or do whatever you want with it. Once done, it’s time to…
Clean up when the mount is no longer needed:


If LVM is also used within the virtual machine disk (“nested” LVM)

Check which partitions are available inside the virtual machine’s disk:


Make the partitions available for mounting:

Check that the partitions are now available for mounting:

Slightly different form the non-nested-LVM scenario. In this case, ls /dev/mapper will still show some items named after the virtual machine disk (i.e. <volume group>-<volume>X) and as many new items as the number of partitions inside the virtual machine disk, named as <volume group>-<partition name>. These are the partitions you want to mount. For example:


The important ones in my example are ubuntu-root and ubuntu-swap_1. These represent the actual partitions inside my virtual machine’s disk, and in this example I could need to mount the main partition, which is the first one.

Mount a partition (e.g. the first one is usually the boot/main partition):


Again, you can at this point backup the content of the partitions or do whatever you want with it. Once done,

Clean up when the mount is no longer needed:

That’s pretty much it for now on KVM LVM based virtual machines; know of other tips or anyway useful administration tasks? Please let me know in the comments. I might also update the post later with some more.

About the author

Vito Botta

I am a passionate web developer based in Espoo, Finland. Besides computing, I love boxing and good food!

View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *

three × one =