Bug 1479796 - vmfex hook not working properly
vmfex hook not working properly
Status: VERIFIED
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network (Show other bugs)
4.2.0
x86_64 Linux
medium Severity high (vote)
: ovirt-4.2.0
: ---
Assigned To: Arik
Michael Burman
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-09 08:17 EDT by Michael Burman
Modified: 2017-09-27 08:34 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+
rule-engine: blocker+


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


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 81859 master MERGED core: send custom properties of vnic profile in engine xml 2017-09-19 12:39 EDT

  None (edit)
Description Michael Burman 2017-08-09 08:17:53 EDT
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 08:51:22 EDT
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 09:44:41 EDT
(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 09:45:35 EDT
(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 10:03:54 EDT
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 03:42:54 EDT
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 03:45:21 EDT
Seems similar to other custom properties that are not handled properly with Engine XML.
Comment 7 Michael Burman 2017-08-31 06:11:35 EDT
Hi Arik,
Any updates on this report?
Comment 8 Arik 2017-08-31 06:21:41 EDT
Francesco, does the fix for bz 1483309 cover this one?
Comment 9 Francesco Romani 2017-09-01 07:23:38 EDT
(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 02:34:09 EDT
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 04:04:57 EDT
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 03:00:18 EDT
Verified on - 4.2.0-0.0.master.20170921184504.gitfcfc9a7.el7.centos

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