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

Reply via email to