SupportConsoleDevelopersStart a trialContact

Chapter 11. Cloning virtual machines

To quickly create a new virtual machine (VM) with a specific set of properties, you can clone an existing VM.

Cloning creates a new VM that uses its own disk image for storage, but most of the clone’s configuration and stored data is identical to the source VM. This makes it possible to prepare multiple VMs optimized for a certain task without the need to optimize each VM individually.

11.1. How cloning virtual machines works

Cloning a virtual machine (VM) copies the XML configuration of the source VM and its disk images, and makes adjustments to the configurations to ensure the uniqueness of the new VM. This includes changing the name of the VM and ensuring it uses the disk image clones. Nevertheless, the data stored on the clone’s virtual disks is identical to the source VM.

This process is faster than creating a new VM and installing it with a guest operating system, and can be used to rapidly generate VMs with a specific configuration and content.

If you are planning to create multiple clones of a VM, first create a VM template that does not contain:

  • Unique settings, such as persistent network MAC configuration, which can prevent the clones from working correctly.
  • Sensitive data, such as SSH keys and password files.

For instructions, see Creating virtual machines templates.

Additional resources

11.2. Creating virtual machine templates

To create multiple virtual machine (VM) clones that work correctly, you can remove information and configurations that are unique to a source VM, such as SSH keys or persistent network MAC configuration. This creates a VM template, which you can use to easily and safely create VM clones.

You can create VM templates by using the virt-sysprep utility or you can create them manually based on your requirements.

11.2.1. Creating a virtual machine template by using virt-sysprep

To create a cloning template from an existing virtual machine (VM), you can use the virt-sysprep utility. This removes certain configurations that might cause the clone to work incorrectly, such as specific network settings or system registration metadata. As a result, virt-sysprep makes creating clones of the VM more efficient, and ensures that the clones work more reliably.

Prerequisites

  • The guestfs-tools package, which contains the virt-sysprep utility, is installed on your host: 

    # dnf install guestfs-tools
  • The source VM intended as a template is shut down.

  • You know where the disk image for the source VM is located, and you are the owner of the VM’s disk image file.

    Note that disk images for VMs created in the system connection of libvirt are located in the /var/lib/libvirt/images directory and owned by the root user by default: 

    # ls -la /var/lib/libvirt/images
-rw-------.  1 root root  9665380352 Jul 23 14:50 a-really-important-vm.qcow2
-rw-------.  1 root root  8591507456 Jul 26  2017 an-actual-vm-that-i-use.qcow2
-rw-------.  1 root root  8591507456 Jul 26  2017 totally-not-a-fake-vm.qcow2
-rw-------.  1 root root 10739318784 Sep 20 17:57 another-vm-example.qcow2
  • Optional: Any important data on the source VM’s disk has been backed up. If you want to preserve the source VM intact, clone it first and turn the clone into a template.

Procedure

  1. Ensure you are logged in as the owner of the VM’s disk image: 

    # whoami
root

  2. Optional: Copy the disk image of the VM. 

    # cp /var/lib/libvirt/images/a-really-important-vm.qcow2 /var/lib/libvirt/images/a-really-important-vm-original.qcow2

    This is used later to verify that the VM was successfully turned into a template.

  3. Use the following command, and replace /var/lib/libvirt/images/a-really-important-vm.qcow2 with the path to the disk image of the source VM. 

    # virt-sysprep -a /var/lib/libvirt/images/a-really-important-vm.qcow2
[   0.0] Examining the guest ...
[   7.3] Performing "abrt-data" ...
[   7.3] Performing "backup-files" ...
[   9.6] Performing "bash-history" ...
[   9.6] Performing "blkid-tab" ...
[...]

Verification

  • To confirm that the process was successful, compare the modified disk image to the original one. The following example shows a successful creation of a template: 

    # virt-diff -a /var/lib/libvirt/images/a-really-important-vm-orig.qcow2 -A /var/lib/libvirt/images/a-really-important-vm.qcow2
- - 0644       1001 /etc/group-
- - 0000        797 /etc/gshadow-
= - 0444         33 /etc/machine-id
[...]
- - 0600        409 /home/username/.bash_history
- d 0700          6 /home/username/.ssh
- - 0600        868 /root/.bash_history
[...]

Additional resources

11.2.2. Creating a virtual machine template manually

To create a template from an existing virtual machine (VM), you can manually reset or unconfigure a guest VM to prepare it for cloning.

Prerequisites

  • Ensure that you know the location of the disk image for the source VM and are the owner of the VM’s disk image file.

    Note that disk images for VMs created in the system connection of libvirt are by default located in the /var/lib/libvirt/images directory and owned by the root user: 

    # ls -la /var/lib/libvirt/images
-rw-------.  1 root root  9665380352 Jul 23 14:50 a-really-important-vm.qcow2
-rw-------.  1 root root  8591507456 Jul 26  2017 an-actual-vm-that-i-use.qcow2
-rw-------.  1 root root  8591507456 Jul 26  2017 totally-not-a-fake-vm.qcow2
-rw-------.  1 root root 10739318784 Sep 20 17:57 another-vm-example.qcow2
  • Ensure that the VM is shut down.
  • Optional: Any important data on the VM’s disk has been backed up. If you want to preserve the source VM intact, clone it first and edit the clone to create a template.

