Bug 1402419

Summary: [RFE] warn user when bonding SR-IOV VFs under one physical port
Product: [oVirt] ovirt-engine Reporter: Martin Polednik <mpoledni>
Component: BLL.NetworkAssignee: Dan Kenigsberg <danken>
Status: CLOSED WONTFIX QA Contact: Meni Yakove <myakove>
Severity: low Docs Contact:
Priority: unspecified    
Version: futureCC: bugs, edwardh, ylavi
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: 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: 2018-06-06 07:53:25 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:

Description Martin Polednik 2016-12-07 13:52:43 UTC
Description of problem:
The user should be warned when working with bonding & SR-IOV and attempts to bond 2 VFs under the same physical port. Bonding 2 VFs under the same physical port doesn't make sense.

Comment 1 Yaniv Lavi 2017-06-13 08:39:30 UTC
Doesn't network manager warn on this? 
If not can we move this RFE to them?

Comment 2 Edward Haas 2017-06-18 10:14:39 UTC
Defining a bond over VF/s that share the same PF is not only wrong, it is an error. The phy has a mini switch/bridge and having potential duplicate mac/s arriving from different VF/s will mess it up.

The RFE should not be on adding the warning, it should be on hiding the VF interfaces on the host, only VM/s should use those and I do not see any valid scenario to have them exposed on the host.

Regarding NM, I am not sure how we can expect such a warning from NM, it is not concerned with high lever misuse of the devices, that's a higher level concern.

Comment 3 Yaniv Lavi 2017-06-18 10:27:19 UTC
(In reply to Edward Haas from comment #2)
> Defining a bond over VF/s that share the same PF is not only wrong, it is an
> error. The phy has a mini switch/bridge and having potential duplicate mac/s
> arriving from different VF/s will mess it up.
> 
> The RFE should not be on adding the warning, it should be on hiding the VF
> interfaces on the host, only VM/s should use those and I do not see any
> valid scenario to have them exposed on the host.

Containers may use these devices.

> 
> Regarding NM, I am not sure how we can expect such a warning from NM, it is
> not concerned with high lever misuse of the devices, that's a higher level
> concern.

I don't think so, since this is the host level error, not a cluster level error.

Comment 4 Edward Haas 2017-06-18 10:38:24 UTC
(In reply to Yaniv Lavi from comment #3)
> (In reply to Edward Haas from comment #2)
> > Defining a bond over VF/s that share the same PF is not only wrong, it is an
> > error. The phy has a mini switch/bridge and having potential duplicate mac/s
> > arriving from different VF/s will mess it up.
> > 
> > The RFE should not be on adding the warning, it should be on hiding the VF
> > interfaces on the host, only VM/s should use those and I do not see any
> > valid scenario to have them exposed on the host.
> 
> Containers may use these devices.

Containers in this regard have the same behaviour, the VF interface is moved to the context of the VM/Container.
I claim that they should not be used in the context/view of the host.

> 
> > 
> > Regarding NM, I am not sure how we can expect such a warning from NM, it is
> > not concerned with high lever misuse of the devices, that's a higher level
> > concern.
> 
> I don't think so, since this is the host level error, not a cluster level
> error.

It is a user error, the tool allows you to configure things, but it is not enforcing you to do it in a "correct" way. Someone may find such a use valid, like in a test.
But I guess you need to convince NM team to see it as you do, not me. Maybe it will make sense for them.

Comment 5 Yaniv Lavi 2018-06-06 07:53:25 UTC
Closing old RFEs, please reopen if still needed.
Patches are always welcomed.