Bug 2222008 - Cloned VM using PVC of another VM can cause data corruption
Summary: Cloned VM using PVC of another VM can cause data corruption
Keywords:
Status: VERIFIED
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: User Experience
Version: 4.13.1
Hardware: All
OS: Linux
high
urgent
Target Milestone: ---
: 4.14.0
Assignee: Dana Orr
QA Contact: Guohua Ouyang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-11 13:42 UTC by nijin ashok
Modified: 2023-08-02 05:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CNV-30872 0 None None None 2023-07-11 13:45:08 UTC

Description nijin ashok 2023-07-11 13:42:18 UTC
Description of problem:

The source VM is using the below dataVolume:

~~~
# oc get vm  rhel8-b0w0qr4bgx7txkuf -o yaml |yq '.spec.template.spec.volumes'
- dataVolume:
    name: rhel8-b0w0qr4bgx7txkuf
  name: rootdisk
~~~

A new virtual machine (VM) was then cloned from the rhel8-b0w0qr4bgx7txkuf VM using the clone button in the OpenShift Console. This created a new persistent volume claim (PVC) and data volume (DV) by appending "volume-clone" to the name of the source DV.

~~~
oc get vm rhel8-b0w0qr4bgx7txkuf-first-clone -o yaml |yq '.spec.template.spec.volumes'
- dataVolume:
    name: rhel8-b0w0qr4bgx7txkuf-volume-clone
  name: rootdisk

# oc get pod virt-launcher-rhel8-b0w0qr4bgx7txkuf-first-clone-f6rfk  -o yaml|yq '.spec.volumes' |grep -A 3 rootdisk
- name: rootdisk
  persistentVolumeClaim:
    claimName: rhel8-b0w0qr4bgx7txkuf-volume-clone
~~~

The source VM, rhel8-b0w0qr4bgx7txkuf, was cloned again. However, the new cloned VM ended up using the same persistent volume claim (PVC) as the previous clone, rhel8-b0w0qr4bgx7txkuf-first-clone.


~~~
# oc get vm rhel8-b0w0qr4bgx7txkuf-second-clone -o yaml  |yq '.spec.template.spec.volumes'
- dataVolume:
    name: rhel8-b0w0qr4bgx7txkuf-volume-clone
  name: rootdisk

# oc get pod virt-launcher-rhel8-b0w0qr4bgx7txkuf-second-clone-65bk7 -o yaml|yq '.spec.volumes' |grep -A 3 rootdisk
- name: rootdisk
  persistentVolumeClaim:
    claimName: rhel8-b0w0qr4bgx7txkuf-volume-clone
~~~

This can easily lead to data corruption, as both VMs will be writing to the same PV.

By looking updateClonedDataVolumes[1], it appears that it is getting the data volume (DV) name from the source VM's volumes/ Data Volume Templates, appending "volume-clone" to the name, and using it as the DV name for the new cloned VM. It does not check if this persistent volume claim (PVC) is already in use and simply assumes that it does not exist and begins using it.


Version-Release number of selected component (if applicable):

OpenShift Virtualization   4.13.1


How reproducible:

100%

Steps to Reproduce:

1. Create two cloned VMs from a VM using the OpenShift Console clone button. 
2. Both the cloned VMs will be using the same PVC.

Actual results:

Cloned VM using PVC of another VM can cause data corruption

Expected results:

While generating the PVC name of the cloned VM, it should create a unique name and should check if it already exists before start using it. 

Additional info:

[1] https://github.com/kubevirt-ui/kubevirt-plugin/blob/main/src/views/virtualmachines/actions/components/CloneVMModal/utils/helpers.tsx#L154

Comment 3 Guohua Ouyang 2023-07-12 03:42:58 UTC
I could reproduce the issue on 4.13 and 4.14, in my opition, the PVC name should always be same with the VM name to avoid any potential issues.

Comment 4 Guohua Ouyang 2023-08-01 09:24:41 UTC
verified on kubevirt-console-plugin-rhel9:v4.14.0-2359


Note You need to log in before you can comment on or make changes to this bug.