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.
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.
(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#)
(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.
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.
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
Seems similar to other custom properties that are not handled properly with Engine XML.
Hi Arik, Any updates on this report?
Francesco, does the fix for bz 1483309 cover this one?
(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.
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..
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 />
Verified on - 4.2.0-0.0.master.20170921184504.gitfcfc9a7.el7.centos
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.