Bug 1479796 - vmfex hook not working properly
Summary: vmfex hook not working properly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ovirt-4.2.0
: ---
Assignee: Arik
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-09 12:17 UTC by Michael Burman
Modified: 2017-12-20 10:42 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-12-20 10:42:41 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.2+
rule-engine: blocker+


Attachments (Terms of Use)
logs (1.14 MB, application/x-gzip)
2017-08-09 12:17 UTC, Michael Burman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 81859 0 master MERGED core: send custom properties of vnic profile in engine xml 2017-09-19 16:39:05 UTC

Description Michael Burman 2017-08-09 12:17:53 UTC
Created attachment 1311181 [details]
logs

Description of problem:
vmfex hook not working properly.

Seems like vmfex hook is not working as it should. The interface type must be:
<interface type='direct'>
      <mac address='00:00:00:00:00:2a'/>
      <source network='direct-pool' dev='enp6s0f1' mode='passthrough'/>
      <virtualport type='802.1Qbh'>
        <parameters profileid='VMFEX_portprofile_1'/>
      </virtualport>
      <target dev='macvtap0'/>

But instead, it is started as bridge type:
<interface type='bridge'>
      <mac address='00:00:00:00:00:26'/>
      <source bridge='vmfex'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <boot order='2'/>
      <alias name='net0'/>

I have tested this with the suggested fix(reverted patch) for BZ - 1478054, but it didn't fixed the issue. We believe that it might be another issue with the hook or something else. I don't see any errors in the logs. 

Version-Release number of selected component (if applicable):
4.2.0-0.0.master.20170808202742.git7c42951.el7.centos

How reproducible:
100 on latest master

Steps to Reproduce:
1. Configure vmfex via engine-config
2. Configure portfrofile via the UCS manager
3. Create network with vmfex vNIC profile and attach to UCS host
4. Add vmfex vNIC tot he VM and run it

Actual results:
<interface type='bridge'>
      <mac address='00:00:00:00:00:26'/>
      <source bridge='vmfex'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <boot order='2'/>
      <alias name='net0'/>

Expected results:
<interface type='direct'>
      <mac address='00:00:00:00:00:2a'/>
      <source network='direct-pool' dev='enp6s0f1' mode='passthrough'/>
      <virtualport type='802.1Qbh'>
        <parameters profileid='VMFEX_portprofile_1'/>
      </virtualport>
      <target dev='macvtap0'/>

Additional info:
We thought this was caused by BZ - 1478054, but the suggested patch(the reverted one for the hooks) didn't fixed the vmfex hook issue.

Comment 1 Dan Kenigsberg 2017-08-13 12:51:22 UTC
I believe that it's a dup of 1478054 and like it "solved" by https://gerrit.ovirt.org/#/c/80444/ . I hope a nicer solution follows.

Comment 2 Michael Burman 2017-08-13 13:44:41 UTC
(In reply to Dan Kenigsberg from comment #1)
> I believe that it's a dup of 1478054 and like it "solved" by
> https://gerrit.ovirt.org/#/c/80444/ . I hope a nicer solution follows.

Wrong. As we already said, the fix for BZ 1478054(see comment8#)

Comment 3 Michael Burman 2017-08-13 13:45:35 UTC
(In reply to Michael Burman from comment #2)
> (In reply to Dan Kenigsberg from comment #1)
> > I believe that it's a dup of 1478054 and like it "solved" by
> > https://gerrit.ovirt.org/#/c/80444/ . I hope a nicer solution follows.
> 
> Wrong. As we already said, the fix for BZ 1478054(see comment8#)
The fix for BZ 1478054 didn't helped.

Comment 4 Red Hat Bugzilla Rules Engine 2017-08-13 14:03:54 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 5 Edward Haas 2017-08-16 07:42:54 UTC
This looks like a consequence of the move to Engine XML.
This is the hook description: https://github.com/oVirt/vdsm/tree/master/vdsm_hooks/vmfex_dev

Comment 6 Arik 2017-08-16 07:45:21 UTC
Seems similar to other custom properties that are not handled properly with Engine XML.

Comment 7 Michael Burman 2017-08-31 10:11:35 UTC
Hi Arik,
Any updates on this report?

Comment 8 Arik 2017-08-31 10:21:41 UTC
Francesco, does the fix for bz 1483309 cover this one?

Comment 9 Francesco Romani 2017-09-01 11:23:38 UTC
(In reply to Arik from comment #8)
> Francesco, does the fix for bz 1483309 cover this one?

Yep, on the Vdsm side. But we will likely require changes on the Engine side too.
We will need the custom properties to be present to trigger the hook processing on Vdsm.

Comment 10 Michael Burman 2017-09-07 06:34:09 UTC
Arik Hi again,
Is this report going to be fixed any time soon? from the previous comment by Francesco, engine side fix is still needed..

Comment 11 Michael Burman 2017-09-11 08:04:57 UTC
We see that for OVN, Engine places the following per-interface custom properties

                <ovirt-vm:custom>
                    <ovirt-vm:provider_type>EXTERNAL_NETWORK</ovirt-vm:provider_type>
                    <ovirt-vm:vnic_id>5d1eb44a-b74e-4cbd-a2b3-df37e8d3fbb6</ovirt-vm:vnic_id>
                    <ovirt-vm:plugin_type>OPEN_VSWITCH</ovirt-vm:plugin_type>
                </ovirt-vm:custom>
            </ovirt-vm:device>

However, similar values are not set for VMFEX
            <ovirt-vm:custom />

Comment 12 Michael Burman 2017-09-24 07:00:18 UTC
Verified on - 4.2.0-0.0.master.20170921184504.gitfcfc9a7.el7.centos

Comment 13 Sandro Bonazzola 2017-12-20 10:42:41 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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