Procedure

  1. Configure the VM for cloning:

    1. Install any software needed on the clone.
    2. Configure any non-unique settings for the operating system.
    3. Configure any non-unique application settings.

  2. Remove the network configuration:

    1. Remove any persistent udev rules by using the following command: 

      # rm -f /etc/udev/rules.d/70-persistent-net.rules
      Note

      If udev rules are not removed, the name of the first NIC might be eth1 instead of eth0.

    2. Remove unique information from the NMConnection files in the /etc/NetworkManager/system-connections/ directory.

      1. Remove MAC address, IP address, DNS, gateway, and any other unique information or non-desired settings. 

        *ID=ExampleNetwork
BOOTPROTO="dhcp"
HWADDR="AA:BB:CC:DD:EE:FF"                  <- REMOVE
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
UUID="954bd22c-f96c-4b59-9445-b39dd86ac8ab" <- REMOVE
      2. Remove similar unique information and non-desired settings from the /etc/hosts and /etc/resolv.conf files.

  3. Remove registration details:

    • For VMs registered on the Red Hat Network (RHN): 

      # rm /etc/sysconfig/rhn/systemid

    • For VMs registered with Red Hat Subscription Manager (RHSM):

      • If you do not plan to use the original VM: 

        # subscription-manager unsubscribe --all # subscription-manager unregister # subscription-manager clean

      • If you plan to use the original VM: 

        # subscription-manager clean
        Note

        The original RHSM profile remains in the Portal along with your ID code. Use the following command to reactivate your RHSM registration on the VM after it is cloned: 

        # subscription-manager register --consumerid=71rd64fx-6216-4409-bf3a-e4b7c7bd8ac9

  4. Remove other unique details:

    1. Remove SSH public and private key pairs: 

      # rm -rf /etc/ssh/ssh_host_example

    2. Remove the configuration of LVM devices: 

      # rm /etc/lvm/devices/system.devices
    3. Remove any other application-specific identifiers or configurations that might cause conflicts if running on multiple machines.

  5. Remove the gnome-initial-setup-done file to configure the VM to run the configuration wizard on the next boot: 

    # rm ~/.config/gnome-initial-setup-done
    Note

    The wizard that runs on the next boot depends on the configurations that have been removed from the VM. In addition, on the first boot of the clone, it is recommended that you change the hostname.

11.3. Cloning a virtual machine by using the command-line interface

For testing, to create a new virtual machine (VM) with a specific set of properties, you can clone an existing VM by using CLI.

Prerequisites

  • The source VM is shut down.
  • Ensure that there is sufficient disk space to store the cloned disk images.
  • Optional: When creating multiple VM clones, remove unique data and settings from the source VM to ensure the cloned VMs work properly. For instructions, see Creating virtual machine templates.

Procedure

  • Use the virt-clone utility with options that are appropriate for your environment and use case.

    Sample use cases

    • The following command clones a local VM named example-VM-1 and creates the example-VM-1-clone VM. It also creates and allocates the example-VM-1-clone.qcow2 disk image in the same location as the disk image of the original VM, and with the same data: 

      # virt-clone --original example-VM-1 --auto-clone
Allocating 'example-VM-1-clone.qcow2'                            | 50.0 GB  00:05:37

Clone 'example-VM-1-clone' created successfully.

    • The following command clones a VM named example-VM-2, and creates a local VM named example-VM-3, which uses only two out of multiple disks of example-VM-2: 

      # virt-clone --original example-VM-2 --name example-VM-3 --file /var/lib/libvirt/images/disk-1-example-VM-2.qcow2 --file /var/lib/libvirt/images/disk-2-example-VM-2.qcow2
Allocating 'disk-1-example-VM-2-clone.qcow2'                                      | 78.0 GB  00:05:37
Allocating 'disk-2-example-VM-2-clone.qcow2'                                      | 80.0 GB  00:05:37

Clone 'example-VM-3' created successfully.

    • To clone your VM to a different host, migrate the VM without undefining it on the local host. For example, the following commands clone the previously created example-VM-3 VM to the 192.0.2.1 remote system, including its local disks. Note that you require root privileges to run these commands for 192.0.2.1: 

      # virsh migrate --offline --persistent example-VM-3 qemu+ssh://root@192.0.2.1/system
root@192.0.2.1's password:

# scp /var/lib/libvirt/images/<disk-1-example-VM-2-clone>.qcow2 root@192.0.2.1/<user@remote_host.com>://var/lib/libvirt/images/

# scp /var/lib/libvirt/images/<disk-2-example-VM-2-clone>.qcow2 root@192.0.2.1/<user@remote_host.com>://var/lib/libvirt/images/

Verification

  1. To verify the VM has been successfully cloned and is working correctly:

    1. Confirm the clone has been added to the list of VMs on your host: 

      # virsh list --all
Id   Name                  State
---------------------------------------
-    example-VM-1          shut off
-    example-VM-1-clone    shut off

    2. Start the clone and observe if it boots up: 

      # virsh start example-VM-1-clone
Domain 'example-VM-1-clone' started

Additional resources

11.4. Cloning a virtual machine by using the web console

To create new virtual machines (VMs) with a specific set of properties, you can clone a VM that you had previously configured by using the web console.

Note

Cloning a VM also clones the disks associated with that VM.

Prerequisites

Procedure

  1. Log in to the RHEL 9 web console.

    For details, see Logging in to the web console.

  2. In the Virtual Machines interface of the web console, click the Menu button ⋮ of the VM that you want to clone.

    A drop down menu appears with controls for various VM operations.

  3. Click Clone.

    The Create a clone VM dialog appears.

    Create a clone VM dialog box with an option to enter a new name for the VM.
  4. Optional: Enter a new name for the VM clone.

  5. Click Clone.

    A new VM is created based on the source VM.

Verification

  • Confirm whether the cloned VM appears in the list of VMs available on your host.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.