#Clone Virtual Machines on KubeVirt

This document provides step-by-step guidance on cloning virtual machines (VMs) using KubeVirt's VirtualMachineClone API.

#Ensure Prerequisites

Before initiating a VM clone operation, make sure the following requirements are satisfied:

• Snapshot‑Capable Storage: The Clone API relies on Snapshot & Restore functionalities. The virtual machine's storage class must support volume snapshots, and snapshot functionality must be explicitly enabled for that storage backend.

#Start Quickly

Follow these quick steps to clone a VM:

1. Prepare the Clone Manifest:

   Create a file named clone.yaml with the following structure:

   apiVersion: clone.kubevirt.io/v1beta1
   kind: VirtualMachineClone
   metadata:
     name: example-vm-clone
     namespace: ns-where-vm-run
   spec:
     source:
       apiGroup: kubevirt.io
       kind: VirtualMachine
       name: source-vm
     target:
       apiGroup: kubevirt.io
       kind: VirtualMachine
       name: target-vm

2. Execute the Clone Operation:

   Apply the manifest:

   kubectl create -f clone.yaml

3. Monitor the Clone Status:

   Wait until the cloning is completed successfully:

   kubectl wait vmclone example-vm-clone --for condition=Ready

4. Verify the Cloned VM:

   Inspect the cloned VM configuration:

   kubectl get vm target-vm -o yaml

5. Fix the DataVolume Label (UI metadata):

   The platform UI links VMs to their disks through the label vm.cpaas.io/used-by=<vm-name> that is automatically added to every DataVolume. After a clone operation the new DataVolume inherits the label from the source VM, so the UI still thinks it belongs to the old VM. Update the label on the newly created DV so the relationship displays correctly (functionality is not affected).

   # List DataVolumes in the VM's namespace; the cloned DV name usually starts with "restore-"
   kubectl get datavolumes -n <ns-where-vm-run>
   
   # Overwrite the label to point to the cloned VM
   kubectl label datavolume <new-dv-name> -n <ns-where-vm-run> vm.cpaas.io/used-by=<target-vm> --overwrite

#Understand the VirtualMachineClone Object

#View a Complete VirtualMachineClone Example

Here's a complete example of a VirtualMachineClone resource with detailed inline comments:

apiVersion: clone.kubevirt.io/v1beta1
kind: VirtualMachineClone
metadata:
  name: detailed-vm-clone
  namespace: ns-where-vm-run
spec:
  # Source VM details
  source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: vm-source

  # Target VM details
  target:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: vm-target

  # Filters for labels and annotations copied from source
  labelFilters:
    - "*"
    - "!exclude-key/*"
  annotationFilters:
    - "include-annotations/*"

  # Template filters to manage network annotations
  template:
    labelFilters:
      - "*"
    annotationFilters:
      - "!network-info/*"

  # Explicitly set new MAC addresses
  newMacAddresses:
    eth0: "02-00-00-aa-bb-cc"

  # Explicitly set SMBios serial
  newSMBiosSerial: "unique-serial-1234"

  # JSON patches to further customize the cloned VM
  patches:
    - '{"op": "add", "path": "/metadata/labels/new-label", "value": "new-value"}'
    - '{"op": "replace", "path": "/spec/template/metadata/annotations/new-annotation", "value": "updated-value"}'

#Understand Each Field

• Source and Target:

  • Define the original VM (source) and the cloned VM (target).
  • Auto-generated if the target name is omitted.
  • Both VMs must reside within the same namespace.

• Label and Annotation Filters:

  • Control copying or excluding labels/annotations from the source VM using wildcards (*) and negations (!).

• Template Label and Annotation Filters:

  • Useful for managing network-related annotations, especially with CNIs like Kube-OVN.

• newMacAddresses:

  • Optionally specify new MAC addresses for network interfaces.
  • Automatically regenerated if omitted.

• newSMBiosSerial:

  • Optionally specify a new SMBios serial.
  • Auto-generated based on VM name if not provided.

• JSON Patches:

  • Advanced customizations directly applied to VM specs.

#Check Clone Operation Phases

The .status.phase of a VirtualMachineClone object changes according to the cloning process progress. The table below explains each phase: