Description of problem: FCOE doesn't work by default because it requires enabling of lldpad and fcoe services. Persistence of symlinks under /etc/systemd doesn't work Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. systemctl enable fcoe 2. reboot the system Actual results: fcoe/lldpad service are not started Expected results: started services Additional info:
Created attachment 1045378 [details] sosreport
Can reproduce. Description of problem: Version-Release number of selected component (if applicable): rhev-hypervisor7-7.1-20150603.0.iso ovirt-node-3.2.3-3.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Step by step to install the rhev-hypervisor7-7.1-20150603.0.iso on the FCoE machine. 2. Configure the system network, then drop into command. 3. Enable and start lldpad.socket, lldpad.service and fcoe service by command 'systemctl' 4. Run command "persist /etc/systemd/", then reboot the system. 5. Check the status of lldpad.socket, lldpad.service and fcoe service. Actual results: lldpad.socket, lldpad.service and fcoe are enabled, but not running. Expected results: lldpad.socket, lldpad.service and fcoe are enabled and running. Additional info: We try the above steps on the FCoE machine with ixgbe driver(Hareware: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection). Sosreport is attached.
Is this issue a 3.5.0 regression? If so, I guess it is yet another consequence of Bug 1203422 (which is to be fixed in 3.5.4). Both ifcfg-em1 and ifcfg-em2 have ONBOOT=no, and are taken up by vdsm too late (after fcoe have failed to start on top them). # Generated by VDSM version 4.16.20-1.el7ev DEVICE=em1 HWADDR=XXXX ONBOOT=no MTU=9000 DEFROUTE=no NM_CONTROLLED=no However, I don't understand where the symmetry between em1 and em2 breaks. Please check if ONBOOT=no is the sole problem by setting ONBOOT=yes in ifcfg*, and setting net_persistence=ifcfg in vdsm.conf. Remember to persist edited files so they show up after boot.
Dan, I'm checking with customer about your suggestion in comment #8 . I'll let you know about test result.
Adding this comment for _original_ bug description issue on node side. 1. This is rhevh 7.1 only bug. lldpad.socket, lldpad.service and fcoe are enabled, but not running as default after reboot rhevh. 2. No such issue on RHEVH 6 whatever rhevh 6.5 and 6.6 for 3.4.z and rhevh 6.6 and 6.7 for 3.5.z. lldpad and fcoe are already enabled as default, and daemon running as default in rhevh. Test version: rhev-hypervisor6-6.5-20150115.0.el6ev - 3.4.z rhev-hypervisor6-6.6-20150123.1.el6ev - 3.4.z rhev-hypervisor6-6.6-20150603.0.el6ev - 3.5.z rhev-hypervisor6-6.7-20150609.0.el6ev - 3.5.z
It seems comment 6 and comment 7 are different from the original bug description. To avoid confusing on bug fix and verify, we'd consider to split new bug to trace detail for comment 6 and comment 7.
Test version: rhev-hypervisor7-7.2-20150928.0.iso ovirt-node-3.3.0-0.10.20150928gite7ee3f1.el7ev.noarch Test steps: 1. PXE boot and install RHEV-H. 2. Configure RHEV-H network. 3. Reboot RHEV-H. Test result: After step1, check fcoe.service, lldpad.socket and lldpad.service status, all of them are running and enabled. After step2, all of three services are running and enabled. After step3, all of three services are running and enabled. This bug has been fixed, change the status to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0378.html