- What is the nature and description of the request? Support for initially configuring LACP (Mode 4 Bond) manually in order to connect with RHEV-M. - Why does the customer need this? (List the business requirements here) In order to actually communicate with RHEV-M over Brocade brand networking equipment, the LACP bond must be enabled in order for traffic to reach the RHEV-M. If that bond is created, vdsm-reg treats it as a bridge instead of a bond, and breaks. - How would the customer like to achieve this? (List the functional requirements here) TUI support for initially configuring and connecting to RHEV-M over LACP
I believe that in the network page of ovirt-node's TUI, an admin can set up arbitrary bonding options. However, the sad thing is that as you can see in bug 1097713, vdsm-reg does not work over bond, and it has never worked. You can still trigger installation via Engine, but the real answer is in bug 994451: vdsm-reg must go.
Any update on this one? Our switches (Extreme Networks) do have the same problem as the Brocade switches. Registering new hosts is currently very hard for us without jumping thru hoops.
As mentioned in comment 2 users can already created bonds with arbitrary options in the RHEV-H, this should also cover the creation of LACP capable bonds. But note that in case that bonds are used, the user must add the host from the RHEV-M side.
Fabian - anything else left to do here?
It should get test coverage, otherwise we should be fine. Ying, should this (LACP mode) be covered explicitly in test case RHEVM3-13108 ?
(In reply to Fabian Deutsch from comment #15) > It should get test coverage, otherwise we should be fine. So it should be moved to ON_QA. > > Ying, should this (LACP mode) be covered explicitly in test case > RHEVM3-13108 ?
Indeed.
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
We try the following steps on rhev-hypervisor7-7.2-20151112.1.iso. Confirmed that RHEV-M can add RHEV-H by mode 4 bond network, with RHEV-H connect to the network switch which configured LACP mode. Physical ENV: Test machine Switch eno3 <-----------> port 21 eno4 <-----------> port 22 Version: RHEV-M3.6.0.3-0.1.el6 rhev-hypervisor7-7.2-20151112.1.iso ovirt-node-3.6.0-0.20.20151103git3d3779a.el7ev.noarch Steps: 1. Configure the port 21 and 22 with LACP mode configured on the switch. 2. Install RHEV-H7.2-20151112, create bond0 with mode4 on eno3 and eno4, configure bond0 with vlan tag 20 and DHCP mode. 3. Add RHEV-H from RHEV-M3.6.0.3-0.1.el6. 4. Unplug one port from the test machine. Result: After step3, RHEV-H can be up successful on RHEV-M. After step4, RHEV-H still up on RHEV-M. Additional info: Switch configuration: ------------------------------------------------------ Switch#show run ... ... ! interface Port-channel5 switchport trunk encapsulation dot1q switchport mode trunk ! ... ... ! interface GigabitEthernet0/21 switchport trunk encapsulation dot1q switchport mode trunk duplex full channel-protocol lacp channel-group 5 mode active ! interface GigabitEthernet0/22 switchport trunk encapsulation dot1q switchport mode trunk duplex full channel-protocol lacp channel-group 5 mode active ! ... ... Switch# show interfaces Port-channel5 etherchannel Port-channel5 (Primary aggregator) Age of the Port-channel = 00d:00h:44m:52s Logical slot/port = 2/5 Number of ports = 2 HotStandBy port = null Port state = Port-channel Ag-Inuse Protocol = LACP Ports in the Port-channel: Index Load Port EC state No of bits ------+------+------+------------------+----------- 0 00 Gi0/21 Active 0 0 00 Gi0/22 Active 0 Time since last port bundled: 00d:00h:33m:50s Gi0/22 Time since last port Un-bundled: 00d:00h:35m:33s Gi0/22 Switch#show int Gi0/21 trunk Port Mode Encapsulation Status Native vlan Gi0/21 on 802.1q trunk-inbndl 1 (Po5) Port Vlans allowed on trunk Gi0/21 1-4094 Port Vlans allowed and active in management domain Gi0/21 1,3,10-13,15-16,20,30,40,99,152-153 Port Vlans in spanning tree forwarding state and not pruned Gi0/21 1,3,10-13,15-16,20,30,40,99,152-153 Switch#show int Gi0/22 trunk Port Mode Encapsulation Status Native vlan Gi0/22 on 802.1q trunk-inbndl 1 (Po5) Port Vlans allowed on trunk Gi0/22 1-4094 Port Vlans allowed and active in management domain Gi0/22 1,3,10-13,15-16,20,30,40,99,152-153 Port Vlans in spanning tree forwarding state and not pruned Gi0/22 1,3,10-13,15-16,20,30,40,99,152-153 RHEV-H configuration: --------------------------------------------------------- [root@localhost ~]# tcpdump -nn -v -i eno3 -s 1500 -c 1 'ether[20:2] == 0x2000' tcpdump: WARNING: eno3: no IPv4 address assigned tcpdump: listening on eno3, link-type EN10MB (Ethernet), capture size 1500 bytes 03:49:43.055084 CDPv2, ttl: 180s, checksum: 0x7e82 (unverified), length 419 Device-ID (0x01), length: 6 bytes: 'Switch' Version String (0x05), length: 189 bytes: Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEE4, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Mon 16-Jul-07 03:11 by myl Platform (0x06), length: 20 bytes: 'cisco WS-C3560G-24TS' Address (0x02), length: 69 bytes: IPv4 (3) 192.168.20.1 IPv6 (2) fe80::21e:49ff:fe88:f4c2 IPv6 (1) 3ffe:501:ffff:101::1 Port-ID (0x03), length: 19 bytes: 'GigabitEthernet0/21' Capability (0x04), length: 4 bytes: (0x00000029): Router, L2 Switch, IGMP snooping Protocol-Hello option (0x08), length: 32 bytes: VTP Management Domain (0x09), length: 0 bytes: '' Native VLAN ID (0x0a), length: 2 bytes: 1 Duplex (0x0b), length: 1 byte: full Management Addresses (0x16), length: 13 bytes: IPv4 (1) 192.168.20.1 unknown field type (0x1a), length: 12 bytes: 0x0000: 0000 0001 0000 0000 ffff ffff 1 packet captured 1 packet received by filter 0 packets dropped by kernel [root@localhost ~]# tcpdump -nn -v -i eno4 -s 1500 -c 1 'ether[20:2] == 0x2000' tcpdump: WARNING: eno4: no IPv4 address assigned tcpdump: listening on eno4, link-type EN10MB (Ethernet), capture size 1500 bytes 03:50:43.059479 CDPv2, ttl: 180s, checksum: 0x7d82 (unverified), length 419 Device-ID (0x01), length: 6 bytes: 'Switch' Version String (0x05), length: 189 bytes: Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEE4, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Mon 16-Jul-07 03:11 by myl Platform (0x06), length: 20 bytes: 'cisco WS-C3560G-24TS' Address (0x02), length: 69 bytes: IPv4 (3) 192.168.20.1 IPv6 (2) fe80::21e:49ff:fe88:f4c2 IPv6 (1) 3ffe:501:ffff:101::1 Port-ID (0x03), length: 19 bytes: 'GigabitEthernet0/22' Capability (0x04), length: 4 bytes: (0x00000029): Router, L2 Switch, IGMP snooping Protocol-Hello option (0x08), length: 32 bytes: VTP Management Domain (0x09), length: 0 bytes: '' Native VLAN ID (0x0a), length: 2 bytes: 1 Duplex (0x0b), length: 1 byte: full Management Addresses (0x16), length: 13 bytes: IPv4 (1) 192.168.20.1 unknown field type (0x1a), length: 12 bytes: 0x0000: 0000 0001 0000 0000 ffff ffff 1 packet captured 1 packet received by filter 0 packets dropped by kernel [root@localhost ~]# brctl show bridge name bridge id STP enabled interfaces ;vdsmdummy; 8000.000000000000 no ovirtmgmt 8000.e41f13ebcd63 no bond0.20 [root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0 # Generated by VDSM version 4.17.10.1-0.el7ev DEVICE=bond0 BONDING_OPTS='mode=4 miimon=100' ONBOOT=yes MTU=1500 NM_CONTROLLED=no IPV6INIT=no HOTPLUG=no [root@localhost ~]# cat /sys/class/net/bond0/bonding/slaves eno3 eno4 [root@localhost ~]# cat /proc/net/vlan/config VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD bond0.20 | 20 | bond0
Fabian, could you check comment 19, is that enough for this bug on node side? Thanks
4. Unplug one port from the test machine. Suggestion: Try to remove both cables, just one at a time. I don't know if the correct working of LACp can be verified from the console. In general this looks fine to me. We should also cover the auto-installation with the bond_setup= argument to see where we stand here.
(In reply to Fabian Deutsch from comment #21) > 4. Unplug one port from the test machine. > Suggestion: Try to remove both cables, just one at a time. Test your suggestion steps: 1, Unplug one cable, wait 5 mins, ping and check RHEV-H status. 2. Plug the cable back, wait 5 mins, ping and check RHEV-H status. 3. Unplug the other one, wait 5 mins, ping and check RHEV-H status. 4. Plug the cable back, wait 5 mins, ping and check RHEV-H status. Result: For all the steps, RHEV-H can ping successful, there is no ping packages lost, and RHEV-H status always was up. > > I don't know if the correct working of LACp can be verified from the console. > In general this looks fine to me. > > We should also cover the auto-installation with the bond_setup= argument to > see where we stand here. Test the bood_setup patameter: bond=bond0:eno3,eno4:mode=4 vlan=20:bond0 Test steps were some with TUI Installation, the result was PASS.
Hi Allan, We test the request on Bond+Vlan environment, details please see the comment 19 and comment 22. Do you think whether those scenarios can meet the customers request ?
According to comment#19 and #22, verified this issue on rhev-hypervisor7-7.2-20151112.1.iso.
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/RHEA-2016-0376.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days