Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1885226 - [v2v] [api] VM import RHV/VMware to CNV Import deploying a 2nd vmimport with the same targetVmName should not be allowed.
Summary: [v2v] [api] VM import RHV/VMware to CNV Import deploying a 2nd vmimport with...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: V2V
Version: 2.5.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 2.5.3
Assignee: Sam Lucidi
QA Contact: Amos Mastbaum
URL:
Whiteboard:
: 1885124 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-05 13:25 UTC by Amos Mastbaum
Modified: 2021-03-15 19:29 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-15 19:29:40 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Amos Mastbaum 2020-10-05 13:25:26 UTC 
Description of problem:

The API allows you to create vmimport CRs with duplicated targetVmName.
 
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.Deploy 2 identical vmimport that has different CR name  


Actual results:
The 2nd vmimport is created successfully
The 2nd vmimport CR may receive vm status message that belongs to the 1st vmimport. 

Expected results:
no 2 vmimports with the same namespace and targetVmName should NOT  be allowed to be created.



Additional info:
Comment 1 Yaacov Zamir 2020-10-06 19:01:58 UTC 
Note:
It will also be nice if the operator can rejects "targetVmName" if we already have a vm with that name ?
Comment 2 Piotr Kliczewski 2020-10-07 07:40:43 UTC 
That is the intention to check target vm name conflicts.
Comment 3 Maayan Hadasi 2020-10-15 15:03:15 UTC 
This issue is relevant for both sources RHV/VMware

Tested with CNV 2.5.0
Comment 4 Sam Lucidi 2020-12-10 17:02:58 UTC 
https://github.com/kubevirt/vm-import-operator/pull/450
Comment 5 Yaacov Zamir 2020-12-16 13:10:33 UTC 
*** Bug 1885124 has been marked as a duplicate of this bug. ***
Comment 6 Ilanit Stein 2020-12-30 11:36:14 UTC 
Verified on Tested om OCP-4.6/CNV hco-v2.5.3-64
by running twice same vm import create. On the 2nd run got:
"Error from server (AlreadyExists): error when creating "STDIN": virtualmachineimports.v2v.kubevirt.io "vmware-import-1" already exists"
Comment 7 Ilanit Stein 2021-01-05 10:43:39 UTC 
The verification in comment #6 was wrong, because it tested using same vm import CR name,
while bug fixes using same targetVmName.

Verified on OCP-4.6/CNV hco-v2.5.3-64 
using same VM import CR twice, with different CR name. The 2nd VM import did not get the first VM import "successful" status.
It failed as expected on:

status:
  conditions:
  - lastHeartbeatTime: "2021-01-05T10:37:36Z"
    lastTransitionTime: "2021-01-05T10:36:24Z"
    message: Virtual machine already exists in target namespace
    reason: DuplicateTargetVMName
    status: "False"
    type: Valid
  targetVmName: ""
  warmImport:
    consecutiveFailures: 0
    failures: 0
    successes: 0

@Sam,
This bug still exists on CNV-2.6.0 - Is this expected please?
Comment 8 Fabien Dupont 2021-01-05 17:31:08 UTC 
The CNV 2.6.0-452 build should have the fix.
Comment 9 Ilanit Stein 2021-01-10 08:47:48 UTC 
Moving bug to Verified since it moved to Assigned in comment #7 by mistake.
Note You need to log in before you can comment on or make changes to this bug.