Bug 1422430

Summary:	[RFE] Support MACADDR when acquiring interfaces from ifcfg and NM.
Product:	[oVirt] vdsm	Reporter:	Edward Haas <edwardh>
Component:	Core	Assignee:	Edward Haas <edwardh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Michael Burman <mburman>
Severity:	medium	Docs Contact:
Priority:	high
Version:	4.20.0	CC:	bugs, cshao, danken, edwardh, mburman, ylavi
Target Milestone:	ovirt-4.2.0	Keywords:	FutureFeature
Target Release:	4.20.7	Flags:	rule-engine: ovirt-4.2+ mburman: testing_plan_complete+ ylavi: planning_ack+ danken: devel_ack+ rule-engine: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-20 10:50:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Edward Haas 2017-02-15 10:43:36 UTC

Description of problem:
Fixed mac addresses specified in ifcfg file through the MACADDR key should be respected by VDSM.

When VDSM acquires an iface that has such a fixed mac specified, it recreates the ifcfg file and currently drops the setting.

VDSM should read this information, and persist it in its configuration. (so it can later be used to restore the configuration or re-apply the configuration through other drivers)

Comment 1 Dan Kenigsberg 2017-11-02 23:19:52 UTC

Edy, please add the gerrit patches that implement this RFE.

Comment 2 Edward Haas 2017-11-03 06:16:34 UTC

The solution provided has extended the original requirement definition to a wider scope.
Any acquirement of externally created bonds, even the ones which their MAC has not been specified, will preserve their mac address in a persisted manner.

Comment 3 Dan Kenigsberg 2017-11-03 11:28:24 UTC

Thanks. Does it still not require any doc text?

Comment 4 Edward Haas 2017-11-05 08:08:45 UTC

(In reply to Dan Kenigsberg from comment #3)
> Thanks. Does it still not require any doc text?

The behaviour logic is "internal", I'm not sure if it will be useful to document in what conditions we preserve the mac and in which we do not. I may just be too confusing.

I think we should document this only when we expose the ability to set bond mac from Engine.

Comment 5 Michael Burman 2017-11-07 06:17:53 UTC

Edy hi,

vdsm now support cloned-mac when acquiring interfaces from NM, but not from ifcfg-* files. 

1) Bond created via cockpit + specified cloned-mac - PASS - host successfully added to rhv.
2) Bond created via NM without specifying the cloned-mac - PASS - host added and MACADDR was added to the ifcfg-bond file after this fix.
3) Bond created via ifcfg-* without specifying the cloned-mac - I think it failed, because the MACADDR key wasn't added to the ifcfg-* file as you said it should be. 

Am i right? 
 
Tested on vdsm-4.20.6-21.git079be83.el7.centos.x86_64 and 4.2.0-0.0.master.20171105155215.git59d3324.el7.centos

Comment 6 Michael Burman 2017-11-07 06:41:03 UTC

(In reply to Michael Burman from comment #5)
> Edy hi,
> 
> vdsm now support cloned-mac when acquiring interfaces from NM, but not from
> ifcfg-* files. 
> 
> 1) Bond created via cockpit + specified cloned-mac - PASS - host
> successfully added to rhv.
> 2) Bond created via NM without specifying the cloned-mac - PASS - host added
> and MACADDR was added to the ifcfg-bond file after this fix.
> 3) Bond created via ifcfg-* without specifying the cloned-mac - I think it
> failed, because the MACADDR key wasn't added to the ifcfg-* file as you said
> it should be. 
> 
> Am i right? 
>  
> Tested on vdsm-4.20.6-21.git079be83.el7.centos.x86_64 and
> 4.2.0-0.0.master.20171105155215.git59d3324.el7.centos

Edy, on scenario 3^^, the MACADDR key was added to the ifcfg-bond file only after reboot, is it the expected behaviour? waiting for your response..

Comment 7 Michael Burman 2017-11-07 08:44:51 UTC

Summarize or results for the 4 relevant scenarios:

1) NM bond + specified cloned-mac - PASS - host added successfully
2) NM bond - without cloned-mac - PASS - MACADDR added to the ifcfg-bond file
3) ifcfg bond + specified cloned-mac - Fail - host added successfully, but the MACADDR was gone from the ifcfg-bond file 
4) ifcfg bond - without cloned-mac - Fail - MACADDR wasn't added as should to the ifcfg-bond file

I believe this should be failedQA,

Comment 8 Red Hat Bugzilla Rules Engine 2017-11-07 08:44:58 UTC

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 9 Edward Haas 2017-11-08 09:34:26 UTC

(In reply to Michael Burman from comment #7)
> Summarize or results for the 4 relevant scenarios:
> 
> 1) NM bond + specified cloned-mac - PASS - host added successfully
> 2) NM bond - without cloned-mac - PASS - MACADDR added to the ifcfg-bond file
> 3) ifcfg bond + specified cloned-mac - Fail - host added successfully, but
> the MACADDR was gone from the ifcfg-bond file 
> 4) ifcfg bond - without cloned-mac - Fail - MACADDR wasn't added as should
> to the ifcfg-bond file
> 
> I believe this should be failedQA,

This is a good catch, we have a bug that acquires external bonds during network upgrade flow even though they are not in use by a network.

Comment 10 Michael Burman 2017-11-15 15:42:15 UTC

Verified with - vdsm-4.20.7-1.gitc9cf1ee.el7.centos.x86_64

Comment 11 Sandro Bonazzola 2017-12-20 10:50:44 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.