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)
Edy, please add the gerrit patches that implement this RFE.
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.
Thanks. Does it still not require any doc text?
(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.
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
(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..
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,
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.
(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.
Verified with - vdsm-4.20.7-1.gitc9cf1ee.el7.centos.x86_64
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.