Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
On 04/22/2013 07:03 PM, Moti Asayag wrote:
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
Moti,
Could you please paste the output of 'ip --detail link show' on your test host here? Thanks!
Mark
I see the same issue and the output of ip --detail link show is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:b2:8e:89 brd ff:ff:ff:ff:ff:ff 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:db:92:09 brd ff:ff:ff:ff:ff:ff 4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:4d:f0:00 brd ff:ff:ff:ff:ff:ff 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 9000 qdisc noqueue state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 02:ff:28:37:6a:d6 brd ff:ff:ff:ff:ff:ff 10: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 12: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 13: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 484: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Moti Asayag" masayag@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, "Antoni Segura Puimedon" asegurap@redhat.com Sent: Monday, April 22, 2013 4:23:02 PM Subject: Re: Error in network devices report with getVdsCaps
On 04/22/2013 07:03 PM, Moti Asayag wrote:
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
Moti,
Could you please paste the output of 'ip --detail link show' on your test host here? Thanks!
Mark
Toni, Thanks for the info! That's bad! It looks 'ip --detail link' doesn't report interface type as what it does on fedora:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:de:44:dd brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:df:89:d9 brd ff:ff:ff:ff:ff:ff 5: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff bridge 7: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT link/ether 92:63:1c:88:31:ef brd ff:ff:ff:ff:ff:ff bridge 8: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff bond
I didn't verify this patch on RHEL system. My fault again!
@Dan, I am fine to revert the patch since it doesn't work on RHEL6. Sorry for the trouble!
Mark
On Mon 22 Apr 2013 11:27:12 PM CST, Antoni Segura Puimedon wrote:
I see the same issue and the output of ip --detail link show is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:b2:8e:89 brd ff:ff:ff:ff:ff:ff 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:db:92:09 brd ff:ff:ff:ff:ff:ff 4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:4d:f0:00 brd ff:ff:ff:ff:ff:ff 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 9000 qdisc noqueue state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 02:ff:28:37:6a:d6 brd ff:ff:ff:ff:ff:ff 10: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 12: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 13: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 484: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Moti Asayag" masayag@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, "Antoni Segura Puimedon" asegurap@redhat.com Sent: Monday, April 22, 2013 4:23:02 PM Subject: Re: Error in network devices report with getVdsCaps
On 04/22/2013 07:03 PM, Moti Asayag wrote:
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
Moti,
Could you please paste the output of 'ip --detail link show' on your test host here? Thanks!
Mark
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Antoni Segura Puimedon" asegurap@redhat.com Cc: "Moti Asayag" masayag@redhat.com, vdsm-devel@lists.fedorahosted.org, "Dan Kenigsberg" danken@redhat.com Sent: Monday, April 22, 2013 5:42:19 PM Subject: Re: Error in network devices report with getVdsCaps
Toni, Thanks for the info! That's bad! It looks 'ip --detail link' doesn't report interface type as what it does on fedora:
Yes, that is the case. My arch linux at home running a relatively new kernel also lacks the type in the output. I'm afraid that we'll have to revert the change or keep it but changing the source of the "type" information.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:de:44:dd brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:df:89:d9 brd ff:ff:ff:ff:ff:ff 5: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff bridge 7: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT link/ether 92:63:1c:88:31:ef brd ff:ff:ff:ff:ff:ff bridge 8: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff bond
I didn't verify this patch on RHEL system. My fault again!
@Dan, I am fine to revert the patch since it doesn't work on RHEL6. Sorry for the trouble!
Mark
On Mon 22 Apr 2013 11:27:12 PM CST, Antoni Segura Puimedon wrote:
I see the same issue and the output of ip --detail link show is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:b2:8e:89 brd ff:ff:ff:ff:ff:ff 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:db:92:09 brd ff:ff:ff:ff:ff:ff 4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:4d:f0:00 brd ff:ff:ff:ff:ff:ff 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 9000 qdisc noqueue state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 02:ff:28:37:6a:d6 brd ff:ff:ff:ff:ff:ff 10: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 12: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 13: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 484: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Moti Asayag" masayag@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, "Antoni Segura Puimedon" asegurap@redhat.com Sent: Monday, April 22, 2013 4:23:02 PM Subject: Re: Error in network devices report with getVdsCaps
On 04/22/2013 07:03 PM, Moti Asayag wrote:
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
Moti,
Could you please paste the output of 'ip --detail link show' on your test host here? Thanks!
Mark
On 04/22/2013 05:49 PM, Antoni Segura Puimedon wrote:
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Antoni Segura Puimedon" asegurap@redhat.com Cc: "Moti Asayag" masayag@redhat.com, vdsm-devel@lists.fedorahosted.org, "Dan Kenigsberg" danken@redhat.com Sent: Monday, April 22, 2013 5:42:19 PM Subject: Re: Error in network devices report with getVdsCaps
Toni, Thanks for the info! That's bad! It looks 'ip --detail link' doesn't report interface type as what it does on fedora:
Yes, that is the case. My arch linux at home running a relatively new kernel also lacks the type in the output. I'm afraid that we'll have to revert the change or keep it but changing the source of the "type" information.
and if you keep it, the unit test should probably use the real output from `ip --detail link` then you can see this happening earlier and know where it failed :-)
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP mode DEFAULT qlen 1000 link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:de:44:dd brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000 link/ether 52:54:00:df:89:d9 brd ff:ff:ff:ff:ff:ff 5: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT link/ether 00:16:3e:e3:68:64 brd ff:ff:ff:ff:ff:ff bridge 7: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT link/ether 92:63:1c:88:31:ef brd ff:ff:ff:ff:ff:ff bridge 8: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff bond
I didn't verify this patch on RHEL system. My fault again!
@Dan, I am fine to revert the patch since it doesn't work on RHEL6. Sorry for the trouble!
Mark
On Mon 22 Apr 2013 11:27:12 PM CST, Antoni Segura Puimedon wrote:
I see the same issue and the output of ip --detail link show is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:b2:8e:89 brd ff:ff:ff:ff:ff:ff 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:db:92:09 brd ff:ff:ff:ff:ff:ff 4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:4d:f0:00 brd ff:ff:ff:ff:ff:ff 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 9000 qdisc noqueue state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 02:ff:28:37:6a:d6 brd ff:ff:ff:ff:ff:ff 10: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 11: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 12: bond2: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 13: bond3: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 484: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 52:54:00:68:25:57 brd ff:ff:ff:ff:ff:ff
----- Original Message -----
From: "Mark Wu" wudxw@linux.vnet.ibm.com To: "Moti Asayag" masayag@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, "Antoni Segura Puimedon" asegurap@redhat.com Sent: Monday, April 22, 2013 4:23:02 PM Subject: Re: Error in network devices report with getVdsCaps
On 04/22/2013 07:03 PM, Moti Asayag wrote:
Hi,
Latest vdsm has a regression in network devices reported with getVdsCaps:
In the list below 'vdsmdummy' should be filtered out and 'rhevm' should have been reported as a network under the bridges element and also as a network under networks element.
I suspect commit 8febe0e40650983d809abaa10be983bc1953ef1e caused this issue, but haven't tried a build with a version prior to it to confirm it.
Here is the output of the getVdsCaps, filtered only for the relevant elements:
bridges = {} networks = {} nics = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'hwaddr': 'ca:b4:d1:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'eth0': {'addr': '', 'cfg': {'BRIDGE': 'rhevm', 'DEVICE': 'eth0', 'HWADDR': '00:26::xx:xx:xx', 'MTU': '1500', 'ONBOOT': 'yes'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '', 'speed': 1000}, 'eth1': {'addr': '', 'cfg': {'BOOTPROTO': 'dhcp', 'DEVICE': 'eth1', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HWADDR': '00:26:6C:FF:CD:C1', 'IPV6INIT': 'no', 'NM_CONTROLLED': 'yes', 'ONBOOT': 'no', 'TYPE': 'Ethernet', 'USERCTL': 'no', 'UUID': '09876e54-70c3-4572-a63a-f2c3da6fb0bd'}, 'hwaddr': '00:26:6c:xx:xx:xx', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'speed': 0}, 'rhevm': {'addr': '10.35.148.48', 'cfg': {'BOOTPROTO': 'dhcp', 'DELAY': '0', 'DEVICE': 'rhevm', 'DHCP_HOSTNAME': 'xxx.xxx.com', 'HOSTNAME': 'xxx.xxx.redhat.com', 'IPV6INIT': 'no', 'MTU': '1500', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge', 'UUID': '4a1dd6c4-2bba-4825-92c8-7dd9ba29ce67'}, 'hwaddr': '00:26:6c:ff:cd:c0', 'ipv6addrs': ['fe80::226:6cff:feff:cdc0/64'], 'mtu': '1500', 'netmask': '255.255.252.0', 'speed': 0}}
Thanks, Moti
Moti,
Could you please paste the output of 'ip --detail link show' on your test host here? Thanks!
Mark
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel@lists.fedorahosted.org