+++ This bug was initially created as a clone of Bug #2182056 +++

Description of problem:
Create a VM and wait for it becomes running, clone the VM, check the VM disk, it use the same PVC of the source VM, which is wrong as when this VM is up, the source VM is not able to turn up. And also it causes confused delete issues, from what I see the VM is stucking at terminating status forever when delete both of them at the same time.

It's happens on 4.12 and 4.13, regression from 4.11.

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

How reproducible:

Steps to Reproduce:
1. Create a VM and wait for it's up
2. Clone a VM from it
3. Verify the VM disk, same as the source VM
4. When the cloned VM is up, try to start the source VM, source VM is not able to up.

Actual results:
Cloned VM PVC is same with source VM's PVC

Expected results:
Cloned VM use its own PVC.

Additional info:

— Additional comment from nijin ashok on 2023-03-29 03:04:30 EDT —

Setting severity to urgent. I hit this in my test env and please note that this causes data corruption/loss because two VMs will be using the same PVC and will corrupt the filesystem. It didn't hit any customers yet but I think should be fixed ASAP considering the impact. The issue looks to be because 4.12 CDI removes DV by default after completion and the console is still referring to this. Adding annotation cdi.kubevirt.io/storage.deleteAfterCompletion: "false" to DV is a workaround.

— Additional comment from Germano Veit Michel on 2023-03-29 03:14:17 EDT —

I hit it while testing. If the Volume is block, qemu-kvm file locking does not protect the volume from double usage and so both the original VM and its clone can be started.

If with file-based storage the qemu protection worked and the VM failed to start with:

Failed to get \"write\" lock\nIs another process using the image [/var/run/kubevirt-private/vmi-disks/rootdisk/disk.img]?')","timestamp":"2023-03-29T03:45:54.286546Z","uid":"9c1b3d3e-c34a-4831-a7e1-d3a861f5cd8f"}

But on block that does not work, and I lost my RHV-M VM (and its clone) with filesystem corruption.

This is a rather basic feature that needs to work and not corrupt VMs. Agreed on the severity.