Offload VM Cloning from KVM to the Back-end Storage

A few weeks ago, I addressed the concept of using the back-end storage to clone RHEL boot LUNs as opposed to repeated Kickstarts.  The reasoning is simple enough – cloning on the backend is significantly faster that creating from scratch.  Work smarter, not harder.. Right?

So what happens when we apply the same logic to individual virtual machines? In a word?


If you’re still not convinced, allow me to illuminate.  Let the hypervisor “hypervise”.  If you’ve got important virtualized workloads running, why would you want to take CPU and memory resources away to perform storage tasks?  Additionally, if your backend has the capability to perform the task at hand, cloning in this case, it likely can do it much more efficiently than any hypervisor can.  If nothing else, we can again look at the significant time saved by cloning on the storage as opposed to cloning at the compute layer.

Let’s take a deeper look at what is involved.

We’ll be using my favorite hypervisor (KVM) and my favorite back-end storage (NetApp) as usual to perform these tasks.  Here are some assumptions that I’m going to make in order to keep this article brief:

The following procedures make several assumptions:

  • An NFS datastore is already configured with NetApp best practices
  • The NFS datastore is already attached to the KVM host
  • A FlexClone license has been purchased and installed on the NetApp controller.
  • Deduplication has been enabled on the NFS datastore
  • A base RHEL virtual machine has already been created using RHEL best practices
  • The base RHEL image has been made suitably “generic” (see the last article on cloning)

Actions on the NetApp Controller

On the NetApp controller, type the following command:

clone start /vol/kvm_nfs_vol/rhel_base.img /vol/kvm_nfs_vol/rhel_clone.img -n -l

Actions on the KVM host

On the KVM host type the following command to clone the XML descriptor file as well as dictate that a new disk image already exists:

virt-clone --original-xml=/etc/libvirt/qemu/rhel_base.xml --preserve-data --file=/var/lib/libvirt/images/rhel_clone.img -n rhel_clone

NOTE: By default, the ‘virt-clone’ command will clone everything – the XML file and the disk.  We’ve already created the new disk, so we just have to worry about the XML file.  The virt-clone command is smart enough to create a unique UUID for the VM as well as a new MAC address.  If you’re working from a pool of UUID’s and/or MAC addresses, you can even specify that in the command line as well…

Then type the following command to effectively register the newly cloned virtual machine (actually, its XML descriptor file) with the hypervisor:

  virsh define /etc/libvirt/qemu/rhel_clone.xml

Start the newly cloned virtual machine:

virsh start rhel_clone

“Magic” performed, situation illuminated.

Imagine putting that into a script to launch 20 clones based on an event.  As good as KVM is, there is no way that it could do in a few minutes what FlexClone can do in a few seconds.  And because they’re all based on the same base image in the same NFS datastore, Deduplication will maintain your datastore’s girlish figure.

Thanks again for reading,


2 thoughts on “Offload VM Cloning from KVM to the Back-end Storage”

Agree? Disagree? Something to add to the conversation?