Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1233405

Summary: [RFE] add configurable LINKDELAY per network (or nic)
Product: [oVirt] ovirt-engine Reporter: jas
Component: RFEsAssignee: bugs <bugs>
Status: CLOSED CURRENTRELEASE QA Contact: meital avital <mavital>
Severity: medium Docs Contact:
Priority: low    
Version: ---CC: bugs, daniel.beckman, danken, dholler, dougsland, jas, lsurette, lsvaty, mgoldboi, srevivo
Target Milestone: ovirt-4.4.0Keywords: FutureFeature, Reopened
Target Release: ---Flags: pm-rhel: ovirt-4.4?
pm-rhel: ovirt-4.5?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-24 12:39: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 jas 2015-06-18 19:57:33 UTC
Description of problem:

I have an ovirt host with dual Gigabit Intel X540-AT2 10G ports.  When I add ovirt host to engine, engine connects to it, and initializes ovirtmgmt via dhcp.  However, this card needs extra time to initialize, and dhcp ends up giving up too soon.  Normally, you would add "LINKDELAY=10" to /etc/sysconfig/network-scripts/ifcfg-XX files, but because of vdsm, this change would be reverted on reboot.  If I login as root on the server console and bring the interface up manually before engine gives up, then all proceeds well.  I can then edit /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt, and add to the end "linkdelay": "10" which solves the problem for good.... that is, until I re-kickstart and re-add the server again ...   It would be nice if ovirt engine would recognize that this network adapter needs that extra linkdelay, but at a minimum, I would hope there would be an option where I could configure the linkdelay in engine when adding the host.

Comment 1 Dan Kenigsberg 2015-06-23 13:29:25 UTC
As long as we use ifcfg, this can be hacked with writing a before_network_setup vdsm-hook, which would add LINKDELAY based on a new custom property.

Comment 2 Dan Kenigsberg 2016-05-04 08:25:57 UTC
*** Bug 1332232 has been marked as a duplicate of this bug. ***

Comment 3 Moran Goldboim 2017-12-28 10:47:27 UTC
closing old low priority RFEs, if applicable please reopen with justification.

Comment 4 jas 2017-12-28 12:51:17 UTC
This is a real problem, and the fix doesn't seem complicated to implement.   I don't see why it's being ignored. I have patiently waited years for this to be implemented. Maybe if this were more generalized as a way to add additional custom options to network configuration just like you can customize, say, kernel options on the host.

Comment 5 Yaniv Kaul 2017-12-28 12:57:46 UTC
(In reply to jas from comment #4)
> This is a real problem, and the fix doesn't seem complicated to implement.  
> I don't see why it's being ignored. I have patiently waited years for this
> to be implemented. Maybe if this were more generalized as a way to add
> additional custom options to network configuration just like you can
> customize, say, kernel options on the host.

Did you see comment 1 ? Doesn't a hook work for you?

Comment 6 jas 2017-12-28 15:25:12 UTC
This requires manual command line work to solve a problem that should be easily solvable from within the GUI.  In my own opinion, a hook that relies on ifcfg scripting is just a temporary hack. If I wanted to work from the command line, I could just "edit /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt, and add to the end "linkdelay": "10" which solves the problem for good.." as per my original report. Is the long term intention of ovirt to continue to allow ifcfg or to force use of network manager? If you think the solution that you've proposed is a proper solution to the problem, go ahead and close the ticket, but just know that I'm not satisfied with the solution suggested because I am 100% confident that Red Hat can do better.

Comment 9 Michal Skrivanek 2020-03-18 15:43:40 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 10 Michal Skrivanek 2020-03-18 15:46:55 UTC
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 11 Dominik Holler 2020-03-23 15:37:21 UTC
Let's check the behavior with nmstate.

Comment 12 Michal Skrivanek 2020-06-23 12:34:16 UTC
This request is not currently committed to 4.4.z, moving it to 4.5

Comment 13 RHEL Program Management 2020-06-23 12:34:22 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Comment 14 Dominik Holler 2020-06-24 12:39:44 UTC
On oVirt 4.4, LINKDELAY is not required anymore.
Even if the switch uses STP with STP hello and forward delay state after the link comes up,
NetworkManager goes on sending DHCP requests.