Bug 1374384

Summary:	libvirt doesn't set the mac on VF's netdev name
Product:	Red Hat Enterprise Linux 7	Reporter:	Cole Robinson <crobinso>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED DUPLICATE	QA Contact:	Jingjing Shao <jishao>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	chhu, dyuan, jishao, laine, mschuppe, rbalakri, xuzhang
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1372944	Environment:
Last Closed:	2017-03-27 02:09:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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 ***