-
Bug
-
Resolution: Done-Errata
-
Critical
-
None
-
Quality / Stability / Reliability
-
5
-
False
-
-
False
-
CLOSED
-
If Release Note Needed, Set a Value
-
Set a Value
-
Moderate
-
None
Description of problem:
Duplicate name check does not work after the VM is deleted, customer is able to create a new VM with the same name as the old VM with same name that still has its virt-launcher pod terminating.
The problem is the new VM is suddenly assigned to the old VMI and its terminating virt-launcher pod.
Version-Release number of selected component (if applicable):
OCP 4.11.7
CNV 4.11.0
How reproducible:
Always
Steps to Reproduce:
1. Create a new Windows VM with Blank PVC (so it fails to boot)
2. Delete the VM
3. Check the VM is gone, but virt-launcher and VMI are still there
NAME READY STATUS RESTARTS AGE
virt-launcher-win10-thin-albatross-8hzzh 1/1 Terminating 0 7m
% oc get vmi
NAME AGE PHASE IP NODENAME READY
win10-thin-albatross 8m27s Running 10.129.2.19 shift-dcv2q-worker-2c76s False
% oc get vm
No resources found in default namespace.
4. Given the VM is gone, you can now create a new VM with the same name. Do it but no need to start it, leave it off.
5. You can now connect to the console and do other things on the terminating VM from step 1.
% oc get vm
NAME AGE STATUS READY
win10-thin-albatross 5m44s Stopped False
% oc get vmi
NAME AGE PHASE IP NODENAME READY
win10-thin-albatross 15m Running 10.129.2.19 shift-dcv2q-worker-2c76s False
It's connecting back to the old terminating pod.
- is blocked by
-
CNV-23140 Validate foreground deletion behavior
-
- New
-
- external trackers
- links to