On 04/22/2013 05:49 PM, Antoni Segura Puimedon wrote:
- Original Message -
From: "Mark Wu"
To: "Antoni Segura Puimedon"
Cc: "Moti Asayag" , vdsm-devel@lists.fedorahosted.org, "Dan
Kenigsberg"
Sent: Monday, April 22, 2013 5:42:19 PM
Subject: Re: Error in network devices report with g
- Original Message -
> From: "Mark Wu"
> To: "Antoni Segura Puimedon"
> Cc: "Moti Asayag" , vdsm-devel@lists.fedorahosted.org,
> "Dan Kenigsberg"
> Sent: Monday, April 22, 2013 5:42:19 PM
> Subject: Re: Error in network devices report with getVdsCaps
>
> Toni,
> Thanks for the info!
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: 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: mtu 1500 qdisc pfifo_fast
master ovirtmg
I see the same issue and the output of ip --detail link show is:
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: 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: mtu 900
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
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 8febe0e40650983d809abaa10
