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
