Troubleshooting virtualized applications using cloning

What is cloning?

In virtualization environments the term cloning refers to the process of creating an exact duplicate or clone of an existing virtual machine. Cloning a virtual machine does not destroy the original virtual machine; it just creates a copy of the VM’s virtual hard disks and configuration files. If the VM was running or in a saved state at the time it was cloned, the resulting clone also includes the memory state of the original VM.

The clone is an exact duplicate of the original VM, which means it has the same security identifier (SID) and computer name. It also may have the same IP address and/or MAC address as well, depending on how the clone operation works. If this is the case and the original VM and the clone are both running on the same network, problems will result because of duplicate network addresses. If the network is part of an Active Directory forest, the original VM and clone will use the same computer account in Active Directory which can also cause problems. Because of these types of considerations, cloned VMs should generally not be used on production networks.

Because cloning a virtual machine can cause problems if you accidentally introduce the clone onto the same network where the original VM resides, the term “cloning” is sometimes used to refer to the two-step process of running Sysprep on a virtual machine and then generating a new virtual machine from the sysprepped image. Once a VM is cloned in this way it can be used as a template for creating new virtual machines that are identical in most respects to the original VM but which each have their own unique SID and computer name so they can co-exist on the same network. Unless otherwise specified however, for the purposes of this article I’ll use the term “clone” to refer to an exact duplicate of an existing virtual machine.

Benefits of cloning

One of the biggest benefits of being able to clone a virtual machine is for troubleshooting issues involving applications and services running in the guest operating system of the virtual machine. To do this you need to be able to clone the virtual machine while it is running.

For example, let’s say you have a virtual machine running on your production network and customers are using an application in this virtual machine. Some of your customers then begin to complain that the application is timing out, hanging, or crashing while they are using it. How do you troubleshoot this issue? It’s risky to try to make changes to the application environment while customers are using the application, so you might wait until late at night when no customers are accessing it before you try to troubleshoot the problem. That means another late night for an already tired and overburdened administrator–you.

However, if you could create an exact duplicate (a clone) of the virtual machine while the problem is happening, you could copy the cloned VM to a test network so you can safely play around with it to try to determine what went wrong with the application. Of course, if the application is multi-tier then it gets more complicated as you would need to clone the whole application environment consisting of virtual machines, virtual networks, and storage. But in theory you can use live cloning like this to safely troubleshoot problems involving applications and services running within virtual machines.

Cloning with VMware

Administrators who work with the VMware virtualization platform will already be familiar with how to clone live (running) virtual machines as this capability has been around for a while in VMware vCenter Server which provides a centralized platform for managing VMware vSphere environments. The steps for cloning a virtual machine running on a VMware ESXi host are straightforward and are summarized in the VMware Knowledge Base in an article titled “Cloning virtual machines in vCenter Server (1027865)“. Note the statement here about live clones being expected to be slightly out-of-date compared to the original VM from which they are cloned. Because cloning is not an instantaneous operation and because uncommitted transactions may be pending in the virtual machine’s disk storage, the cloning process isn’t perfect. For a more detailed explanation of the steps involved in cloning a VM using the VMware vSphere Client, see the article titled “Clone a Virtual Machine in the vSphere Client” in the vSphere 5 Documentation Center.

Cloning with Hyper-V

Microsoft System Center Virtual Machine Manager (VMM) has supported cloning of virtual machines since the 2008 release of the platform. VMM documentation carefully points out that you should sysprep a virtual machine before cloning it so you can create new VMs from the cloned VM. Figure 1 shows a running (live) virtual machine being cloned and provisioned to a Windows Server 2012 R2 Hyper-V host using the SCVMM Admin console of VMM 2012 R2. 

Image
Figure 1: Live cloning a virtual machine using System Center Virtual Machine Manager 2012 R2.

The live cloning in VMM 2012 R2 creates an exact duplicate of the original virtual machine with the same computer name, SID, MAC address and IP address. In this example I’ve deployed the clone to a different logical network than the original VM so there won’t be any conflict.

What if you don’t have System Center 2012 R2 deployed in your environment? Is there any way to clone live virtual machines using Hyper-V alone? If your Hyper-V hosts are running the latest version Windows Server 2012 R2 the answer is Yes because a new feature introduced in this version is the ability to export a virtual machine while it is running. What’s especially cool is that you can export the VM’s checkpoints (snapshots) too.

Here’s a quick walkthrough of how you might perform a live export of a virtual machine running on Windows Server 2012 R2 Hyper-V and then import it onto another host to create a clone of the original VM. Figure 2 shows the Hyper-V Manager console being used to export a running VM named DC150 (150):

Image
Figure 2: Step 1 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

Tip:
You can also select multiple VMs in Hyper-V Manager, right-click, and select Export to live export multiple running VMs simultaneously in Windows Server 2012 R2.

We’ll export the running VM to a share on our destination host:

Image
Figure 3: Step 2 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

Note that you might need to configure NTFS permissions on the share to allow the export to happen. For more information see this link.

The export process starts by temporarily merging together the checkpoints:

Image
Figure 4: Step 3 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

The VM files are then exported to the share on the destination host as shown by opening File Explorer on the destination host:

Image
Figure 5: Step 4 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

We can now use Hyper-V Manager on the destination host to import the exported virtual machine files:

Image
Figure 6: Step 5 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

Stepping through the Import Virtual Machine wizard, we’ll choose to restore the virtual machine using its existing unique ID so it’s an exact duplicate of the original VM:

Image
Figure 7: Step 6 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

The only hiccup we encounter is caused by the fact that the virtual network on our test server HOST40 has a different name than the virtual network on the production server HOST30 where the original VM resides:

Image
Figure 8: Step 7 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

All we need to do to fix this however is to select a virtual network on HOST40 for the virtual machine and each of its checkpoints:

Image
Figure 9: Step 8 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

Once we complete the wizard, the virtual machine files are copied to the destination storage folders and the import process is complete. The cloned VM is initially in a Saved state as shown here:

Image
Figure 10: Step 9 of live cloning a VM using Windows Server 2012 R2 Hyper-V.

You can then start the clone and it will behave and run exactly like the original VM from which it was cloned. Once you’ve done this you can now use your clone to begin troubleshooting whatever problems have been happening with the applications and services running in the original virtual machine.

You can also use Windows PowerShell to live export and import virtual machines but it can be a bit trickier, especially the import process. We’ll look at this in a future article here on VirtualizationAdmin.com.

Conclusion

Live cloning is a powerful tool for troubleshooting problems with applications and services running in a virtual machine without the need of taking the virtual machine offline. Both the VMware and Microsoft virtualization platforms now support this capability, so it’s a good idea to learn how to use it.

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top