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