Crmgo Blog

Cloning KVM

Cloning KVM

Before cloning, make sure the source image contains everything needed for future clones. If you've just installed the operating system, consider whether it makes sense to additionally install mc, nano, traceroute, configure networking, hostname, SSH motd, iptables, and so on. Verify network connectivity and install the latest…

Cloning KVM

Before cloning, make sure the source image contains everything needed for future clones. If you have just installed the operating system, consider whether it makes sense to install additional tools such as mc, nano, traceroute, configure networking, hostname, SSH motd, iptables, and so on. Check network connectivity and install the latest updates. You might also want to configure httpd and a mail server. Ensure that the original image is free of suspicious issues and runs stably. Ready? Let's go!

Let's look at the list of virtual machines:

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 4     vm1                            running

We will create a copy of vm1 and name it vm2.

First, let's suspend the original:

# virsh suspend vm1

or shut it down:

# virsh shutdown vm1

Next, let's consider two options:

Option 1: using the virt-clone utility:

# virt-clone -o vm1 -n vm2 -f /data/vms/vm2.img --connect=qemu:///system WARNING Setting the graphics device port to autoport, in order to avoid conflicting. Allocating 'vm2.img' | 20 GB 00:00:06

Clone 'vm2' created successfully.

Since we ran the command as root, virt-clone created a clone of the vm1.img disk named vm2.img with the owner root:root instead of qemu:qemu. This does not affect performance. The main thing is to ensure that the disk was created:

# ls -al /data/vms/ total 3104656 drwxr-xr-x. 2 root root 4096 Apr 27 06:17 . drwxr-xr-x. 5 root root 4096 Apr 19 17:45 .. -rw-r--r--. 1 qemu qemu 21478375424 Apr 27 06:17 vm1.img -rw-r--r--. 1 root root 1587609600 Apr 27 06:17 vm2.img

When starting vm2, you might see the following message:

# virsh start vm2 error: Failed to start domain vm2 error: internal error: process exited while connecting to monitor: 2016-04-27T10:19:21.991952Z qemu-kvm: -chardev socket,id=charchannel0, path=/var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied 2016-04-27T10:19:21.992122Z qemu-kvm: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-vm1/org.qemu.guest_agent.0, server,nowait: chardev: opening backend "socket" failed

Note the domain-vm1 in the error text. Fix this (find domain-vm1 and replace it with domain-vm2):

# virsh edit vm2 Domain vm2 XML configuration edited.

# virsh start vm2
Domain vm2 started

Option 2 (manual method)

Since vm2 already exists, let's create vm3 and compare the results.

Shut down the original:

# virsh shutdown vm1

Copy the disk:

# cp /data/vms/{vm1,vm3}.img

Export the XML configuration from vm1:

# virsh dumpxml vm1 > /tmp/vm3-template.xml

Remove the original UUID; libvirt will add new values:

# sed -i /uuid/d /tmp/vm3-template.xml # sed -i '/mac address/d' /tmp/vm3-template.xml

Rename the names from the old to the new:

# sed -i s/vm1/vm3/ /tmp/vm3-template.xml

Create the new vm3:

# virsh define /tmp/vm3-template.xml # virsh start vm1 # virsh start vm3

I found this option here: http://unix.stackexchange.com/questions/8351/

Analysis of the results

The difference I noticed is that in the first case, the size of the vm2 disk differed significantly from the size of vm3:

# ls -al --block-size=M /data/vms/ total 4550M drwxr-xr-x. 2 root root 1M Apr 27 06:44 . drwxr-xr-x. 5 root root 1M Apr 19 17:45 .. -rw-r--r--. 1 qemu qemu 20484M Apr 27 07:00 vm1.img -rw-r--r--. 1 qemu qemu 1515M Apr 27 07:00 vm2.img -rw-r--r--. 1 qemu qemu 20484M Apr 27 06:59 vm3.img

It appears that virt-clone, when creating a clone, copies only the space actually used by the virtual machine. The size of vm2.img is only slightly larger than the output of "df -h" executed inside vm1, vm2, or vm3 (since I didn't do anything with the guests between cloning operations, their sizes remained unchanged relative to the "parent" vm1).

In general, when you encounter something for the first time, try to analyze changes after each step. You ran "sed -i /uuid/d /tmp/vm3-template.xml" – check the result. Compare it with the original. Then you cloned vm2; just in case, check the directory where your guest disks are stored. You created a new network – check whether a network configuration file was created in /etc/libvirt/qemu/networks. And so on.

Wherever you see something unfamiliar, try to verify it before executing it in the console. If you see an example of a virt-clone command in this article, don't be lazy: go online and search for who else suggests this, and read the man page.

Try to document, record, and comment on all your actions, and you will get your own how-to guide that you can use when you need to create a couple more guests a year from now. If you don't create virtual machines regularly, it's normal to forget the syntax, and the history may be cleared or filled with so many commands, possibly with typos, that you'll have to figure it all out again from scratch.

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 7     vm2                            running
 9     vm1                            running
 10    vm3                            running

Note: This post may be AI-assisted and then human-edited. Editorial responsibility: Dmytro Lomaka, Kaltenkirchen.

Categories: KVM