cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Guillén Camba <fernando.guil...@usc.es>
Subject Re: cant add host to cloud: "Nics are not configured!" / "Failedto get public nic name"
Date Tue, 25 Jun 2013 14:12:31 GMT
Thanks for the reply. This is the content of my agent.properties:

#Storage
#Tue Jun 25 16:07:21 CEST 2013
guest.network.device=public_guest
workers=5
private.network.device=management
port=8250
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
pod=1
zone=1
guid=9b1d387e-11bd-3ab0-a673-c655eb4c8f66
cluster=1
public.network.device=public_guest
local.storage.uuid=1bc23df8-6012-4909-a3af-2719255caf3c
domr.scripts.dir=scripts/network/domr/kvm
host=192.168.0.2
LibvirtComputingResource.id=0


Following the findings of the previous answers qiven below the problem 
seems to be in the name the physical interfaces are qiven in RHEL and 
derivatives, not in the bridges.
By the way I had a previous CS4.0.1 working with the same bridge 
configuration but under Ubuntu 12.04.



El 25/06/13 15:21, WXR escribió:
> 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"<fernando.guillen@usc.es>;
> Date:  Tue, Jun 25, 2013 08:14 PM
> To:  "users"<users@cloudstack.apache.org>;
>
> 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: citius.tic@usc.es


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message