Bug 1402419 - [RFE] warn user when bonding SR-IOV VFs under one physical port
Summary: [RFE] warn user when bonding SR-IOV VFs under one physical port
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: future
Hardware: Unspecified
OS: Unspecified
unspecified
low vote
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-07 13:52 UTC by Martin Polednik
Modified: 2018-06-06 07:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 07:53:25 UTC
oVirt Team: Network
ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

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.


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