Hi.
I'm trying to install CS4.1 in a host with Centos6.4 and I'm having
exactly the same problem:
2013-06-25 14:07:14,703 DEBUG [kvm.resource.LibvirtComputingResource]
(main:null) failing to get physical interface from bridgemanagement, did
not find an eth*, bond*, or vlan* in
/sys/devices/virtual/net/management/brif
The interface list on the server:
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether e0:db:55:21:1f:3c brd ff:ff:ff:ff:ff:ff
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether e0:db:55:21:1f:3e brd ff:ff:ff:ff:ff:ff
4: p3p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether 00:0a:f7:0d:fb:e0 brd ff:ff:ff:ff:ff:ff
5: p3p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether 00:0a:f7:0d:fb:e2 brd ff:ff:ff:ff:ff:ff
6: public_guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/ether 00:0a:f7:0d:fb:e0 brd ff:ff:ff:ff:ff:ff
7: management: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
link/ether 00:0a:f7:0d:fb:e2 brd ff:ff:ff:ff:ff:ff
9: cloud0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
link/ether b2:64:55:9e:b8:33 brd ff:ff:ff:ff:ff:ff
Is there any other solution than the one found by Javier?
removing the biosdevname package, renaming all em* ifcfg scripts to eth*
and deleting the 70-persistent-net.rules
Thanx.
El 23/05/13 17:51, Prasanna Santhanam escribió:
Yes the consistent naming scheme problem I *think* was fixed already
by Marcus and should be in 4.1 IIRC. Glad to hear that your problem is
solved.
On Thu, May 23, 2013 at 05:17:04PM +0200, Javier Rodriguez wrote:
Hi Prasanna,
Thanks very much for your response,
[root@mnode-1 ~]# rpm -qa | grep qemu
gpxe-roms-qemu-0.9.7-6.9.el6.noarch
qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.2.x86_64
qemu-img-0.12.1.2-2.355.0.1.el6.centos.2.x86_64
[root@mnode-1 ~]# rpm -qa | grep virt
libvirt-client-0.10.2-18.el6_4.4.x86_64
libvirt-0.10.2-18.el6_4.4.x86_64
virt-what-1.11-1.2.el6.x86_64
[root@mnode-1 ~]# rpm -qa | grep cloud
cloud-deps-4.0.2-1.el6.x86_64
cloud-utils-4.0.2-1.el6.x86_64
cloud-scripts-4.0.2-1.el6.x86_64
cloud-agent-libs-4.0.2-1.el6.x86_64
cloud-python-4.0.2-1.el6.x86_64
cloud-agent-4.0.2-1.el6.x86_64
cloud-core-4.0.2-1.el6.x86_64
I enabled the DEBUG mode like you asked (I did not find
/etc/cloudstack/agent/log4j.xml, so I changed it in
/etc/cloud/agent/log4j-cloud.xml instead), and I found something
interesting:
2013-05-23 12:26:26,210 DEBUG
[kvm.resource.LibvirtComputingResource] (main:null) failing to get
physical interface from bridgecloudbr0, did not find an eth*, bond*,
or vlan* in /sys/devices/virtual/net/cloudbr0/brif
The only file in /sys/devices/virtual/net/cloudbr0/brif is a symlink
named em1.200, and apparently the cloud agent is expecting to find
eth* devices.
Apparently this has something to do with the Consistent Network
Device naming feature introduced in later RH based distributions.
(if eth0 is embedded in the motherboard it will be now called em1 by
default).
After investingating a bit I managed to rename the nics by removing
the biosdevname package, renaming all em* ifcfg scripts to eth* and
deleting the 70-persistent-net.rules in /etc/udev/rules.d (which
gets automatically regenerated with proper values taken from ifcfg
scripts by write_net_rules).
After that I could add the host with no problem :) . I think the
cloud agent not being able to manage Consistent Network Device
Interfaces ( em* and p*p* ) is probably a bug in the cloud agent.
Thanks for your help,
-Javier
--
Fernando Guillén Camba
Unidade de Xestión de Infraestruturas TIC
Centro de Investigación en Tecnoloxías da Información (CITIUS)
Teléfono: 8818 16409
Correo: citius....@usc.es
