Bug 1374384 - libvirt doesn't set the mac on VF's netdev name
Summary: libvirt doesn't set the mac on VF's netdev name
Keywords:
Status: CLOSED DUPLICATE of bug 1415609
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Jingjing Shao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-08 14:24 UTC by Cole Robinson
Modified: 2020-04-15 14:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1372944
Environment:
Last Closed: 2017-03-27 02:09:44 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Cole Robinson 2016-09-08 14:24:44 UTC
This was filed against fedora 23 version, but by the upstream discussion this sounds relevant to libvirt.git as well, and it affects openstack, so worth considering for RHEL.


+++ This bug was initially created as a clone of Bug #1372944 +++

Description of problem:
Due to this commit cb3fe38c  (which supposed to fix this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113474) libvirt is now setting the mac on the VF using netlink RTM_SETLINK but not on the VF's netdev name.
For macvtap-passthrough we need the mac to be set both on VF's netdev name and using the VF using netlink RTM_SETLINK.

Version-Release number of selected component (if applicable):
libvirt-1.2.18.3-1.fc23.x86_64

How reproducible:
create a guest with macvtap-passthrough in openstack
The guest will not get DHCP because the the VF's netdev name is not set.


Actual results:
guest didn't get DHCP

Expected results:
guest should get DHCP

Additional info:
https://www.redhat.com/archives/libvir-list/2016-September/msg00008.html

Comment 3 Laine Stump 2017-03-27 02:09:44 UTC
Hmm. How did I previously miss that this is the same as Bug 1415609. Could have saved the trouble of filing that one.

Anyway there is now a lot of comment/info in there, so I'm closing this bug as a duplicate of that one (which will be fixed - half of the patches are already pushed, and the other half waiting for one more ACK).

*** This bug has been marked as a duplicate of bug 1415609 ***


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