Clone an existing VM's PVC as a new VM and as a new data volume to provision additional VMs.
A clone is a copy of a VM. Usually, you carefully prepare a VM to use as a model and then clone it to deploy multiple identical machines. Deploying new VMs this way is fast and reliable, because you do not have to install and configure the operating system manually for each machine.
A clone likely has machine-specific data and configuration settings from the original VM. For example, Microsoft Windows clones get the same machine Security Identifier (SID). Red Hat Enterprise Linux clones get the same SSL certificates, SSH host keys, and Red Hat subscriptions.
To prevent the clones from having these same identifying settings, you usually seal the original VM before using it to create clones. Sealing the VM is a process where you clear the machine-specific information.
An alternative to using clones is using templates and then configuring the VM with tools such as cloud-init or Ansible.
This method starts with an initial operating system installation that you configure by using automated tools.
After installing and configuring the VM to use as a model for clones, remove all information that is unique to the VM. Unique information includes hardware information that is specific to the VM, such as MAC addresses; unique system configurations, such as the hostname and static IP addresses; and possibly logs and other data.
Depending on the operating system, you might need to perform these steps manually, or tools might be available to seal the image for you.
For Red Hat Enterprise Linux systems, use the virt-sysprep command.
The command directly edits the disk block device to remove all information that is unique to the VM.
You do not run the command from inside the VM itself but from a Linux system with access to the VM disk block devices.
You must stop the VM before using the virt-sysprep command.
For Microsoft Windows systems, use the sysprep.exe command to initiate a System Out-of-Box-Experience (OOBE).
The process for sealing a Windows VM concludes when you shut down the VM.
Red Hat OpenShift Virtualization provides the virtctl guestfs command to start a container that includes the virt-sysprep tool.
The container also attaches the VM's PVC as the /dev/vda block device.
The following example shows the execution of the virt-sysprep command to seal the dsk1 PVC in the golden-vms namespace:
[user@host ~]$virtctl guestfs -n golden-vms dsk1Use image: registry.redhat.io/container-native-virtualization/libguestfs-tools@sha256:591e...64ae The PVC has been mounted at /dev/vda Waiting for container libguestfs still in pending, reason: ContainerCreating, message: ...output omitted... If you don't see a command prompt, try pressing enter. [root@libguestfs-tools-dsk1 /]#virt-sysprep -a /dev/vda[ 0.0] Examining the guest ... [ 3.4] Performing "abrt-data" ... [ 3.4] Performing "backup-files" ... [ 4.1] Performing "bash-history" ... ...output omitted... [ 4.7] Setting a random seed [ 4.7] Setting the machine ID in /etc/machine-id [ 4.9] Performing "lvm-uuids" ... [root@libguestfs-tools-dsk1 /]#exitexit [user@host ~]$
The first time that the VM boots after sealing, the operating system re-creates many of the items that the sealing tools stripped out.
Thus, never start a VM that you sealed. If you accidentally start the VM, then you must repeat the process of sealing the image.
Use the OpenShift web console to create a VM clone:
Navigate to → , select the VM to clone, and then stop the VM. OpenShift Virtualization can clone only stopped VMs.
Click → and then complete the form.
Click .
![]() |
Clone a VM by completing the form
Name of the VM to create | |
Namespace of the new VM. To create the VM in a different namespace from the source VM, your cluster administrator must enable permissions to clone VMs across namespaces. The reference section provides a link that describes that configuration. | |
Summary of the VM configuration. |
When OpenShift Virtualization clones a VM, it creates a VirtualMachine resource with the same characteristics as the source VM.
The new VirtualMachine resource declares a DataVolume resource for each disk in the source VM.
These DataVolume resources orchestrate the cloning operation.
The following example shows the dataVolumeTemplates section of the VirtualMachine resource for a cloned VM with two disks:
[user@host ~]$oc get VirtualMachine front1 -o yamlapiVersion: kubevirt.io/v1 kind: VirtualMachine ...output omitted... spec: dataVolumeTemplates:- apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: creationTimestamp: null name: vm1-bvle4
namespace: intranet-front spec: source:
pvc: name: vm1 namespace: golden-vms storage:
resources: requests: storage: 10Gi - metadata: creationTimestamp: null name: webroot-bvle4
namespace: intranet-front spec: source: pvc: name: webroot namespace: golden-vms storage: resources: requests: storage: 1Gi ...output omitted...
The | |
The name of the data volume is the name of the source PVC and a string of random characters. The cloning process appends the name of the source PVC with the random characters. Both data volumes use the same suffix. | |
The | |
The |
To clone a disk, OpenShift Virtualization can rely on the back-end storage. If the back-end storage provides a cloning feature and the Container Storage Interface (CSI) driver supports the feature, then OpenShift Virtualization uses that method. Otherwise, if the back-end storage and its CSI driver support snapshots, then OpenShift Virtualization uses temporary snapshots for the cloning process. If the back-end storage does not support snapshots, then OpenShift Virtualization starts Kubernetes pods to copy the content of the source volume into the destination volume. That copy method is usually slower than delegating the cloning process to the back-end storage.
The StorageProfile resource that OpenShift Virtualization associates with each storage class uses the cloneStrategy parameter to specify the cloning method:
csi-clone
The cloning process relies on the back-end storage cloning feature.
snapshot
The cloning process relies on the back-end storage snapshot feature.
copy
The cloning process does not rely on back-end storage. OpenShift Virtualization starts Kubernetes pods for the copying.
When the StorageProfile resource does not include the cloneStrategy parameter, OpenShift Virtualization uses snapshots if possible.
Otherwise, OpenShift Virtualization uses the copy method.
Instead of cloning a whole VM, you can clone individual disks and then attach the copies to another VM.
DataVolume resources orchestrate the cloning process.
Therefore, to clone an individual disk, you must create a DataVolume resource.
The following DataVolume resource clones the documentroot PVC from the golden-vms namespace into a new PVC:
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: documentroot-clone1 spec: storage:resources: requests: storage: 1Gi storageClassName: ocs-external-storagecluster-ceph-rbd-virtualization source:
pvc: name: documentroot namespace: golden-vms
The | |
The |
Run the oc apply -f command to create the resource.
If the VM that uses the source PVC is running, then the resourcefile.yamlDataVolume resource stays in the CloneScheduled phase:
[user@host ~]$oc apply -f documenrootDV.yamldatavolume.cdi.kubevirt.io/documentroot-clone1 created [user@host ~]$oc get DataVolumeNAME PHASE PROGRESS RESTARTS AGE documentroot-clone1CloneScheduled10m
After you stop the VM, the cloning process completes.
You can attach the new PVC, which has the same name as the DataVolume resource, to a VM and then access its contents.
[user@host ~]$oc get DataVolumeNAME PHASE PROGRESS RESTARTS AGE documentroot-clone1Succeeded24m [user@host ~]$oc get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES ...documentroot-clone1Bound pvc-bb80...e067 10Gi RWX ...
When you create or clone a whole VM, OpenShift Virtualization creates the required DataVolume resources.
When you delete the VM, OpenShift Virtualization also deletes the associated DataVolume resources and the underlying PVC and PV resources.
In contrast, OpenShift Virtualization does not automatically delete the DataVolume resources that you create independently of a VM.
You can reuse your DataVolume resources with another VM.
Knowledgebase: "Steps to Make a Clean VM for Use as a Template or Clone"
For more information about the virtctl guestfs command , refer to the Deploying libguestfs by Using virtctl section in the Red Hat OpenShift Container Platform Virtualization guide at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/virtualization/index#virt-about-libguestfs-tools-virtctl-guestfs_virt-using-the-cli-tools
For more information about cloning VM disks by using data volumes, refer to the Creating VMs by Cloning PVCs section in the Red Hat OpenShift Container Platform Virtualization guide at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/virtualization/index#virt-creating-vms-by-cloning-pvcs