in the file "/etc/cloudstack/agent/agent.properties" you can see two properties which are commented: #public.network.device=cloudbr0 #private.network.device=cloudbr1 the commented contents indicate that you should create two bridges called cloudbr0 and cloudbr1,or you can uncomment the two lines and modify them to other values.
------------------ Original ------------------ From: "Fernando Guillén Camb"<[email protected]>; Date: Tue, Jun 25, 2013 08:14 PM To: "users"<[email protected]>; Subject: Re: cant add host to cloud: "Nics are not configured!" / "Failedto get public nic name" 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: [email protected]
