Bug 1437152 - v2v import from VmWare via REST API doesn't override the original mac address
Summary: v2v import from VmWare via REST API doesn't override the original mac address
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.1.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.1.5
: 4.1.5.2
Assignee: Shmuel Melamud
QA Contact: Ilanit Stein
URL:
Whiteboard:
Depends On:
Blocks: 1467846
TreeView+ depends on / blocked
 
Reported: 2017-03-29 16:04 UTC by sefi litmanovich
Modified: 2017-08-23 08:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-23 08:06:39 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.1+
mtessun: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
logs (1.31 MB, application/x-gzip)
2017-03-29 16:04 UTC, sefi litmanovich
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 80403 0 master MERGED core: always clone on import from cfme 2017-08-08 16:41:15 UTC
oVirt gerrit 80416 0 ovirt-engine-4.1 MERGED core: always clone on import from cfme 2017-08-09 06:46:59 UTC

Description sefi litmanovich 2017-03-29 16:04:47 UTC
Created attachment 1267324 [details]
logs

Description of problem:
The importing a vm from a VmWare external provider via REST API should perform the action as clone. When running the same action via UI, one can choose if to import as clone or not. When choosing as clone via UI the vm is imported and the mac address of it's nic is set to a new mac address from the engine's default mac pool range, overriding the original mac address with which this vm is set in VmWare.
When running the action via REST API, the import is done as clone (no choice in API, hopefully this could be added as well, will open RFE), but in this case, the original mac address persists and isn't overridden by new one for engine's default pool.

Attaching vdsm and engine logs, although not sure how helpful they can be. The time stamp for this import is around 17:53:50

Version-Release number of selected component (if applicable):
rhv-4.1.1.6-0.1.el7

How reproducible:
always

Steps to Reproduce:
1. Have a Vmware instance with some vm with nic having a mac address out of your ovirt engine's default mac pool.
2. Import this vm to the engine via API by invoking POST call to:
https://{engine_url}/ovirt-engine/api/externalvmimports/

body:
<external_vm_import>
   <vm>
     <name>some_name</name>
   </vm>
   <cluster id="{cluster_where_to_import" />
   <storage_domain id="{storage_where_to_import"/>
   <name>vmware_vm_name</name>
   <sparse>true</sparse>
   <username>{vmware_username}</username>
   <password>{vmware_password}</password>
   <provider>VMWARE</provider>
   <url>{url_to_vm_ware_cluster}</url>
 </external_vm_import>


Actual results:
Vm is imported successfully but the mac address isn't overridden by one from the engine's mac pool.

Expected results:
vm's mac address is overridden by one from the engine's mac pool.

Additional info:

Comment 1 Yaniv Kaul 2017-08-04 16:06:18 UTC
Is this on track to get into 4.1.5?

Comment 2 Tomas Jelinek 2017-08-08 16:26:52 UTC
(In reply to Yaniv Kaul from comment #1)
> Is this on track to get into 4.1.5?

yes

Comment 3 Sandro Bonazzola 2017-08-10 09:53:07 UTC
Michal, you targeted this to 4.1.6 but referenced patches are included in 4.1.5.
Can you please check this bug status?

Comment 4 Michal Skrivanek 2017-08-10 10:22:30 UTC
ok, if they are included then they are in:)

Comment 5 Ilanit Stein 2017-08-14 09:36:31 UTC
Verified on CFME 'Fine' nightly August 10/RHV-4.1.5.-3:

RHEL/Windows imported VMs, have a mac from the RHV mac pool range, and not the VMWare original mac address.


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