----- Original Message -----
From: "Mark Wu" <wudxw(a)linux.vnet.ibm.com>
To: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
Cc: "Moti Asayag" <masayag(a)redhat.com>,
vdsm-devel(a)lists.fedorahosted.org, "Dan Kenigsberg" <danken(a)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(a)linux.vnet.ibm.com>
>> To: "Moti Asayag" <masayag(a)redhat.com>
>> Cc: vdsm-devel(a)lists.fedorahosted.org, "Antoni Segura Puimedon"
>> <asegurap(a)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
>>
>>
>